Just another idiot’s ramblings

One of the biggest tasks in updating Frame2 is making sure the web services components still work. This integration was one of the major features when Frame2 was orginally developed as TurboM2 – at the time it was something that really set it apart from Struts.
I’ll be honest and say that I never had that strong of a grasp on the web services side of Frame2. As long as the unit tests kept passing, I didn’t really care. Now, however, as I muck about in the guts of the system, I’ve really come to appreciate the advances that have been made in JAXB in the last several years. That’s not to say it’s been an entirely painless process, though. Here’s what I’ve found so far:
Good

• The JAXB Reference Implementation (RI) included with Java 6 has been greatly overhauled. The number one improvement I’ve enjoyed is the reduced number of generated files. In one case, there are now 4 files where older versions of JAXB created 35-40.
• All of the required support jars are part of Java 6. No more downloading and installing the Web Services Developer’s Kit – not to mention repackaging it. Huge savings in space and dependencies.

Bad

• If a schema import creates multiple classes, all of those classes extend the specified superclass. There is no either/or. For the purposes of Frame2, classes created from schemas need to extend JaxbEventBase in order to work correctly with the framework. In most cases, however, only the root element needs to extend JaxbEventBase. JAXB only allows inheritance on an all or nothing basis, so it can introduce confusion with trying to use objects that technically have the right interface, but logically should be separated.
• JAXB schema imports create an ObjectFactory class than can be used to create other items from the schema. Unfortunately, this class is not as generic as I’d like – Frame2 tries to do a lot of generic introspection and not having a good all purpose factory has led me to write some creative code.

Ugly

• With previous versions of JAXB, Frame2 was able to perform on-demand validation of objects against the schema. This mechanism has been superceded in favor of using Schema objects for validation. The old validation mechanism is still around, but it;s marked deprecated and optional. Apparently in Java 6, “optional” means “blows up”. Trying to create an instance of the on-demand validator throws an UnsupportedOperationException. Trying to enable validation in the JAXB unmarshaller yields the same results. Unexpected results from an “optional” operation!
• The Frame2 JAXB infrastructure is one of those areas of the code I should spend more time in. Most of it hasn’t been touched since the product was named TurboM2, and I’m not convinced the TM2 guys followed “best” or even “pretty good” practices.