I do use castordoclet. However, the use of a mapping file requires that I have multiple mapping files to handle use of castor in different contexts. We have code running in tomcat and in jboss which have different classpaths, so some classes that are 'visible'(loadable) to the code running in jboss are not 'visible' to the code running in tomcat, you can't have a reference to a 'non-visible' class in a mapping file, even if you do not reference it (the code which processes the mapping file has to be able to process all the classes mentioned in the mapping file). Given other aspects of our application, I wind up with 6 mapping files which contain a significant amount of overlap. Whereas I would only need one instance of a class descriptor class and it would be used in whatever context referenced it.
-----Original Message----- From: Werner Guttmann [mailto:[EMAIL PROTECTED] Sent: Sunday, January 07, 2007 6:50 AM To: [email protected] Subject: Re: [castor-user] generating class descriptor files from binding file Thanks, James. That your post remindes me that we should try to get the tools section of the HTML docs up-to-date ... Werner James Abley wrote: > We use castordoclet [1] to generate mapping files from doclet tags in > the Java source. This might be worth looking at. > > Cheers, > > James > > [1] http://castordoclet.sourceforge.net/ > > Kuns, Edward wrote: >> From: Jay Goldman [mailto:[EMAIL PROTECTED] >>> 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 >> >> Nope, it has an internal representation of Java class structure (in >> org.exolab.javasource and org.exolab.castor.builder) and builds the >> class structure class by class, method by method, and when completed, >> writes these class objects out to disk as *.java files. But it >> doesn't truly build a "descriptor object" which is then serialized to >> disk as Java source. >> >> Currently, the source generator is designed around the assumption >> that it is processing an XSD schema, optionally as modified by a >> binding file. This can change, of course, but it's where the code is today. >> >> Eddie >> >> --------------------------------------------------------------------- >> 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
