Re: Newbie question about ApplicationServlet
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: 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 ApplicationS
Re: Newbie question about ApplicationServlet
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: 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]
Re: Newbie question about ApplicationServlet
Jessie, I'm not sure what you're refering to. Do you mean creating threads or the process of initializing my background process, which may involve creating threads? Dave. - Original Message - From: "Jesse Kuhnert" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Wednesday, October 04, 2006 11:25 PM Subject: Re: Newbie question about ApplicationServlet Oh no... Don't do anything remotely like that. You want to go look at jakarta.apache.org/hivemind. It's a very powerful IoC container - and it's also what t4 is built on. You'll find almost any pattern (including thread per session ) available to you once you peek inside. Almost all of the core of Tapestry is broken up into easy to manage / inject services. On 10/4/06, Dennis Sinelnikov <[EMAIL PROTECTED]> wrote: 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] -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Newbie question about ApplicationServlet
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: 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]
Re: Newbie question about ApplicationServlet
Oh no... Don't do anything remotely like that. You want to go look at jakarta.apache.org/hivemind. It's a very powerful IoC container - and it's also what t4 is built on. You'll find almost any pattern (including thread per session ) available to you once you peek inside. Almost all of the core of Tapestry is broken up into easy to manage / inject services. On 10/4/06, Dennis Sinelnikov <[EMAIL PROTECTED]> wrote: 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] -- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
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]
