Jim Marino wrote: > Hi Jeremy, > > Could you briefly enumerate what you see as the benefits to the StAX > framework over alternatives? >
The final straw that prompted me to do this was the amount of classloader wrangling we ended up doing in the Tomcat code a couple of weeks ago. We need to keep track of context classloader switching between loading the model and loading any application code. There is plenty of room for subtle errors to creep in. The SDO solution (actually this would be true of any XML->POJO binding) was fine when the logical model was an exact replica of the XML files. However, to support more logical unit testing (and other uses) the model has now shifted back to being more of a true configuration model. This means we can't just slurp the XML into objects and use them directly, we need to read in the POJOs and then run a transformation on them. This adds an additional phase to the load process that needs maintenance. Having a container system there able to manage the loaders means extending the model is easy - an extension just needs to contribute its model elements and a XML handler. There is no need to codegen a separate XML model and write a transformer. There is also only one extension registry rather than two (the SDO type registry and the SCDL loader registry). The XML handling is pluggable - it just uses the standard StAX APIs rather than internal hooks to our SDO implementation and/or EMF. A validating StAX parser can be used if required; semantic validation is still being performed in the model and builders. Code footprint is better as there is no intermediate form. Performance and memory footprint are probably better too. However, I don't see that as a major factor as we are only reading config data here (i.e. it's once per deployment not once per request). On the downside, StAX is a technology that may not be as familiar to people. However, I think it has enough similarity to DOM/SAX to be readily understood. It is also heavily used in Axis2 so we will be seeing it anyway. We will need to modify the parsing code if the XML changes whereas with SDO or another XML->POJO solution that would be handled by generation. However, the need to transform the model after load means that we have custom parsing code anyway just running on the POJOs (see SCDLModelContentHandler). That's what comes to mind - if anyone else can see any issues please let me know. -- Jeremy
