One advantage, for me at least, would be not having to have 6 different mapping files. I need multiple mapping files due to multiple execution environments, i.e., jvm executions with different class loaders with different classpaths. A reference to a non-loadable class causes the processing of the mapping file to fail - which makes sense, but means i have to create a different mapping file for each 'logical subset' of classes. Since (a) xdoclet processing is slow and (b) processing large mapping files is slow it just makes my build/test cycles longer. Admittedly, the mapping file processing time is irrelevant for a production environment as its only done once - but it would simplify my build process, etc. to only have to build a class/field descriptor file for each class and then let castor load them as needed.
I haven't looked at the implementation of the source generator, but i was hoping that it built class/file descriptor objects and then generated the java, but from Ralf's comment that doesn't sound like the way it works so using it as a basis for creating java from xdoclets probably is not the way to go. Looks like i might have to re-use the code which creates objects from mapping files and generate the java that way. jay -----Original Message----- From: Ralf Joachim [mailto:[EMAIL PROTECTED] Sent: Wed 12/27/2006 5:00 AM To: [email protected] Subject: Re: [castor-user] generating class descriptor files from binding file As far as I understand, Jay thought of a modification to source generator that creates descriptor classes only out of xdoclets. While this would also be possible to implement, it seams to be more difficult then the MappingLoader. And, in my opinion, there would be no advantage of the compiled descriptors over the MappingLoader as Werner suggested. Ralf Werner Guttmann schrieb: > 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 --------------------------------------------------------------------- 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
