Error Messages using the WEF JAXB Plugin

I just resolved an issue related to my plugin for WEF which generates JAXB code for easy conversion to/from IXML and I thought I'd write it up before I forget.

The error message looks something like this:

java.lang.ClassCastException: javax.xml.bind.JAXBElement incompatible with com.dsixe.jaxbgen....

This seems to be caused by a variance in the schema generated by the SQL Call builder where the topmost wrapper element is not annotated as root element by JAXB. The problem is solved by using code which looks like this:

javax.xml.bind.JAXBElement jaxbElement = (javax.xml.bind.JAXBElement)Transform.convertToObject(available, "http://com/dsixe/Roles", com.dsixe.jaxbgen.rolesTransformSchema.RowSetType.class);

com.dsixe.jaxbgen.rolesTransformSchema.RowSetType iAvailable = (com.dsixe.jaxbgen.rolesTransformSchema.RowSetType) jaxbElement.getValue(); 



We need to initially cast to JAXBElement and then use getValue() to retrieve the object. One more line of code fixes the problem.

Defaulting WEF Builder Input Groups as Expanded

A little used WEF feature is the comments builder input which appears on all builder editors. The input always displays at the very top under the collapsed group header "Properties" along with the builder enable/disable input. The primary reason it is little used is because the "Properties" group is collapsed by default and therefore not immediately visible. This can be easily changed through these steps:

1) Extract the Base.bdef file from \WebContent\WEB-INF\builders\corebuilders.zip
2) Copy the file to \WebContent\WEB-INF\builders\com\bowstreet\core
3) Edit the highlighted element from true to false

Restart your eclipse workspace and the comments builder input should now be visible by default.

Remember to restart this process when you upgrade to a new version of WEF since this effectively overrides the designer's defaults.

REST vs SOAP

For some reason people who work in technology seem to have well defined opinions about matters and will often go to great lengths to defend those opinions. Think about the unix vi editor (I dislike), windows vs unix, windows vs apple. These topics will often lead to flame wars. Today I'm going to weigh in on web service transports and hope I don't light up a wildfire.

Early Binding vs Late Binding

I'm a supporter of the SOAP protocol for most cases unless the service is to be consumed by a javascript application. I've been thinking about why it is that I have this preference and I think I know exactly why. It comes down to early (or design time) binding of an external component vs late (or runtime) binding. This concept has been around since the early days of computer science, the idea being that a sub component can declare ahead of time what kind of operation signatures it supports so that these can be confirmed by the compiler. If a piece of code which has been bound at compile time fails at run time then we immediately know there is a conflict in versions. A similar concept is found in strongly typed languages. I can think of a few examples of this:

• java interfaces
• C/C++ header files
• WSDL - web service definition language

The bad part of using SOAP is that it requires additional overhead, but in simple cases this is little more that a message envelope.

The other side of the argument is run time binding where we find out about the operation signatures when the code is actually executed. Now this isn't as bad as one thinks because the component owner will always provide details about the shape of the data and what is expected so the consumer that write appropriate code. The bad part of this is that the service provider can change anything at any time without notifying the consumers, resulting in an error when the consumer attempts to invoke an operation. There is a similar concept in weakly typed languages:

• javascript
• visual basic
• assembly language

How to Choose?

The short answer is that this whole argument is moot if the software is well designed and written. All the valuable business logic should reside in java bean POJOs and then combined with a runtime container such as an enterprise service bus (ESB) or a service component architecture (SCA). The container manages exposing the POJO business logic using any number of transport protocols and can be configured at time of deployment. If an ESB or SCA is not available, then a similar result can be attained by coding a thin delegate using JAX-RS or JAX-WS.

Why do I prefer early binding? I don't like doing emergency production troubleshooting and with early binding I can eliminate one more point of failure.

Transform IXml with JAXB

This posting simply redirects to an article I've added to IBM's community.

http://www-10.lotus.com/ldd/pfwiki.nsf/dx/Transform_IXml_with_JAXB