First of all, if you want a single manager object, tapestry provides
Application State Objects to do this. See
http://tapestry.apache.org/tapestry4/UsersGuide/state.html#state.aso for
more info. For a single instance of an ASO across an entire
application, you set the scope to "application" instead of "session".
This is tapestry's preferred way of doing things, but the problem is
that (I think) it's lazily initialized.
JMS: Check out spring (http://www.springframework.org). They've had JMS
send capabilities for a while now and I've (lightly) used them
successfully. Spring 2.0 was released earlier this week and now has
Message Driven POJOs (MDPs) - the receiver side of JMS. It sets up a
pool of asynchronous receivers for you
(http://static.springframework.org/spring/docs/2.0.x/reference/jms.html).
A coworker of mine is starting to play with these and we're optimistic
that it'll eliminate our last reason to use an EJB container. If you're
using Spring, they provide a servlet filter that you can configure in
your web.xml to load the spring context when the app initializes. I
know I'm contradicting my first paragraph, but a spring context is also
a great place to construct your manager object and JMS config - no
worries about lazy initialization here.
Threads are messy and really hard to get right. This isn't specific to
servlets, just in general. That's why many people try to avoid them.
Personally, I'm more comfortable with a well-tested library to manage
threads for me.
Tapestry does a lot of things right, but it sounds like a good chunk of
your project is better covered by Spring's problem domain. Fortunately,
they play nice together.
-Steve
Dave Rathnow wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
