Oops, I just came to realize that I posted the wrong link. Can you please have a look at
http://www.castor.org/xml-best-practice.html and (in my opinion) find answers to most of your questions. Regards Werer VitoAndolini wrote: > Werner, > > Thanks very much for the response and the suggestion. I did look at your > link, and have searched many other places on the web for advice on this > practice but have found none (including the link you provided). Perhaps I am > just missing something, but I did not see any advice on the best practice > for the instantiation of the Mapping and (Un)Marshaller classes (static vars > / instance vars / method vars). > > In your experience, what have you found to be the best practice? > > Grazie tanto, > Vito > > > Werner Guttmann wrote: >> Ciao, >> >> did you actually have a look at >> >> http://www.castor.org/xml-tips-tricks.html >> >> at all ? >> >> Werner >> >> VitoAndolini wrote: >>> Hello, I have a question regarding the best practice for instantiating >>> castor's Mapping and Unmarshaller classes. >>> >>> My initial thought is that if the Mapping instance is always loaded with >>> the >>> same xml file, and the Unmarshaller instance is always sets the same >>> instance of Mapping, we should try to minimize the creation of these >>> objects. >>> >>> If this is true, the anti-practice woiuld be to instantiate new Mapping >>> and >>> Unmarshaller objects with every request. The best practice would be to >>> make >>> these objects static, so that they are only created once for every class >>> that uses them. >>> >>> Is this correct? I notice that the Mapping class has a synchronized >>> method >>> "getResolver" - could this hurt performance if Mapping is static? Are >>> there >>> any other issues to consider when instantiating the Mapping and >>> (Un)Marshaller classes? >>> >>> Many Thanks... >> --------------------------------------------------------------------- >> 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
