Heiko, I use generated classes for all of my xml generation, and have had no problems. However, let me point out that I care less about adhering to a specified schema than I do about simply generating xml from an object that can be reinstantiated. The performance has been more than acceptable, but I have also made some efforts to maintain a simple object model (Parent objects containing collections of children objects, no more than probably 2 levels deep. I am also always marshalling using the generated class descriptors and never with reflection or a special mapping file.
Also, the getters and setters that you were mentioning - aren't they already generated using the source code generation? Hope thats helpful - Margaret -----Original Message----- From: Heiko Erhardt [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 16, 2002 12:03 PM To: [EMAIL PROTECTED] Subject: Re: [castor-dev] Collection access / Mapping performance Hi Margaret, thanks for the hint, I'll give that a try. As it sounds, this might be usable as a solution to my other posting concerning default setters/getters also. BTW: What are your experiences concerning stability and performance of Castor, especially when it comes to large quanitiies or highly complex XML structures? Reflection access was pretty slow once - In JDK 1.1 times, we once had our own mapping framework which also built havily on reflections. We had to replace it agains a code-generation based XML serialization framework due to performance reasons. Cheers, Heiko Erhardt skynamics AG www.skynamics.com > -----Original Message----- > From: Martin, Margaret [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 16, 2002 5:14 PM > To: [EMAIL PROTECTED] > Subject: Re: [castor-dev] Collection access > > > Heiko - > Actually, this is a really nice place to start understanding the castor code > base. Take a look at org.exolab.castor.builder.CollectionInfo - especially > #createAccessMethods... what I've done is subclass CollectionInfo and > extended this method to provide the additional functionality that I wanted. > You can then create an extension of FieldInfoFactory that uses your > CollectionInfo class for source generation (there is a property in > castor.properties where you specify this class)... > > Good luck! > > Margaret Martin > > -----Original Message----- > From: Heiko Erhardt [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 16, 2002 9:38 AM > To: [EMAIL PROTECTED] > Subject: [castor-dev] Collection access > > > For access to collection objects, Castor expects methods like > > <CollectionType> get<Name> () > set<Name> (<CollectionType> collection) > > Since Iterators came into vogue and since one of the ideas of > object-oriented > programming is encapsulation of implementation details, many classes tend to > expose iterators and adder methods only. > > I would suggest to support access methods like > > Iterator get<Name> () > add<Name> (<Type> value) > > Haven't found anything in the docs. > Sorry for not implementing it myself, but since I'm pretty new to Castor, > I don't want to dive right into the product's core at this point. > > Thanks, > > Heiko Erhardt > skynamics AG > www.skynamics.com > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
