You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Essl Christian <ju...@esslchristian.de> on 2003/09/12 16:57:21 UTC
[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.
RE: [HiveMind] I don like HiveMind.getDefault and setDefault(Registry)
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
At this point, I don't think a service should ever need to implement Initializable.
I may remove the ServiceExtensionPoint parameter from Initializable; it's dangerous (gives access to
the registry).
In fact, looking at the code, I think I can wall the "user" (the developer using HiveMind) off from
the ServiceExtensionPoint and friends entirely ... unless they chose to use a backdoor such as a
static variable somewhere.
--
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:jucas@esslchristian.de]
> Sent: Friday, September 12, 2003 1:14 PM
> To: Jakarta Commons Developers List
> Subject: Re: [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.
>
> > 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.
> >
>
> Thank you! I am realy glad to hear that. And you are right
> static accessors
> are convinient, but sometimes also dangerous.
>
> It is also good that you mentioned that a Service does not need the
> Registry at all. I am still a bit slow in getting used to the
> power of the
> BuilderFactory :)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
Re: [HiveMind] I don like HiveMind.getDefault and setDefault(Registry)
Posted by Essl Christian <ju...@esslchristian.de>.
>> The reason I don't like this is because I guess it can lead to quite
>> some problems and it is not realy needed.
> 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.
>
Thank you! I am realy glad to hear that. And you are right static accessors
are convinient, but sometimes also dangerous.
It is also good that you mentioned that a Service does not need the
Registry at all. I am still a bit slow in getting used to the power of the
BuilderFactory :)
RE: [HiveMind] I don like HiveMind.getDefault and setDefault(Registry)
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
Global would work for a Tapestry 3.0 app.
For Tapestry 3.1, HiveMind will be integral to the framework.
--
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:hkrishnaswamy@comcast.net]
> Sent: Monday, September 15, 2003 9:46 AM
> To: Jakarta Commons Developers List
> Subject: Re: [HiveMind] I don like HiveMind.getDefault and
> setDefault(Registry)
>
>
> Thanks, I am not so familiar with clusters either, this is
> for my education.
>
> I still wondering, though, why Global is not a good place, after all
> Globals are context attributes also and Tapestry manages them
> pretty well.
>
> -Harish
>
> Christian Essl wrote:
>
> >>What if you had two applications running under the
> >>same context though?
> >>
> >>
> >I guess they should have (as recommended by the
> >servlet-spec) have attribute names like
> >[package-name].HiveMindRegistry. (Of course if you mean two
> >Tapestry apps you will have to find another way).
> >
> >
> >
> >>And how will replication be taken care of, I thought
> >>context attributes
> >>are not replicated in a clustered environment.
> >>
> >>
> >
> >As I see the war is distributed and on each node it
> >will be started up seperately. Therefore the ServletContextListener.
> >However I am not so common with clusters.
> >
> >
> >
> >
> >>And,yes the
> >>constructDefaultRegistry will definitely be helpful.
> >>
> >>-Harish
> >>
> >>
> >>
> >
> >
> >__________________________________________________________________
> >
> >Gesendet von Yahoo! Mail - http://mail.yahoo.de
> >Logos und Klingeltöne fürs Handy bei http://sms.yahoo.de
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> >
> >
>
Re: [HiveMind] I don like HiveMind.getDefault and setDefault(Registry)
Posted by Harish Krishnaswamy <hk...@comcast.net>.
Thanks, I am not so familiar with clusters either, this is for my education.
I still wondering, though, why Global is not a good place, after all
Globals are context attributes also and Tapestry manages them pretty well.
-Harish
Christian Essl wrote:
>>What if you had two applications running under the
>>same context though?
>>
>>
>I guess they should have (as recommended by the
>servlet-spec) have attribute names like
>[package-name].HiveMindRegistry. (Of course if you
>mean two
>Tapestry apps you will have to find another way).
>
>
>
>>And how will replication be taken care of, I thought
>>context attributes
>>are not replicated in a clustered environment.
>>
>>
>
>As I see the war is distributed and on each node it
>will be started up seperately. Therefore the
>ServletContextListener. However I am not so common
>with clusters.
>
>
>
>
>>And,yes the
>>constructDefaultRegistry will definitely be helpful.
>>
>>-Harish
>>
>>
>>
>
>
>__________________________________________________________________
>
>Gesendet von Yahoo! Mail - http://mail.yahoo.de
>Logos und Klingeltöne fürs Handy bei http://sms.yahoo.de
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
RE: [HiveMind] I don like HiveMind.getDefault and setDefault(Registry)
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
On each server in the cluster, the initialization will be done identically, in parallel, resulting
in equivalent registries.
Christian is right; to support multiple apps in a single context, it is necessary to use qualified
servlet context attribute names.
--
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: Christian Essl [mailto:christianessl@yahoo.de]
> Sent: Monday, September 15, 2003 9:39 AM
> To: Jakarta Commons Developers List
> Subject: Re: [HiveMind] I don like HiveMind.getDefault and
> setDefault(Registry)
>
>
> > What if you had two applications running under the
> > same context though?
> I guess they should have (as recommended by the
> servlet-spec) have attribute names like
> [package-name].HiveMindRegistry. (Of course if you mean two
> Tapestry apps you will have to find another way).
>
> > And how will replication be taken care of, I thought
> > context attributes
> > are not replicated in a clustered environment.
>
> As I see the war is distributed and on each node it
> will be started up seperately. Therefore the
> ServletContextListener. However I am not so common with clusters.
>
>
> > And,yes the
> > constructDefaultRegistry will definitely be helpful.
> >
> > -Harish
> >
>
>
> __________________________________________________________________
>
> Gesendet von Yahoo! Mail - http://mail.yahoo.de
> Logos und Klingeltöne fürs Handy bei http://sms.yahoo.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
Re: [HiveMind] I don like HiveMind.getDefault and setDefault(Registry)
Posted by Christian Essl <ch...@yahoo.de>.
> What if you had two applications running under the
> same context though?
I guess they should have (as recommended by the
servlet-spec) have attribute names like
[package-name].HiveMindRegistry. (Of course if you
mean two
Tapestry apps you will have to find another way).
> And how will replication be taken care of, I thought
> context attributes
> are not replicated in a clustered environment.
As I see the war is distributed and on each node it
will be started up seperately. Therefore the
ServletContextListener. However I am not so common
with clusters.
> And,yes the
> constructDefaultRegistry will definitely be helpful.
>
> -Harish
>
__________________________________________________________________
Gesendet von Yahoo! Mail - http://mail.yahoo.de
Logos und Klingeltöne fürs Handy bei http://sms.yahoo.de
Re: [HiveMind] I don like HiveMind.getDefault and setDefault(Registry)
Posted by Harish Krishnaswamy <hk...@comcast.net>.
What if you had two applications running under the same context though?
And how will replication be taken care of, I thought context attributes
are not replicated in a clustered environment. And, yes the
constructDefaultRegistry will definitely be helpful.
-Harish
Howard M. Lewis Ship wrote:
>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:hkrishnaswamy@comcast.net]
>>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:jucas@esslchristian.de]
>>>>Sent: Friday, September 12, 2003 10:57 AM
>>>>To: commons-dev@jakarta.apache.org
>>>>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: commons-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
RE: [HiveMind] I don like HiveMind.getDefault and setDefault(Registry)
Posted by Christian Essl <ch...@yahoo.de>.
Yes, I would agree with this and generally would suggest to hold the registry in the ServletContext. I think the ServletContext is thought for this. I actually use as ContextListener which builds the Registry up when my web-app is started.
"Howard M. Lewis Ship" <hl...@comcast.net> wrote:
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.
---------------------------------
Gesendet von http://mail.yahoo.de
Schneller als Mail - der neue Yahoo! Messenger.
RE: [HiveMind] I don like HiveMind.getDefault and setDefault(Registry)
Posted by Christian Essl <ch...@yahoo.de>.
Yes, exactly.
Like:
public static Registry constructDefaultRegistry(){
ClassResolver resolver = new DefaultClassResolver();
RegistryBuilder builder = new RegistryBuilder();
builder.processModules(resolver);
Registry registry = builder.constructRegistry(Locale.getDefault());
return registry;
}
(At the moment I am just not at my computer. So I have to send it this way).
"Howard M. Lewis Ship" <hl...@comcast.net> wrote:
So, you mean something like
public static Registry constructDefaultRegistry();
on class HiveMind?
That's not a bad idea at all.
--
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
---------------------------------
Gesendet von http://mail.yahoo.de
Schneller als Mail - der neue Yahoo! Messenger.
RE: [HiveMind] I don like HiveMind.getDefault and setDefault(Registry)
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
So, you mean something like
public static Registry constructDefaultRegistry();
on class HiveMind?
That's not a bad idea at all.
--
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: Christian Essl [mailto:christianessl@yahoo.de]
> Sent: Monday, September 15, 2003 8:36 AM
> To: Jakarta Commons Developers List
> Subject: RE: [HiveMind] I don like HiveMind.getDefault and
> setDefault(Registry)
>
>
> I was now thinking about why I did not like getDefault(). I
> think the real (Freud'schen) reason was that the first time I
> saw it I expected it to be something I could get a default
> registry from. (You know I was eagar to try it out, had my
> head full with the new stuff and didn't want to go through
> the setup things).
>
> Of course bootstraping is well documented now and it is easy.
> But I think the same still applies to new users and the most
> prominent class is now a bit naked.
>
> So I'd like to propose a static factory method which just
> builds up a default new Registry (read all modules from the
> Context ClassLoader). I think this would also save cut/paste
> for many uses.
>
>
>
>
>
>
> ---------------------------------
> Gesendet von http://mail.yahoo.de
> Schneller als Mail - der neue Yahoo! Messenger.
>
RE: [HiveMind] I don like HiveMind.getDefault and setDefault(Registry)
Posted by Christian Essl <ch...@yahoo.de>.
I was now thinking about why I did not like getDefault(). I think the real (Freud'schen) reason was that the first time I saw it I expected it to be something I could get a default registry from. (You know I was eagar to try it out, had my head full with the new stuff and didn't want to go through the setup things).
Of course bootstraping is well documented now and it is easy. But I think the same still applies to new users and the most prominent class is now a bit naked.
So I'd like to propose a static factory method which just builds up a default new Registry (read all modules from the Context ClassLoader). I think this would also save cut/paste for many uses.
---------------------------------
Gesendet von http://mail.yahoo.de
Schneller als Mail - der neue Yahoo! Messenger.
RE: [HiveMind] I don like HiveMind.getDefault and setDefault(Registry)
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
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:hkrishnaswamy@comcast.net]
> 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:jucas@esslchristian.de]
> >>Sent: Friday, September 12, 2003 10:57 AM
> >>To: commons-dev@jakarta.apache.org
> >>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: commons-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >>
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> >
> >
>
Re: [HiveMind] I don like HiveMind.getDefault and setDefault(Registry)
Posted by Harish Krishnaswamy <hk...@comcast.net>.
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:jucas@esslchristian.de]
>>Sent: Friday, September 12, 2003 10:57 AM
>>To: commons-dev@jakarta.apache.org
>>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: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
RE: [HiveMind] I don like HiveMind.getDefault and setDefault(Registry)
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
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:jucas@esslchristian.de]
> Sent: Friday, September 12, 2003 10:57 AM
> To: commons-dev@jakarta.apache.org
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>