On Tue, 05 Oct 2004 16:27:09 -0400, Sean Schofield <[EMAIL PROTECTED]> wrote: > Craig, > > >I should have checked on the line endings before committing ... was it > >built on a Windows system with CR-LF? I checked it in on Unix. > > > > > > > I'm developing on a Windows machine. I think my IDE is adding Windows > line feed by default but preserves the end of line used by existing > files (which would explain why I don't have problems with patches.) > > >I'll apply the patch tonight, when I can reach the repository without > >my friendly corporate firewall in the way. > > > > > > > Thanks. I have the same problem here with CVS and subversion. I can't > even checkout or do updates which sucks. > > >* Leverage the fact that each web application has a unique class loader > > that can then be used as a map key to disambiguate the default catalog. > > The container guarantees to set up something called the "thread context > > class loader" before calling any code inside the webapp, so your getInstance() > > method could retrieve it like this: > > > > ClassLoader cl = Thread.currentThread().getContextClassLoader(); > > > > and use it as the key to a Map that contains the actual catalogs for that > > webapp. The biggest problem with this approach is cleaning up when > > the application is undeployed or reloaded ... you'll want something like a > > ServletContextListener whose contextDestroyed() method can call a > > cleanup to release all the catalogs for that webapp. > > > > NOTE: Commons Logging uses techniques like this. > > > > > I think I will go with this approach. What is the need for > ServletContextListener? Is this so that the resources associated with > the Catalog for a web application can be "released" after the > application is stopped? >
Yes, although if you have one for that purpose you might also use it to read your configuration information and set up the catalogs (i.e. like what ChainListener already does). > I was wondering if you think there is significant harm associated with > not doing this? Java doesn't have any API to unload classes. Therefore, when you reload a webapp, what the container does is throws away its reference to the class loader. If the app is well behaved, that will make all the classes and objects instantiated by that webapp into garbage that can be collected and reused. If your map of class loader -> catalog entries is not cleaned up, then there is still a live reference to the class loader, and hence live references to all the old objects. End result -- massive memory leak on every application reload. Not a good thing. Also, I take it that this is not an issue once you > restart the server. > That's correct. > Finally, while I like the idea of the ServletContextListener for clean > up, it seems like there is no way other than documentation to make sure > the cleanup takes place (since the listener needs to be deployed via the > web.xml file.) Should I provide an implementation of the > ServletContextListener as well for users to use for cleanup? > We could just add it to ContextListener, and extend the configuration processing to deal with multiple catalogs. > sean > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
