Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <4163039D.8010801@schof.com>
Date: Tue, 05 Oct 2004 16:27:09 -0400
From: "Sean Schofield" <sean_schofield@schof.com>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: [chain] New interface: CatalogFactory
References: <415C5D3E.7030809@schof.com>	
 <f8b39ace04100212266958c96c@mail.gmail.com>	
 <4162B1FE.6050000@schof.com>
 <f8b39ace04100510396eed8ebc@mail.gmail.com>
In-Reply-To: <f8b39ace04100510396eed8ebc@mail.gmail.com>
Content-Type: text/plain;
 charset=iso-8859-1;
 format=flowed
Content-Transfer-Encoding: 7bit

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? 

I was wondering if you think there is significant harm associated with 
not doing this?  Also, I take it that this is not an issue once you 
restart the server.

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?

sean


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org