Having one Registry instance in J2EE apps

[Klaas Waslander <K....@nl.tiscali.com>]

Hi,

I want to start using Hivemind for our reusable Java services across multiple projects. It abstracts nicely from specific J2EE mechanisms, and forces an abstract java-interface-only spec of each service.

Question is the following: RegistryBuilder.constructDefaultRegistry rebuilds the registry every time. That is not good if POJO's, servlets and JSPs use that to get service instances all the time.

For JSP/servlet environments there is the HiveMindFilter that provides one registry through a request attribute. That is not good enough, because I want to be able to get the same instance from POJO's as well, that have no knowledge of the servlet request.

My idea is the following:
- have a "HiveRegistry" class of myself, with a static getService method
- this method gets the registry and returns the service from it
- the way it gets the registry can be:
  a) static singleton in the same class
  b) registry instance from JNDI context, with a startup class registering the instance in JNDI

Option (a) works okay with webapps I think, as each webapp would generally get its own classloader, and as such its own instance in the static variable. Hot (re-)deployment could work then, have to test. Ideas?

Option (b) would mean a servlet context listener that would create the registry, put it in the webapp JNDI context, and the HiveRegistry class simply returning it from JNDI.

I am aiming for option a (naturally), however am not sure if it's the best one. Also am wondering if this can be incorporated in the Hivemind framework itself, instead of having to deal with this myself.

Looking forward to your input!

Regards,
Klaas Waslander


--
Klaas Waslander
Systems Architect
Tiscali NL
website: www.tiscali.nl

---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org

Re: Having one Registry instance in J2EE apps

[ac...@streber24.de]

I would suggest to use a combination of a) and b).
Hold the single instance of the registry in a singleton class, but
don't initialize it statically. It's better to provide a static method 
'setRegistry' which must be called on system initialization.
In a web application you can initialize the registry from a servlet 
(that is loaded on startup) or a context listener and store the registry 
instance by calling this method. Look at Case Study #1 for an example 
how to do this.
Redeployment (Tomcat) ist working without problems in my case.

Regards
Achim Huegen

Klaas Waslander wrote:
> Hi,
> 
> I want to start using Hivemind for our reusable Java services across multiple projects. It abstracts nicely from specific J2EE mechanisms, and forces an abstract java-interface-only spec of each service.
> 
> Question is the following: RegistryBuilder.constructDefaultRegistry rebuilds the registry every time. That is not good if POJO's, servlets and JSPs use that to get service instances all the time.
> 
> For JSP/servlet environments there is the HiveMindFilter that provides one registry through a request attribute. That is not good enough, because I want to be able to get the same instance from POJO's as well, that have no knowledge of the servlet request.
> 
> My idea is the following:
> - have a "HiveRegistry" class of myself, with a static getService method
> - this method gets the registry and returns the service from it
> - the way it gets the registry can be:
>   a) static singleton in the same class
>   b) registry instance from JNDI context, with a startup class registering the instance in JNDI
> 
> Option (a) works okay with webapps I think, as each webapp would generally get its own classloader, and as such its own instance in the static variable. Hot (re-)deployment could work then, have to test. Ideas?
> 
> Option (b) would mean a servlet context listener that would create the registry, put it in the webapp JNDI context, and the HiveRegistry class simply returning it from JNDI.
> 
> I am aiming for option a (naturally), however am not sure if it's the best one. Also am wondering if this can be incorporated in the Hivemind framework itself, instead of having to deal with this myself.
> 
> Looking forward to your input!
> 
> Regards,
> Klaas Waslander
> 
> 
> --
> Klaas Waslander
> Systems Architect
> Tiscali NL
> website: www.tiscali.nl


---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org