commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@gmail.com>
Subject Re: [chain] New interface: CatalogFactory
Date Tue, 05 Oct 2004 20:42:40 GMT
On Tue, 05 Oct 2004 16:27:09 -0400, Sean Schofield
<sean_schofield@schof.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message