Re: A Resource ObjectFactory as LifecycleListener ?
On Mon, Dec 13, 2004 at 08:50:18AM -1000, Seth Ladd wrote: : >Another alternative would be to externalize the service itself onto a : >separate server, so you don't need to worry about shutting it down at : >all ;) : : Well, that's kind of what we do now. We expose the service via Hessian, : so that all webapps can access it (and avoid classloading issues of : implementation classes). I was hoping to avoid the overhead and expose : as regular classes via JNDI. You have a tradeoff here: "overhead" vs "scalability/maintainability." I'm a big fan of the latter, especially given that you may have trouble getting your singleton to exist on multiple machines when your app grows. ;) -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A Resource ObjectFactory as LifecycleListener ?
Shapira, Yoav wrote: Hi, So while we could put all the classes into common/lib and use a singleton pattern, I wouldn't have a way to cleanly shut down the service on app server shutdown (I could be wrong here). You could use a JVM shutdown hook. At least that's portable and not Tomcat-specific. Another alternative would be to externalize the service itself onto a separate server, so you don't need to worry about shutting it down at all ;) Well, that's kind of what we do now. We expose the service via Hessian, so that all webapps can access it (and avoid classloading issues of implementation classes). I was hoping to avoid the overhead and expose as regular classes via JNDI. Seth -- http://www.picklematrix.net/foaf.rdf";>Seth Ladd's FOAF http://www.foaf-project.org/";>What is FOAF? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: A Resource ObjectFactory as LifecycleListener ?
Hi, >So while we could put all the classes into common/lib and use a >singleton pattern, I wouldn't have a way to cleanly shut down the >service on app server shutdown (I could be wrong here). You could use a JVM shutdown hook. At least that's portable and not Tomcat-specific. Another alternative would be to externalize the service itself onto a separate server, so you don't need to worry about shutting it down at all ;) Yoav Shapira http://www.yoavshapira.com This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A Resource ObjectFactory as LifecycleListener ?
Shapira, Yoav wrote: Hi, Why go through all this? The point of the JNDI Resources part of the Servlet Specification is to allow portable interaction with external resources. Your approach loses all the portability (it's Tomcat-specific) without gaining much of anything. You could do the same stuff in your webapp, instead relying on a portable notification of app shutdown (ServletCotnextListener) and managing your own object creation/destruction. Good question. Because we have a few services we'd like shared between all webapps. While you are correct that getting the service into JNDI is Tomcat specific (which is why I'm pulling for a writable JNDI context :), getting the service out from JNDI is standard. So while we could put all the classes into common/lib and use a singleton pattern, I wouldn't have a way to cleanly shut down the service on app server shutdown (I could be wrong here). Seth -- http://www.picklematrix.net/foaf.rdf";>Seth Ladd's FOAF http://www.foaf-project.org/";>What is FOAF? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: A Resource ObjectFactory as LifecycleListener ?
Hi, Why go through all this? The point of the JNDI Resources part of the Servlet Specification is to allow portable interaction with external resources. Your approach loses all the portability (it's Tomcat-specific) without gaining much of anything. You could do the same stuff in your webapp, instead relying on a portable notification of app shutdown (ServletCotnextListener) and managing your own object creation/destruction. Yoav Shapira http://www.yoavshapira.com >-Original Message- >From: Seth Ladd [mailto:[EMAIL PROTECTED] >Sent: Monday, December 13, 2004 1:10 PM >To: [EMAIL PROTECTED] >Subject: A Resource ObjectFactory as LifecycleListener ? > >Hello, > >I've setup a ObjectFactory for Tomcat's JNDI and Resource system. I'd >like that that ObjectFactory to respond to the Tomcat Server shutting >down. It appears that a new ObjectFactory is created for every request >for the Object, so ObjectFactory itself is not a singleton. That's OK >for now. > >The Object that is returned by the ObjectFactory is a singleton (in a >sense) and I'd like that Object to shutdown cleanly when the Server >shuts down. > >One idea I had was to create a that would shut down the >singleton. The ObjectFactory would continue to serve the singleton via >JNDI. The problem there is I might have to duplicate some class files >because the will load its classes from server/lib, while the >ObjectFactory will load its classes from common/lib. > >If I could have the or the ObjectFactory participate as a >LifecycleListener, I think it would work very smoothly. I looked >through the code, and it doesn't appear possible. > >Thanks, >Seth > >-- >http://www.picklematrix.net/foaf.rdf";>Seth Ladd's FOAF >http://www.foaf-project.org/";>What is FOAF? > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
