Hi all, I think this would be a good FAQ point.
> Hi Tim! > > It is certainly possible to store the metadata anywhere you want - the >TypeDesc.getTypeDescForClass() > method is the control point there. Right now we look for a) inline static metdata, >and b) a "Helper" class > which contains the metadata. This could easily be extended to include scanning for >an XML or a > properties file. > > The TypeDesc class contains XML <-> Java databinding information in a >well-structured form. The > BeanInfo class just gives you name/value pairs, so we'd still need to come up with >some kind of data > structure to store the actual information about mapping fields/properties to XML >elements/attributes even > if we got that data from BeanInfo classes. We've discussed getting the TypeDesc >from a BeanInfo > structure, but haven't gone there yet. > > In terms of publishing existing beans without modifying them, this works fine in >that a) the default > serialization will apply to beans with no metadata (all public fields represented as >XML elements, and I > think the schema uses <all>) and b) we support external metadata in the form of a >Helper class right > now, and may support other file-based formats in the future. > > TypeDesc/FieldDesc should expand to handle capturing more of what schema can do > (all/sequence/choice/etc), and we also hope to include a constraint system at some >point to support > schema restriction types with limited value sets. > > As for "Axis-specific", any XML<->Java databinding framework (JAXB, Castor, Axis) is >going to be > proprietary right now, in that the metadata gets read by some tool that is >deserializing or serializing XML > in some custom way. It may be that this stuff gets standardized (that's where JAXB >is trying to go, for > instance), but we're not there yet. Until a standard we like better arrives, we're >going to try to make Axis > do this as efficiently and simply as we can. It's also the plan at some point to >tease the databinding > framework away from the rest of Axis so that it can be used independently from, as >well as in concert > with, the SOAP/Handler stuff. > > --Glen > > -----Original Message----- > From: Tim Blake [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 23, 2002 6:52 AM > To: [EMAIL PROTECTED] > Subject: JavaBeans and metadata > > Hi, > > Could somebody please give me a summary of the design decisions taken vis-a-vis >storing > metadata inline with generated complexTypes? I appreciate that this has >already been the > subject of some discussion (and maybe even disagreement ;-)) and I'm genuinely >trying to > understand, not just rock the boat... > > - Why do you store metadata inline, as opposed to in separate files (or maybe >this is > possible as well)? > - Why do you use "org.apache.axis.description.TypeDesc" for describing metadata >on > JavaBeans, rather than the existing BeanInfo framework? Is this intended to be >more > generic than BeanInfo, since it can be used in other contexts? How does this >"proprietary" > metadata layer affect the use case where people want to publish existing >JavaBeans > without modifying them? > My real interest here is in solving the problem of mapping the XML schema >comparators all > | sequence | choice into Java in the best possible non-AXIS-specific way. This >isn't so > much a question of "interoperability" as "uniformity" of solution. If you've >discussed this to > death previously then please point me to the relevant posts. If not, what do >y'all think? > > Thanks, > Tim >
