Hi, we will once we have made Castor 1.3 publically available. Right now, all resources are being invested into making 1.3 available.
If you need the replies earlier, please do consider taking up professional support. <personal comment> Investing 20+ hours unpaid a week to make Castor 1.3 shippable already stretches myself to my personal limit. And that limit is not a movable one. </personal comment> Regards Werner Guttmann Sanjeev Krishnan wrote: > Hi Werner, > > Could you please respond to my questions below. > > Thanks, > > -Sanjeev > > > ------------- Original Message > ---------------------------------------------------- > > Hi Werner, > > Thanks for your response. Please see my comments inlined below: > >> if I were you, I would stop worrying about Castor's use of reflection, >> as this is a one-time only penalty (as startup) if used correctly. > > One-time penalty of reflection for building the class descriptor is ok, > but using reflection for every get/set of a field while marshalling / > unmarshalling > seems slow, since there will be millions of get/set method calls. > What is the correct way to avoid reflection during marshalling / > unmarshalling ? > >> Let me ask you a few questions, though: >> >> a) Will you be using a mapping file ? >> b) Have you considered using the XML code generator to generate domain >> classes (and descriptor classes) from your XML schema(s) ? > > I'm starting with a set of Java classes which are already in use > by applications and cannot be changed. These Java classes > need to be persisted in an XML store. > I would prefer not to use a mapping file unless the default > Castor Java->XML mapping needs to be changed for some class. > >> c) Have you already looked at the documentation of the >> XMLClassDescriptorResolver ? > > Yes but it doesnt seem to provide a way to avoid using reflection > during marshalling / unmarshalling. > >> d) Are you using Spring, and would you like to integrate Castor with >> Spring ? > > No. > >> And how did you measure performance when comparing Castor to JAXB ? I >> find your questions very interesting, but you'd need to educate me a bit >> more about your environment, etc. > > I'm going by: > (a) The generally accepted wisdom that reflection is slow compared to > normal Java method calls. > (b) Performance numbers from comparisons done by others. > > Thanks much, > > -Sanjeev > > > > >> Date: Mon, 12 Jan 2009 21:05:29 +0100 >> From: [email protected] >> To: [email protected] >> Subject: Re: [castor-user] [XML] Non-reflective get/set >> >> Hi, >> >> any chances of resending your reply with proper indentation ? >> >> Regards >> Werner >> >> Sanjeev Krishnan wrote: >>> Hi Werner, Thanks for your response. Please see my comments inlined >>> below:>> if I were you, I would stop worrying about Castor's use of >>> reflection,> as this is a one-time only penalty (as startup) if used >>> correctly. One-time penalty of reflection for building the class >>> descriptor is ok, but using reflection for every get/set of a field >>> while marshalling / unmarshalling seems slow, since there will be >>> millions of get/set method calls.What is the correct way to avoid >>> reflection during marshalling / unmarshalling ?> Let me ask you a >>> few questions, though:>> a) Will you be using a mapping file ?> b) >>> Have you considered using the XML code generator to generate domain> >>> classes (and descriptor classes) from your XML schema(s) ? I'm >>> starting with a set of Java classes which are already in use by >>> applications and cannot be changed. These Java classesneed to be >>> persisted in an XML store.I would prefer not to use a mapping file >>> unless the default Castor Java->XML mapping needs to be changed for >>> some class.> c) Have you already looked at the documentation of the> >>> XMLClassDescriptorResolver ? Yes but it doesnt seem to provide a way >>> to avoid using reflectionduring marshalling / unmarshalling.> d) Are >>> you using Spring, and would you like to integrate Castor with> Spring >>> ? >>> >>> No. >>>>> And how did you measure performance when comparing Castor to JAXB >>>>> ? I> find your questions very interesting, but you'd need to >>>>> educate me a bit> more about your environment, etc. I'm going >>>>> by:(a) The generally accepted wisdom that reflection is slow >>>>> compared to normal Java method calls.(b) Performance numbers >>>>> from comparisons done by others. Thanks much, -Sanjeev>> >>>>> Regards> Werner>> Sanjeev Krishnan wrote:>>>> Hello,Is there >>>>> a way to configure Castor-XML to avoid using>> reflection tocall >>>>> get/set methods of objects during marshalling />> unmarshalling >>>>> ?Reflection is supposed to be slower in general>> compared >>>>> tocustom-generated code which calls the get/set methods.E.g.>> >>>>> it should be possible to generate FieldHandlers usingcglib / asm >>>>> />> BCEL at runtime, has anyone done that ?JAXB2.x seems to use >>>>> generated>> code to call fields rather thanusing reflection is >>>>> that the reason>> why JAXB2.0 is faster than Castor ?Castor >>>>> seems ideal for my project>> (in terms of ease of use)however >>>>> I'm trying to figure out if its>> performance will be as good as >>>>> JAXB.Thanks,-Sanjeev>> >>>>> _________________________________________________________________ > > > ------------- Original Message --------------------------------------- > > Hello, > Is there a way to configure Castor-XML to avoid using reflection to > call get/set methods of objects during marshalling / unmarshalling ? > Reflection is supposed to be slower in general compared to > custom-generated code which calls the get/set methods. > E.g. it should be possible to generate FieldHandlers using > cglib / asm / BCEL at runtime, has anyone done that ? > JAXB2.x seems to use generated code to call fields rather than > using reflection is that the reason why JAXB2.0 is faster than Castor ? > Castor seems ideal for my project (in terms of ease of use) > however I'm trying to figure out if its performance will be as good as > JAXB. > Thanks, > -Sanjeev > > ---------------------------------------------------------------------- > _________________________________________________________________ > Windows Live™: E-mail. Chat. Share. Get more ways to connect. > http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_allup_howitworks_012009 > --------------------------------------------------------------------- > 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
