JBUG Milan: first meeting will focus on AS7

We (alessio and me) are going to have a speech on AS7 during the first JBUG Milan’s meeting next 20 Septmber.

If you are around Milan join us it will be a lot of fun. For your convenience I have pasted here the full agenda, but don’t forget to visit the official group and sign in for partecipation.

9.30: Welcome coffee
9.45: Welcome and first infos about JBUG
10.15: JBoss AS7
11.00: Coffee Break
11.15: JBoss AS7 and webservices
12.00: JBoss in cloud with OpenShift
12.45: Closing
13.00: luch
14:00: Hacking AS7

And don’t miss the hacking party we will have in the afternoon: Alessio and me will be in the public area of Red Hat office working on JBoss AS7, and would be cool to have you hacking with us. Don’t leave your laptop at home, join the community and send your first patch in that afternoon.

 

And now, for our italian reader, for this italian event…the post in italian language:

Alessio ed io faremo due presentazioni su AS7 durante il primo meeting del JBUG di Milano il prossimo 20 Settembre.

Se passte da Milano, non perdetevi l’evento, ci divertiremo. Per vostra comodità riporto qui l’agenda definitiva dell’incontro, ma non scordatevi di fare un giro sul gruppo ufficiale del JBUG ed iscrivetevi all’evento mandando la mail come indicato in uno dei messaggi.

9.30: Welcome coffee
9.45: Benvenuto e prime informazioni sul JBUG
10.15: JBoss AS7
11.00: Coffee Break
11.15: JBoss AS7 e i webservices
12.00: JBoss in cloud con OpenShift
12.45: Closing
13.00: Pranzo a buffet
14:00: Sviluppo di AS7

E mi raccomando, non perdetevi l’hacking su AS7 nel pomeriggio. Io ed Alessio ci fermeremo in area pubblica dell’ufficio Red Hat di Milano a lavorare su JBoss AS7. E sarebbe bello sviluppare insieme a voi. Non dimenticatevi il computer , partecipate alla community mandando il pomeriggio stesso la vostra prima patch ;)

 

See you there!

Ci vediamo li!

JBossWS 2010 closing balance… an year of integration

Before joining Red Hat / JBoss, I used to have closing balance face to face meetings at work before Christmas. Of course I met with my direct boss… so now I find quite funny to think about writing something similar to a JBossWS 2010 closing balance here, given my boss at that time now happens to be the guy I share this blog with and since some months he’s finally working for Red Hat / JBoss too – Stefano ;-)

So, what’s up with JBossWS in 2010 ? The project has gone through two major sets of releases. The 3.3.x series kind of finalized the JBossWS move to having the Apache CXF based stack as its preferred one, installed by default on JBoss Application server. Integrating a third-party piece of software is always something non-trivial. And even if the overall quality of what we consume (and contribute to, of course) from Apache is definitely very high, that’s simply not enough when it comes to integrating: many issues were discovered, dealt with and solved… any many are probably still to come.

The type of development you end up doing when providing a solution like JBossWS-CXF is pretty much different from what you are on when developing stuff from scratch. I kind of expected that to be honest. It’s not that unusual to spend days on looking for the best way of re-using / integrating already existing (or partially available) functionalities, trying to figure out an elegant solution for achieving the goal on JBoss side, while enriching the third-party side of the software in a way that makes sense regardless of JBoss needs. Sometime I think it’s like “plumbing”. For sure you need to go on constantly swapping your hats, the JBoss employee one and the Apache contributor one, in my case. And given we operate in an open source world here :-) … you might even find yourself producing fully vendor agnostic solutions just for the sake of solving your own (JBoss here) problem.

Some might dislike this kind of work, thinking satisfaction can come only from creating your own solutions from scratch, feeling they’re your own babies. Others might appreciate the integration work, enjoying the  new challenges in this. To be honest, I think this is a really subjective feeling and you can find yourself excited by the achievements you reach in both cases. You should probably try both in any case.

Anyway, back to bringing Apache CXF in JBoss through JBossWS… implementing the JSR 109 requirements is a good example of integration. Apache CXF provides WS functionalities and successfully verifies those are compliant with the core JCP WS specifications (JSR 224 – JAXWS, for instance). However CXF of course does not care about all the details on how that’s supposed to work with a given application server according to the rest of the JavaEE specification, which JSR 109 is a good example of. In an ideal world the missing bits need to live in the integration project (JBossWS here)… In reality you end up coordinating different needs, reviewing and rationalizing stuff on both sides, to basically make the integration happen and be a success.

The second set of JBossWS 2010 releases has been the 3.4.x series. While the announcement is recent story, that was a multiple months effort from me and the rest of the team. We went through active collaboration on CXF (Apache contributor hat on ;-) ) to have it implement JAXWS 2.2 and make it pass the TCK certifaction testsuite for that. While on that, we implemented the proper integration for passing the corresponding ws modules of JavaEE 6 TCK on JBoss side (with *the* red hat on ;-) ). This all was done while directly targeting development snapshots of Apache CXF, hence with multiple moving targets (JBoss AS, Apache CXF, our own JBossWS integration layer and even the TCK which was not final yet) to track for potential regressions.

