Hi agree with Nick, Part of my motivation is to remove the need to compile and ship separate generated ClassDescriptor's when using SourceGenerated classes with Castor XML. Infact as each ClassDescriptor contains an anonymous inner class for each field the number of classes runs into thousands for us. Often meaning we have to allocate lots of memory to the class heap as a result. So parallel files (be they .java or .xml) do have an overhead, be it maintenance or in the above case class footprint. Using annotations simply brings two definitions together. I also agree that if you want different runtime behaviour annotations are not suitable.
Andy. -----Original Message----- From: Nick Stuart [mailto:[EMAIL PROTECTED] Sent: 15 July 2005 13:21 To: dev@castor.codehaus.org Subject: Re: [castor-dev] [XML] Are there existing systems for mapping via annotations? I do the same thing Gregory. I have a couple of objects that use several mapping files, and annotations would not be able to help with this case, at least in no way that I can tell. I was never starting this little project with the idea of getting rid of the XML files, but to add some convenience where we could. -Nick On 7/15/05, Jeremy Haile <[EMAIL PROTECTED]> wrote: > 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] > ------------------------------------------------- > > ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] ------------------------------------------------- The information in this message is confidential and may be legally privileged. It may not be disclosed to, or used by, anyone other than the addressee. If you receive this message in error, please advise us immediately. Internet emails are not necessarily secure. CODA does not accept responsibility for changes to any email which occur after the email has been sent. Attachments to this email may contain software viruses, which could damage your systems. CODA has checked the attachments for viruses before sending, but you should virus-check them before opening. ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
