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!

JBossWS and Apache CXF collaboration

I’ve just pubblished a post on the JBosWS blog regarding the JBossWS involvement in the Apache CXF project. In few words, the JBossWS team is increasing its collaboration with the CXF developers, the target being to improve both projects.

It’s not that simple to achieve an active bi-directional collaboration, with both parties’ needs being considered, but this is working quite well now. For instance, read what Daniel Kulp (CXF lead) writes about the collaboration. Needless to say I like this, that’s a nice example of what open source can make possible.

Ant 1.7.1 and package-info.java compilation problem of JAX-WS generated classes

Today I have spent a lot of time with a very strange issue compiling JAX-WS generated classes. I have been using jbossws wsconsume to generate some classes from a .NET wsdl and I had a very strange behaviour:

  1. Generate class calling wsconsume
  2. compile them and its client using ant and run my test perfectly working
  3. then calling my clean task to remove .class files and recompile them and run my tests doesn’t work!

IOW JAX-WS client have been working only the first time I compile them. I couldn’t figure out why it have been working in that manner, but after a lot of google search I got this commit. In practice what have been happening is better described in “Note on package-info.java” paragraph of javac target in ant manual. Starting from version 1.7.1 ant compile package-info.java only in these 3 case:

  1. If a package-info.class file exists and is older than the package-info.java file.
  2. If the directory for the package-info.class file does not exist.
  3. If the directory for the package-info.class file exists, and has an older modification time than the the package-info.java file. In this case <javac> will touch the corresponding .class directory on successful compilation.

In practice if you havea ant task like mine:

<target name=”compile” depends=”init” description=”Compile the Java source code”>
<javac destdir=”${classes.dir}” classpathref=”build.classpath” debug=”${javac.debug}” deprecation=”${javac.deprecation}” target=”1.5″>
<src path=”${src.java.dir}” />
</javac>

Here the compilation target compile all files and so create directory where package-info.class will be contained during other generated files compilation. In this case the compilation target never re-generate package-info.class because no one of the 3 conditions is true. My workaround have been to change my build.xml file and have this compile target:

<target name=”compile” depends=”init” description=”Compile the Java source code”>
<touch>
<fileset dir=”${src.java.dir}” includes=”**/package-info.java”/>
</touch>
<javac destdir=”${classes.dir}” classpathref=”build.classpath” debug=”${javac.debug}” deprecation=”${javac.deprecation}” target=”1.5″>
<src path=”${src.java.dir}” />
</javac>

Hoping this post would be useful for someone, let me remark that is a problem of ant javac task, not of jbossws and you will get the same problem with any other jaxws stack.

Let me remark also that Wise perfectly work in this case regenerating it’s classes on the fly :P

JBossWS wsconsume error “undefined element declaration ‘sch:schema’”

Today I was importing a .NET generated wsdl and getting this error using JBossWS wsconsume.sh tool (yes I’m not using Wise for this particular case!! But the problem would be the same in Wise since it use wsconsume under the hood) :

[WARNING] src-resolve.4.2: Error resolving component 'sch:schema'. It was detected that 'sch:schema' is in namespace 'http://www.w3.org/2001/XMLSchema', but components from this namespace are not referenceable from schema document 'file:/home/oracle/Desktop/security.asmx#types?schema1'. If this is the incorrect namespace, perhaps the prefix of 'sch:schema' needs to be changed. If this is the correct namespace, then an appropriate 'import' tag should be added to 'file:/home/oracle/Desktop/security.asmx#types?schema1'.
  line 85 of file:/home/oracle/Desktop/security.asmx#types?schema1
[ERROR] undefined element declaration 'sch:schema'
  line 85 of file:/home/oracle/Desktop/security.asmx
[ERROR] undefined element declaration 'sch:schema'
  line 178 of file:/home/oracle/Desktop/security.asmx
[ERROR] undefined element declaration 'sch:schema'
  line 217 of file:/home/oracle/Desktop/security.asmx
[ERROR] undefined element declaration 'sch:schema'
  line 231 of file:/home/oracle/Desktop/security.asmx
[ERROR] undefined element declaration 'sch:schema'
  line 245 of file:/home/oracle/Desktop/security.asmx
[ERROR] undefined element declaration 'sch:schema'
  line 259 of file:/home/oracle/Desktop/security.asmx
[ERROR] undefined element declaration 'sch:schema'
  line 273 of file:/home/oracle/Desktop/security.asmx

Failed to invoke WsImport
java.lang.NullPointerException
        at com.sun.tools.xjc.reader.internalizer.SCDBasedBindingSet.apply(SCDBasedBindingSet.java:237)
        at com.sun.tools.xjc.ModelLoader.createXSOM(ModelLoader.java:518)
        at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:232)
        at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:85)
        at com.sun.tools.ws.processor.modeler.wsdl.JAXBModelBuilder.bind(JAXBModelBuilder.java:134)
        at com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.buildJAXBModel(WSDLModeler.java:2244)
        at com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.internalBuildModel(WSDLModeler.java:187)
        at com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.buildModel(WSDLModeler.java:133)
        at com.sun.tools.ws.wscompile.WsimportTool.run(WsimportTool.java:182)
        at org.jboss.ws.tools.jaxws.impl.SunRIConsumerImpl.consume(SunRIConsumerImpl.java:217)
        at org.jboss.wsf.spi.tools.cmd.WSConsume.importServices(WSConsume.java:223)
        at org.jboss.wsf.spi.tools.cmd.WSConsume.main(WSConsume.java:81)

After some search Alessio pointed me to this excellent post where the problem is well explained and solution provided. The “problem” is not specific to JBossWS and solution explained there is fine for JBossWS too.

Hoping this cross post could help someone looking for the error in relation to JBossWS in google ;)