At the end of the year I’m quite satisfied by what we got. From a job point of view, I’m just waiting for Santa to come with a nice present… a final release of JBoss AS 6 (I sent him the jbossws maven artifacts to include in the box ;-) , he should have got them in time… despite the snow over north Italy these days).

OK, now it’s time to start relaxing a bit, to enjoy the Christmas spirit…  then I’ll come back with new intentions for the next year, both directly related to JBossWS and not…

Merry X-mas and happy new year!

IronJacamar Beta2 released

Just a little cross post to inform my readers that the project I’m working on full time as Core Developer at JBoss has reached Beta2.
Since I never write about it here, let me explain that IronJcamar implements the Java EE Connector Architecture 1.6 specification.
This is a quite great release, and we are eager to have your feedback.
We have added support for our extension to specification deployment descriptors. They are designed with easy-to-use for final users requirements in mind. These formats are set to be ones used in JBoss Application Server 7, so be sure to check out the XSDs and send your feedback.

Small open source projects are difficult to keep alive. And what about Wise and TestedBy?

Hi all,
another time I have to say that a long time has passed since my last post :(

Well, I’ve been very very busy in last months driving (or at least help a lot to drive) a big change in my former company, leading a key project with more than fifty programmers involved distributed in various team, with a lot of biz analysts and so on. But it’s another story I’ll probably tell you at some point. But the important word in last sentence is former. Yep, who is following me on twitter (or have recently read about_us page or even is linked with me on linkedin) knows I’ve joined  Red Hat as Principal Software Engineer in JBoss division. That’s a cool interesting job (I’m working on IronJacamar project and AS7 development), but it’s making me very busy.

Anyway, back to the title of this post. It’s matter of fact that is very hard to keep alive open source projects in spare time. And maybe in last months some people thought that Wise is an almost dead project, and TestedBy a totally dead one. In fact we had very few time to  work on Wise and also on TestedBy for all the reasons stated above. But they aren’t dead and we are getting back on them (check last week commits for both!).

In particular Alessio is working on Wise to full support JBossWS-CXF container, while I’m planning to cleanup ESB module to support the last version (maybe after Alessio’s work). After that we will work on our object mapping subsystem needed to continue the implementation of our WebUI.

I’m refining in the mean time samples of TestedBy to make possible to release the first version of the project. BTW very probably we will leave “TestedBy” name and we will launch the first release of the project with a new cool name. I’ll keep you post here.

As said keeping open source project alive in spare time isn’t easy, and sometime it’s very very hard specially if contributors are very few and very busy. Would you be part of a cool open source project, with all the beauty of that? We would need in particular contributions for TestedBy in Eclipse area, but if you would land an hand in other area and/or in Wise we are fine with that too. Please contact us, your help could make the difference!

Last but not least Wise have a new very very cool logo. Thanks to Red Hat Design team and in particular to Cheynne for that! No link here…it merits a dedicated post!

As said a lot of cool stuffs are coming…stay tuned.

Simple WS endpoint deployment with JAXWS 2.2 HTTP container abstraction

Recently I’ve been playing with the JAXWS Endpoint.publish(..) API. For those not really involved in WS development, JAXWS includes an API for easily deploying an endpoint in JSE environment while starting a http server just for serving calls to the specified endpoint.

Endpoint endpoint = Endpoint.create(new EndpointBean());
endpoint.publish("http://localhost:8080/jaxws-endpoint1");
//invoke endpoint...
endpoint.stop();

While from a user point of view this API is of few interest on a JavaEE environment, this is still quite interesting in JSE env as well as whenever having the need for a quick/easy testing of basic endpoints.
Moreover, JAXWS 2.2 added a HTTP SPI for establishing / fixing the layer between http server containers and JAXWS stack implementations. This basically allows any jaxws 2.2 compliant implementation to be used on top of any “compatible” http server.
Jitendra Kotamraju (current JSR-224 spec lead) recently provided a bridge project for making Grizzly compatible with the JAXWS 2.2 HTTP SPI. I’ve done the same for the httpserver included in the JDK6 com.sun.net.httpserver.HttpServer. There’s also a similar project for Jetty. So, with the additions of spec 2.2 and the required vendor implementations to comply on that, users can finally do the following with any JAXWS compliant implementation:

import javax.xml.ws.spi.http.HttpContext;
..
HttpContext context = ..;
Endpoint endpoint = Endpoint.create(new EndpointBean());
endpoint.publish(context);
//invoke endpoint
endpoint.stop();

where the context is obtained according to the selected containers, for instance (using my bridge to the JDK6 httpserver):

import com.sun.net.httpserver.HttpServer;
..
HttpServer server = HttpServer.create(new InetSocketAddress(currentPort), 0);
HttpContext context = HttpServerContextFactory.createHttpContext(server, contextPath, path);
server.start();
..
//here comes the endpoint publish and usage as shown above
..
server.stop(0);

Quite handy, isn’t it? ;-)