Jeremy, > > Just FYI, the JAXB 2.0 marshaller/unmarshaller has methods for the > > XMLStream* and XMLEvent* and such as well as those for InputSource, > > URL, InputStream, Source, etc.... I'm not sure if you care (since > > SDO is not JAXB), but I thought I'd mention it. > > This highlights the issue I was trying to avoid. As I read this (and I > confess ignorance with JAXB) it sounds like there is *one* > (un-)marshaller which has methods on it for different XML access APIs. > This means that an implementation has to support *all* these different > APIs - the "kitchen sink" approach that bloats the runtime footprint.
Well, I'm not sure if it's really "kitchen sink". It's basically all the formats that are part of the JDK (JDK 1.5) which is all the source objects, the DOM, the InputSource, the URL, etc... with the addition of StAX. For the most part, I think internally, (not really sure, I haven't looked at the code) all they do is wrapper whatever comes in with a StAX Event thing so the engine itself just uses StAX. The marshaller/unmarshaller just "wraps" the incoming stuff with the appropriate wrapper. For the most part, the XMLInputFactory (part of StAX) contains all the methods for converting from all the other formats to the appropriate StAX type. Thus, the JAXB runtime doesn't need to do much. (puts the "kitchen sink" burden on the StAX runtime, not the JAXB one) Obviously, that makes the JAXB runtime directly depend on StAX in ALL cases. I'm not sure that's what you want or not, although I would vote +1 to allowing that dependency. :-) Enjoy! -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED]
