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
 

Reply via email to