Dave,
In Tapestry3, we have a web application that forks our custom threads,
nothing wrong with that. Jesse is right with Tapestry4, HiveMind does
many neat things for you. I've only had a chance to play around parsing
application configurations via a xml file. HiveMind would basically
parse xml data and create java objects for me using specified
rules/schema.
I'm not a HiveMind expert, but I believe ApplicationServlet reads all of
tapestry's HiveMind registries (simple xml files) upon start up. So you
can write your own xml file using HiveMind APIs, that would get parsed
upon ApplicationServlet start up and access your "services" whenever you
want in your app. Check out http://jakarta.apache.org/hivemind/ , there
is a lot of useful information and code examples there...
Good Luck,
Dennis
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]