The introduction of annotation-support in Castor would not break any support of using mapping XML files. Annotations are merely a convenience that allow you to attach meta-data to your code that describes how to map classes to XML files - they are one alternative for mapping classes to XML; the mapping XML files are another alternative.
The way Keith described adding annotations support is in the introspection code that examines classes to determine how to map them. This is already an alternative to mapping files and would simply be enhanced to support annotations (JAXB?). There are definitely situations where it is undesirable to have the mappings embedded in your source code, and you present a good example. On Fri, 15 Jul 2005 11:47:44 +0100, "Gregory Block" <[EMAIL PROTECTED]> said: > Just as a sidenote: > > We routinely take object trees from our DAO layer and render them, > using different mapping files, to different feeds and different feed > versions based on customer config and the actual feed being provided. > > I would *not* be amenable to any fundamental change that broke > Castor's ability to perform arbitrary, non-hardcoded XML generation; > this is one of our strong points, IMO - the ability to determine, on > the fly, an appropriate XML representation in code and serialise to > that representation, rather than one imposed by the developer at > class generation time, rather than force a lot of unwanted content > through an XSL transform just to receive a minimal subset of data. > > On 13 Jul 2005, at 14:16, Jeremy Haile wrote: > > > It sounds like your annotations are used to generate a Castor mapping > > XML file. JAXB actually works by reading the annotations at runtime - > > meaning that no XML file would be required at all. This would require > > Castor to be modified to support reading the annotations at runtime > > rather than reading the XML mapping file. In fact, perhaps the Castor > > introspection code could simply be modified to recognize the > > annotations > > when figuring out how to map "unmapped" classes. > > > ------------------------------------------------- > If you wish to unsubscribe from this list, please > send an empty message to the following address: > > [EMAIL PROTECTED] > ------------------------------------------------- > ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
