Making Tapestry's HiveMind registry available from a singleton or even JNDI?

[Jonas Maurus <jo...@gmail.com>]

Hi everybody

I have a bit of an architectural problem to solve.

I currently can't think of a reason why Tapestry's HiveMind registry
cannot be static. (I might also just be stupid and about to
single-thread my whole application ;-).) According to the servlet
2.4-spec there should only be one instance of the ApplicationServlet
around anyway.

I'm working on a project that will have multiple servlets that provide
different methods of access (not all HTTP based). All of these need
access to DAOs that are configured via HiveMind and are also used in
the Tapestry-based front-end application.

I could initialize multiple HiveMind registries, which I understand
might be an expensive operation and there are also services involved
that shouldn't exist multiple times (a scheduling service for
example), so that might not be the best option. I could also expose
the ApplicationServlet's registry.

Which is ultimately better?
And if I expose the ApplicationServlet's registry, should I expose it
from a ThreadLocal or statically by providing my own
ApplicationServlet-implementation?

The real winner of course might be a Tomcat ResourceFactory that puts
a registry into JNDI thus allowing other services like Message-Driven
Beans to easily access services and reimplementing Tapestry's
ApplicationServlet to use this. It all comes back to my first
question: can the registry be static?

Thanks for your help and thoughts!
Jonas

PS: The application will not run without the Tapestry-part, so I'm not
worried about decoupling everything if it helps performance-wise or
keeps the resource-usage down.

PSS: I'm still in the position to rewrite the services that currently
wouldn't work well if multiple instances of them existed, so I might
rewrite the scheduler to keep track of its jobs through a database
avoiding duplicate jobs. Or I might just use Quartz. So don't worry
about suggesting a solution that affects this.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

Re: Making Tapestry's HiveMind registry available from a singleton or even JNDI?

[Howard Lewis Ship <hl...@gmail.com>]

The HiveMind registry is stored into the servlet context, for access by
non-Tapestry code.

It can't be stored statically, because there will always be the possibility
of one WAR or one app server containing multiple Tapestry applications; each
needs its own Registry.

On 11/4/06, Jonas Maurus <jo...@gmail.com> wrote:
>
> Hi everybody
>
> I have a bit of an architectural problem to solve.
>
> I currently can't think of a reason why Tapestry's HiveMind registry
> cannot be static. (I might also just be stupid and about to
> single-thread my whole application ;-).) According to the servlet
> 2.4-spec there should only be one instance of the ApplicationServlet
> around anyway.
>
> I'm working on a project that will have multiple servlets that provide
> different methods of access (not all HTTP based). All of these need
> access to DAOs that are configured via HiveMind and are also used in
> the Tapestry-based front-end application.
>
> I could initialize multiple HiveMind registries, which I understand
> might be an expensive operation and there are also services involved
> that shouldn't exist multiple times (a scheduling service for
> example), so that might not be the best option. I could also expose
> the ApplicationServlet's registry.
>
> Which is ultimately better?
> And if I expose the ApplicationServlet's registry, should I expose it
> from a ThreadLocal or statically by providing my own
> ApplicationServlet-implementation?
>
> The real winner of course might be a Tomcat ResourceFactory that puts
> a registry into JNDI thus allowing other services like Message-Driven
> Beans to easily access services and reimplementing Tapestry's
> ApplicationServlet to use this. It all comes back to my first
> question: can the registry be static?
>
> Thanks for your help and thoughts!
> Jonas
>
> PS: The application will not run without the Tapestry-part, so I'm not
> worried about decoupling everything if it helps performance-wise or
> keeps the resource-usage down.
>
> PSS: I'm still in the position to rewrite the services that currently
> wouldn't work well if multiple instances of them existed, so I might
> rewrite the scheduler to keep track of its jobs through a database
> avoiding duplicate jobs. Or I might just use Quartz. So don't worry
> about suggesting a solution that affects this.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>


-- 
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com