Thanks, Jay, for putting things into context for us. With regards to using a MappingLoader to create (XML)CLassDscriptors from xdoclets, it does not really make a difference whether this is done at run-time or at compile-time or even earlier.
In other words, irrespective of these requirements, coming up with a new MappingLoader (specific to xdoclets) is the way to go forward. Thanks Werner Jay Goldman wrote: > Werner, thanks for the reply. > To some extent I see xdoclet tags as somewhat different things than > annotations. Since annotations live in the class file I see them as > intended for runtime processing as opposed to compile/pre-processing. > So, a MappingLoader using annotation values computing class descriptor > objects at runtime instaed of from a mapping file makes sense. > > But I was thinking more about pre-processing files (I guess either using > xdoclet tags or annotations from class files) and creating class/field > descriptor java source files obviating any need for runtime processing > of either a mapping file or annotations. > > Jay > > -----Original Message----- > From: Werner Guttmann [mailto:[EMAIL PROTECTED] > Sent: Monday, December 25, 2006 7:14 AM > To: [email protected] > Subject: Re: [castor-user] generating class descriptor files from > binding file > > Jay, > > please read in-line. > > Werner > > Jay Goldman wrote: >> When the project I am working on started using castor it was decided >> that xdoclet tags would be used to create castor mapping files. > A few days (weeks) ago, a decision has been taken that we (the > committers plus anybody willing to help us) will start to work on > implementing the JAXB 2.x specification. As part of this undertaking, we > will have to support loading mapping information from (Java 5) > annotations. I wonder whether this information is of any (additional) > value to you, though. > > Personally, I think that a new MappingLoader (please see below for an > explanation of what MappingLoaders are) could be added, and essentially > will be added as we progress through adding support for JAXB. I wonder, > though, whether this particular component could (and should) be added > earlier ... ;-). > >> There >> are no xsd files associated with the project. Essentially there are >> java data classes which needed xml representations. So the java source > >> is the 'primary' input, it defines the needed xml. >> >> So, we use xdoclet processing to generate mapping files. Multiple >> variants of the mapping files are needed due to subsets of the classes > >> being executed in different jvms with different classpaths (e.g., >> tomcat vs jboss). So the same classes need to have mapping information > >> put in multiple files and these multiple files need to be parsed >> (albet only >> once) the first time an object needs to be marshalled (or > unmarsalled). >> It is my understanding that when castor processes a mapping file it >> creates class descriptor objects, ... > Yes, correct. Both Castor JDO and XML internally use ClassDescriptor and > FieldDescriptor instances to represent mapping information, using either > JDO- and/or XML-specific 'dialects' of these. > >> so I was wondering if it wouldn't be >> better to just use class descriptor classes instead of mapping files? > Yes, I think it would. Here's why ... > >> However, to do this I would need a tool for either (a) processing >> xdoclet tags into class descriptor source or (b) taking a mapping file > >> and generating class descriptor source and I am not aware of any such > tool. > Nor am I, but that would be part of the exercise, whatever approach you > will be taking. For the JAXB support (annotations), we will have to add > a new MappingLoader instance that builds Class-/FieldDescriptors from > those annotations. And the same would be required to support xdoclets. > Does this make any sense ? >> Hopefully I am incorrect and someone can point me at a way I can >> create class descriptor source from my xdoclet-taged java source. >> >> thanks in advance, >> Jay Goldman >> > > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > > > > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
