Hi Dennis,
The application we're writing is "bridging" topics across multiple JMS
servers. The
initialization involves creating and initializing all the necessary JMS
objects. Pretty
simple, really, which is why we decided to make this our first Tapestry
project.
There is a single "manager" object that manages the bridge, which is being
managed by
the UI. The manger object has to be created at application startup time so
I can't
rely on any UI events to do this process for me. Right now, I've created my
own
ApplicationServlet subclass to handle this process. I'm using async message
delivery
so all the thread creation is being handle by the JMS implementation, except
for some
threads I create to handle connection loss events.
I'm curious about handling threads inside a servlet. I know this is a bit
off topic
but, are there any problems with simply creating your own threads inside a
servlet
container or is there some magic that has to be done to ensure you don't
mess
things up? I've heard from a couple of people that there could be problems
with
managing your own threads. Is there any truth to this?
Thanks,
Dave.
----- Original Message -----
From: "Dennis Sinelnikov" <[EMAIL PROTECTED]>
To: <users@tapestry.apache.org>
Sent: Wednesday, October 04, 2006 9:14 PM
Subject: Re: Newbie question about ApplicationServlet
Hello Dave,
There is 1 instance of ApplicationServlet, with newer releases of tapestry
there is less and less things I can think of doing in the
ApplicationServlet. You can extend from
org.apache.tapestry.ApplicationServlet and create your own (perfectly ok
to do). In ApplicationServlet, usually you would do some global
configuration settings, resource allocation, fork threads, etc..
Without knowing too much about the application you're trying to develop,
you could fork threads in your ApplicationServlet that would do your
background processing and just clean them up in destroy(). I would not
recommend getting your ApplicationServlet instance, but perhaps develop
separate logic that would get triggered via a UI. This logic would do
monitoring/control and return response to the user via a UI. If you need
some global object or perhaps one of the threads that got forked upon
ApplicationServlet startup, consider having a pool of threads that have
the same purpose that you can just grab at any point...
Hope this helps,
Dennis
Dave Rathnow wrote:
I'm new to Tapestry and have just started working with it. My background
is WebObjects so
most of my question will come from that perspective.
The application I'm developing will be doing some background processing
with the UI providing
monitoring and control functions. In WebObjects, we would use an single
Application instance that is created when the web application is first
started. We would store the objects required to access and control the
back ground processing. This Application instance is then available in
in each request-response loop through a Session object, or through a
global static method.
Is this same model provided by the ApplicationServlet class in Tapestry?
Is there a single instance
of this object and if so, how can I get it? Is it common practice to
subclass this class and
then do all your own application specific logic in the derived class?
Thanks,
Dave.
---------------------------------------------------------------------
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]