I think the TapestryApplicationServlet should build the registry and store it as a ServletContext attribute. In addition, the IEngine interface should include a property pointing to the shared Registry instance.
-- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com > -----Original Message----- > From: Harish Krishnaswamy [mailto:[EMAIL PROTECTED] > Sent: Sunday, September 14, 2003 7:58 PM > To: Jakarta Commons Developers List > Subject: Re: [HiveMind] I don like HiveMind.getDefault and > setDefault(Registry) > > > So, in a webapp environment what is the best place to hold > the registry? > Is it the Global? Or do you think pages will also be a part of the > registry that there will be no need at all for a registry reference, > that is of course after Tapestry is refactored? > > -Harish > > Howard M. Lewis Ship wrote: > > >I'm thinking you are right ... its the balance of convienience vs. > >correctness. Certainly, no service implementation should ever use > >HiveMind.getDefault() ... the BuilderFactory means they > never need to > >find out the registry at all. The idea was to provide a convienient > >place for application code to get at the registry, to get at > services. > > > >Still, I'm now leaning in your direction (removing it); it has the > >potential to cause too many problems once you introduce > class loaders > >and the like. > > > >-- > >Howard M. Lewis Ship > >Creator, Tapestry: Java Web Components > >http://jakarta.apache.org/tapestry > >http://jakarta.apache.org/commons/sandbox/hivemind/ > >http://javatapestry.blogspot.com > > > > > > > >>-----Original Message----- > >>From: Essl Christian [mailto:[EMAIL PROTECTED] > >>Sent: Friday, September 12, 2003 10:57 AM > >>To: [EMAIL PROTECTED] > >>Subject: [HiveMind] I don like HiveMind.getDefault and > >>setDefault(Registry) > >> > >> > >>The reason I don't like this is because I guess it can lead > >>to quite some > >>problems and it is not realy needed. > >> > >>Just imagine your app uses HiveMind and some api uses > >>HiveMind internally > >>but does not document (it is just internal why should it?). > >>Both register > >>with setDefault(). Than you have a problem which is not realy > >>easy to find. > >> > >>The same can happen everywhere where there are different > >>ClassLoaders. > >>Think of a tomcat setup where HiveMind is in the > >>RootClassLoader. Imagine > >>two different web-apps use HiveMinde (and I think this will > >>be no rare > >>case). Each registers its own Registry. Both will end up > sharing one > >>Registry and which one is more or less a matter of luck. This > >>is realy hard > >>to debug. > >> > >>Both Service and user code which use the getDefault() will be > >>more or less > >>useless. > >> > >>You also don't realy need the getDefault(). Services should take the > >>Registry to which they belong from the initialize() method or > >>let it set as > >>a property. And user code should provide its own way to > >>access its service. > >>A user defined static method could be enough (its not realy hard to > >>implement). > >> > >>So I want to recommend (because HiveMind is quite new) to > >>just remove the > >>methods or deprecate them, before users start using them. > >> > >> > >> > >>------------------------------------------------------------ > --------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
