Hi Ralf, Ralf Joachim wrote: > Hi Werner, > > TMR.Loader holds TMF and properties to allow lazy initialization of TM. > Another posibility to implement this would be to maintain TMF, > properties and initialized TM in different maps in TMR. It may also be > possible that another class (e.g. DatabaseRegistry, DatabaseContext) > could handle the lazy initialization. > > The only reason why someone would need that (lazy init of TM) could be > that he loads multiple jdo-conf ... So in that case, the JDO configurations would carry a name attribute, right, to distinguish them from each other ?
> with different TM but uses only one in > his application. With the lazy initialization of the TM's he prevents > failures from the other TM that could not be instantiated or looked up. Assuming that this would be on the same classloader (e.g. the class loader from a web application), would this really make sense ? I always thought that our users would like to be informed about any misconfigurations as soon as possible, i.e. at startup time, similar to mapping problems. > > Regards > Ralf > > Werner Guttmann schrieb: >> Hi, >> >> can anybody share his memories with me and explain to me what the >> purpose of this inner class is. I have now been staring at this class >> for some odd 15 minutes, and somehow I don't reach a conclusion. >> >> Anybody ? >> >> Regards >> Werner >> >> --------------------------------------------------------------------- >> 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
