Re: Such a thing as server startup class?
Greg Trasuk at [EMAIL PROTECTED] wrote: > Hi all: > > Yes, a good discussion. > > I puzzled over this for an application I wrote a while ago. After many > hours contemplating the servlet spec (2.2), I finally decided that if I > created an object and dropped it into the application context, it was > guaranteed to live as long as the servlet container. My logic was this: > - The servlet container can load/unload servlets at its pleasure > - A servlet marked "Load-on-startup" will be loaded and have its init() > method called when the container starts, even if its not mapped to a URL. > - Java won't finalize an instance so long as another instance or class has > a reference to it. > - The application context will maintain a reference to the instance. > - If the servlet container destroys the application context, it's probably > a sign that I should reinitialize everything anyway. > > Could some of the folks who are more familiar with the specs and > implementation comment on whether this logic is correct and portable to all > containers? It worked for the application under Tomcat 3.x, but I've always > had nagging doubts. All YES but the last two... You cannot be guaranteed that the container will maintain a reference until it dies... BUT at the same time, I haven't seen anyone doing the contrary... Pier
RE: Such a thing as server startup class?
Hi all: Yes, a good discussion. I puzzled over this for an application I wrote a while ago. After many hours contemplating the servlet spec (2.2), I finally decided that if I created an object and dropped it into the application context, it was guaranteed to live as long as the servlet container. My logic was this: - The servlet container can load/unload servlets at its pleasure - A servlet marked "Load-on-startup" will be loaded and have its init() method called when the container starts, even if its not mapped to a URL. - Java won't finalize an instance so long as another instance or class has a reference to it. - The application context will maintain a reference to the instance. - If the servlet container destroys the application context, it's probably a sign that I should reinitialize everything anyway. Could some of the folks who are more familiar with the specs and implementation comment on whether this logic is correct and portable to all containers? It worked for the application under Tomcat 3.x, but I've always had nagging doubts. Thanks, Greg Trasuk, President StratusCom Manufacturing Systems Inc. - We use information technology to solve business problems on your plant floor. http://stratuscom.ca > -Original Message- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Monday, August 06, 2001 8:51 PM > To: [EMAIL PROTECTED] > Subject: Re: Such a thing as server startup class? > > > > > On Mon, 6 Aug 2001, Erik Weber wrote: > > > > In a servlet 2.2 world, what most people do is declare a > servlet to be > > > and initialize things in the init() > method of that > > > servlet. This is relying on the container to never > unload that servlet > > > for the lifetime of the app (Tomcat doesn't unload > anything until shutdown > > > time), but it basically works. > > > > > > Craig McClanahan > > > > Good point. If the Servlet were to be unloaded, another > instance would > > need to be loaded right away. Is there any > (platform-independent) way > > to guarantee that at least one instance of a Servlet will always be > > loaded, even if it's not set up to handle HTTP requests? > > > > Sounds like time for my favorite URL reference - where to get > the spec so > you can look stuff like this up for yourself :-) > > http://java.sun.com/products/servlet/download.html > > On this particular issue, there is no such > platform-independent API. In > fact, the 2.2 and 2.3 specs explicitly remind you that you > *cannot* rely > on "servlet will stay loaded" behavior in a portable application. The > container is free (as far as the spec is concerned) to unload a loaded > servlet any time it feels like doing so. > > That was one of the primary reasons that application event > listeners were > added in 2.3 -- to give apps a portable mechanism that does > not rely on > non-guaranteed assumptions about servlet lifetime, or on container > specific implementation features. > > > -Erik > > > > > > Craig > >
Re: Such a thing as server startup class?
Thank you for all the thoughtful suggestions. I may or may not be able to talk my engineers into trying 4.0. :) -Erik "Pier P. Fumagalli" wrote: > Erik Weber at [EMAIL PROTECTED] wrote: > > > > The upshot of this is, that it might make the interceptor (startup class) > > solution more appealing, even though it isn't platform independent. That is, > > until Servlet 2.3 implementations are stable. > > > > Any thoughts? > > Well... You have to trust me on this one... But the Servlet 2.3 reference > implementation _is_ very stable :) (AKA, Tomcat 4.0! :) And so is the spec. > > Just consider it as a hint from a very close friend who has some insight > information :) > > Pier
Re: Such a thing as server startup class?
Erik Weber at [EMAIL PROTECTED] wrote: > > The upshot of this is, that it might make the interceptor (startup class) > solution more appealing, even though it isn't platform independent. That is, > until Servlet 2.3 implementations are stable. > > Any thoughts? Well... You have to trust me on this one... But the Servlet 2.3 reference implementation _is_ very stable :) (AKA, Tomcat 4.0! :) And so is the spec. Just consider it as a hint from a very close friend who has some insight information :) Pier
Re: Such a thing as server startup class?
On Mon, 6 Aug 2001, Erik Weber wrote: > This is a good discussion. > > I would like to introduce the question: How much work is it to undo > the platform dependency, How does one do this without insisting that all containers implement the same APIs with the same behavior? Oh, yeah, it's already been done in 2.3 with application event listeners. :-) > and is it worth the liability to take > advantage of a nice feature of the server? > That's always a "risk versus reward" tradeoff. If I were a malicious platform vendor, I'd do everything I could to encourage you to utilize my platform specific stuff and get locked in. On the other hand, I might be very customer-sensitive and want to provide you a bunch of cool features above and beyond the spec so that you can be productive ... but they only work on my platform. Whether it's worth the risk or not is totally up to you ... there's no pat answer. > Specifically, would the interceptor approach offer significant > benefits over the Servlet adapter approach? And how much work would it > involve (potentially) to adapt the interceptor approach to some other > unnamed platform if needed? > If the "unnamed platform" is open source, you could theoretically do this. If not, are you planning to decompile the bytecodes so that you see how it works, and then figure out how to hack the insides to use your additional functions? The only way to rely on a platform-independent feature is to have it in the spec. > -Erik > Craig > > > "Pier P. Fumagalli" wrote: > > > Filip Hanik at [EMAIL PROTECTED] wrote: > > > > > For Tomcat 3.x, you can create an interceptor to act as a startup class. > > > you can just configure it using the server.xml file, read more about this in > > > http://www.filip.net/tomcatbook/TomcatInterceptors.html > > > > Again, this would be unportable to other containers... My reasoning is that > > Erik needs some functionality for a web application that will allow his code > > to be 100% portable on all possible servlet containers. > > > > Using tomcat interceptors is exactly like using Weblogic's startup classes, > > unportable. That's why I'm not a fan of interceptors (or valves in Tomcat > > 4.0), or ANY other unportable feature. > > > > Pier > >
Re: Such a thing as server startup class?
> Sounds like time for my favorite URL reference - where to get the spec so > you can look stuff like this up for yourself :-) > > http://java.sun.com/products/servlet/download.html > > On this particular issue, there is no such platform-independent API. In > fact, the 2.2 and 2.3 specs explicitly remind you that you *cannot* rely > on "servlet will stay loaded" behavior in a portable application. The > container is free (as far as the spec is concerned) to unload a loaded > servlet any time it feels like doing so. > > That was one of the primary reasons that application event listeners were > added in 2.3 -- to give apps a portable mechanism that does not rely on > non-guaranteed assumptions about servlet lifetime, or on container > specific implementation features. > > Craig Indeed, I need to read the spec. (Hey, I've read JDBC and EJB at least :) Thanks for the help, though. The upshot of this is, that it might make the interceptor (startup class) solution more appealing, even though it isn't platform independent. That is, until Servlet 2.3 implementations are stable. Any thoughts? -Erik
Re: Such a thing as server startup class?
On Mon, 6 Aug 2001, Erik Weber wrote: > > In a servlet 2.2 world, what most people do is declare a servlet to be > > and initialize things in the init() method of that > > servlet. This is relying on the container to never unload that servlet > > for the lifetime of the app (Tomcat doesn't unload anything until shutdown > > time), but it basically works. > > > > Craig McClanahan > > Good point. If the Servlet were to be unloaded, another instance would > need to be loaded right away. Is there any (platform-independent) way > to guarantee that at least one instance of a Servlet will always be > loaded, even if it's not set up to handle HTTP requests? > Sounds like time for my favorite URL reference - where to get the spec so you can look stuff like this up for yourself :-) http://java.sun.com/products/servlet/download.html On this particular issue, there is no such platform-independent API. In fact, the 2.2 and 2.3 specs explicitly remind you that you *cannot* rely on "servlet will stay loaded" behavior in a portable application. The container is free (as far as the spec is concerned) to unload a loaded servlet any time it feels like doing so. That was one of the primary reasons that application event listeners were added in 2.3 -- to give apps a portable mechanism that does not rely on non-guaranteed assumptions about servlet lifetime, or on container specific implementation features. > -Erik > > Craig
Re: Such a thing as server startup class?
> In a servlet 2.2 world, what most people do is declare a servlet to be > and initialize things in the init() method of that > servlet. This is relying on the container to never unload that servlet > for the lifetime of the app (Tomcat doesn't unload anything until shutdown > time), but it basically works. > > Craig McClanahan Good point. If the Servlet were to be unloaded, another instance would need to be loaded right away. Is there any (platform-independent) way to guarantee that at least one instance of a Servlet will always be loaded, even if it's not set up to handle HTTP requests? -Erik
Re: Such a thing as server startup class?
Erik Weber at [EMAIL PROTECTED] wrote: > This is a good discussion. Indeed... > I would like to introduce the question: How much work is it to undo the > platform dependency, and is it worth the liability to take advantage of a nice > feature of the server? Depends on what you need to do... If all you need to do is create instances of objects for your web app, that's the way to go... If you're building a web app to control your servlet-container, DOH! you need to build around its APIs :) A wise approach when designing a web application is examine your requirements and see, wether it's worth to tie your app down to a container, or abstract above it... Every problem is different... > Specifically, would the interceptor approach offer significant benefits over > the Servlet adapter approach? And how much work would it involve (potentially) > to adapt the interceptor approach to some other unnamed platform if needed? Dunno much about interceptors and TC3x...
Re: Such a thing as server startup class?
On Mon, 6 Aug 2001, Erik Weber wrote: > Hello all. > > I have minimal experience with Tomcat, and didn't see any mention of this in > looking over the docs. > > I am used to developing in WebLogic. WebLogic supports what are called startup > classes. You register the name of the class in the server's properties file, > and when the server starts, it instantiates that class with arguments included > in the properties file. > > I have found this is a nice way to start up asynchronous subscribers to a > messaging queue. Upon instantiation, which again is automatic, the various > subscribers, in their constructors, simply register themselves as listeners > with the queue. > > I was wondering if Tomcat supports a similar construct as this (startup > classes). If not, perhaps I could implement my queue subscribers as Servlets, > but this seems strange, considering mulitple threads should not be running > through a single subscriber. > > Any thoughts or advice on this? > The servlet 2.3 spec (and, therefore, Tomcat 4) supports a portable mechanism for this kind of thing called "application event listeners". Using this, you can register (in web.xml) listeners that are notified when the application is started and shut down -- quite helpful for this sort of thing. In a servlet 2.2 world, what most people do is declare a servlet to be and initialize things in the init() method of that servlet. This is relying on the container to never unload that servlet for the lifetime of the app (Tomcat doesn't unload anything until shutdown time), but it basically works. > -Erik > > Craig McClanahan
Re: Such a thing as server startup class?
Erik Weber at [EMAIL PROTECTED] wrote: > > Pier, nice solution. Sort of a Servlet implementation of the adapter pattern. And it works on ALL servlet engines :) > So you're saying just make the service() method throw an exception, no > questions asked? Or use a filter that is not bound to any URL pattern (but that's only available on servlet 2.0). Check out the servlet spec (2.2 or 2.3, depending on what platform you need to need to deploy your app on). > Also, you were quick to fire off about portability, and I agree, but when you > work in a WebLogic shop . . . Well, it has some nice features. :) That's why you go off to a shop and but WebLogic for a few thousand $$$. :) > I hope to > discover Tomcat's strengths as well in the near future, now that my company > plans to use it in a limited production role as well. Tomcat is the R.I.. A very good one. Concerning API functionalities, Tomcat will provides few things (interceptors, valves). Other features are available and will be built in the future, but just remember the tradeoff of building on top of that, despite of relying on what's provided you by the platform (those APIs implemented by all vendors) > All, I would still be interested in hearing any other ideas on the "startup > class" problem. Pier
Re: Such a thing as server startup class?
This is a good discussion. I would like to introduce the question: How much work is it to undo the platform dependency, and is it worth the liability to take advantage of a nice feature of the server? Specifically, would the interceptor approach offer significant benefits over the Servlet adapter approach? And how much work would it involve (potentially) to adapt the interceptor approach to some other unnamed platform if needed? -Erik "Pier P. Fumagalli" wrote: > Filip Hanik at [EMAIL PROTECTED] wrote: > > > For Tomcat 3.x, you can create an interceptor to act as a startup class. > > you can just configure it using the server.xml file, read more about this in > > http://www.filip.net/tomcatbook/TomcatInterceptors.html > > Again, this would be unportable to other containers... My reasoning is that > Erik needs some functionality for a web application that will allow his code > to be 100% portable on all possible servlet containers. > > Using tomcat interceptors is exactly like using Weblogic's startup classes, > unportable. That's why I'm not a fan of interceptors (or valves in Tomcat > 4.0), or ANY other unportable feature. > > Pier
Re: Such a thing as server startup class?
Filip Hanik at [EMAIL PROTECTED] wrote: > For Tomcat 3.x, you can create an interceptor to act as a startup class. > you can just configure it using the server.xml file, read more about this in > http://www.filip.net/tomcatbook/TomcatInterceptors.html Again, this would be unportable to other containers... My reasoning is that Erik needs some functionality for a web application that will allow his code to be 100% portable on all possible servlet containers. Using tomcat interceptors is exactly like using Weblogic's startup classes, unportable. That's why I'm not a fan of interceptors (or valves in Tomcat 4.0), or ANY other unportable feature. Pier
RE: Such a thing as server startup class?
For Tomcat 3.x, you can create an interceptor to act as a startup class. you can just configure it using the server.xml file, read more about this in http://www.filip.net/tomcatbook/TomcatInterceptors.html Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect [EMAIL PROTECTED] www.filip.net >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf >Of Erik Weber >Sent: Monday, August 06, 2001 4:24 PM >To: [EMAIL PROTECTED] >Subject: Re: Such a thing as server startup class? > > >Pier, nice solution. Sort of a Servlet implementation of the >adapter pattern. So >you're saying just make the service() method throw an exception, >no questions >asked? > >Also, you were quick to fire off about portability, and I agree, >but when you work >in a WebLogic shop . . . Well, it has some nice features. :) I >hope to discover >Tomcat's strengths as well in the near future, now that my company >plans to use it >in a limited production role as well. > >All, I would still be interested in hearing any other ideas on the >"startup class" >problem. > >-Erik > > > >"Pier P. Fumagalli" wrote: > >> Erik Weber at [EMAIL PROTECTED] wrote: >> >> > Hello all. >> > >> > I have minimal experience with Tomcat, and didn't see any >mention of this in >> > looking over the docs. >> > >> > I am used to developing in WebLogic. WebLogic supports what >are called startup >> > classes. You register the name of the class in the server's >properties file, >> > and when the server starts, it instantiates that class with >arguments included >> > in the properties file. >> > >> > I have found this is a nice way to start up asynchronous >subscribers to a >> > messaging queue. Upon instantiation, which again is automatic, >the various >> > subscribers, in their constructors, simply register themselves >as listeners >> > with the queue. >> > >> > I was wondering if Tomcat supports a similar construct as this (startup >> > classes). If not, perhaps I could implement my queue >subscribers as Servlets, >> > but this seems strange, considering mulitple threads should >not be running >> > through a single subscriber. >> > >> > Any thoughts or advice on this? >> >> That's what you get when you rely on features specific to a >specific Servlet >> container... My advice would be to use all your object as is, and have a >> servlet overriding the service() method throwing an HTTP error, >and so use >> the init() and destroy() methods in that servlets to instantiate all your >> objects... You can use servlet properties to provide the class names and >> mimic the behavior of Weblogic, but then your web application will be >> portable to any compliant servlet container. >> >> Oh, and, of course, remember to initialize the servlet at startup :) >> >> Being "the" reference implementation, I wouldn't want to >populate Tomcat's >> core with unportable features. If it runs under Tomcat, it runs >everywhere >> :) >> >> Pier > >
Re: Such a thing as server startup class?
Pier, nice solution. Sort of a Servlet implementation of the adapter pattern. So you're saying just make the service() method throw an exception, no questions asked? Also, you were quick to fire off about portability, and I agree, but when you work in a WebLogic shop . . . Well, it has some nice features. :) I hope to discover Tomcat's strengths as well in the near future, now that my company plans to use it in a limited production role as well. All, I would still be interested in hearing any other ideas on the "startup class" problem. -Erik "Pier P. Fumagalli" wrote: > Erik Weber at [EMAIL PROTECTED] wrote: > > > Hello all. > > > > I have minimal experience with Tomcat, and didn't see any mention of this in > > looking over the docs. > > > > I am used to developing in WebLogic. WebLogic supports what are called startup > > classes. You register the name of the class in the server's properties file, > > and when the server starts, it instantiates that class with arguments included > > in the properties file. > > > > I have found this is a nice way to start up asynchronous subscribers to a > > messaging queue. Upon instantiation, which again is automatic, the various > > subscribers, in their constructors, simply register themselves as listeners > > with the queue. > > > > I was wondering if Tomcat supports a similar construct as this (startup > > classes). If not, perhaps I could implement my queue subscribers as Servlets, > > but this seems strange, considering mulitple threads should not be running > > through a single subscriber. > > > > Any thoughts or advice on this? > > That's what you get when you rely on features specific to a specific Servlet > container... My advice would be to use all your object as is, and have a > servlet overriding the service() method throwing an HTTP error, and so use > the init() and destroy() methods in that servlets to instantiate all your > objects... You can use servlet properties to provide the class names and > mimic the behavior of Weblogic, but then your web application will be > portable to any compliant servlet container. > > Oh, and, of course, remember to initialize the servlet at startup :) > > Being "the" reference implementation, I wouldn't want to populate Tomcat's > core with unportable features. If it runs under Tomcat, it runs everywhere > :) > > Pier
Re: Such a thing as server startup class?
Erik Weber at [EMAIL PROTECTED] wrote: > Hello all. > > I have minimal experience with Tomcat, and didn't see any mention of this in > looking over the docs. > > I am used to developing in WebLogic. WebLogic supports what are called startup > classes. You register the name of the class in the server's properties file, > and when the server starts, it instantiates that class with arguments included > in the properties file. > > I have found this is a nice way to start up asynchronous subscribers to a > messaging queue. Upon instantiation, which again is automatic, the various > subscribers, in their constructors, simply register themselves as listeners > with the queue. > > I was wondering if Tomcat supports a similar construct as this (startup > classes). If not, perhaps I could implement my queue subscribers as Servlets, > but this seems strange, considering mulitple threads should not be running > through a single subscriber. > > Any thoughts or advice on this? That's what you get when you rely on features specific to a specific Servlet container... My advice would be to use all your object as is, and have a servlet overriding the service() method throwing an HTTP error, and so use the init() and destroy() methods in that servlets to instantiate all your objects... You can use servlet properties to provide the class names and mimic the behavior of Weblogic, but then your web application will be portable to any compliant servlet container. Oh, and, of course, remember to initialize the servlet at startup :) Being "the" reference implementation, I wouldn't want to populate Tomcat's core with unportable features. If it runs under Tomcat, it runs everywhere :) Pier
