You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Remy Maucherat <re...@apache.org> on 2005/02/16 13:04:24 UTC
5.5.8 ?
Hi Yoav,
What do you think about the idea of doing a 5.5.8 ?
The list of fixes gets longer, and there were actually two regressions
in 5.5.7:
- JSP precompilation with taglibs in some cases
- DataSource realm connection leaking; the fix needs testing
My latest deployer changes need testing as well, as it would be good to
avoid regressions.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: 5.5.8 ?
Posted by Dominik Drzewiecki <dr...@post.pl>.
Dominik Drzewiecki wrote:
>>The list of fixes gets longer, and there were actually two regressions
>>in 5.5.7:
>>- JSP precompilation with taglibs in some cases
>>- DataSource realm connection leaking; the fix needs testing
>
> I did some testing in a webapp I currently develop. And the fixed
> DataSourceRealm seems to work. No more leaking - at least the Realm returns
> all leased connections to the pool. However I observe increasing number of
> database backends after several subsequent redeployments. Since the
> datasource defined in application's context.xml serves connections to both
> DataSourceRealm as well as the application itself (Hibernate Session, to be
> exact), I suspect that there's something wrong with the DataSource cleanup
> peformed on undeployment. I'll look into it today evening. Any
> thoughts/suggestions are welcome.
I confirm, that the new DataSourceRealm is not a source of
aforementioned leaked connections. The real origin of the leak was the
fact that the Spring ContextLoaderListener couldn't properly release all
the beans on undeploy/stop as the context parameters have been removed
before listener's contextDestroyed() invocation. AFAIK this has also
been fixed (bug 33463)
FYI, I tested DataSourceRealm with PostgreSQL 8.0.
regz,
/dd
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: 5.5.8 ?
Posted by Dominik Drzewiecki <dr...@post.pl>.
Remy Maucherat <re...@apache.org> erote:
> Hi Yoav,
>
> What do you think about the idea of doing a 5.5.8 ?
Good idea.
>
> The list of fixes gets longer, and there were actually two regressions
> in 5.5.7:
> - JSP precompilation with taglibs in some cases
> - DataSource realm connection leaking; the fix needs testing
I did some testing in a webapp I currently develop. And the fixed
DataSourceRealm seems to work. No more leaking - at least the Realm returns
all leased connections to the pool. However I observe increasing number of
database backends after several subsequent redeployments. Since the
datasource defined in application's context.xml serves connections to both
DataSourceRealm as well as the application itself (Hibernate Session, to be
exact), I suspect that there's something wrong with the DataSource cleanup
peformed on undeployment. I'll look into it today evening. Any
thoughts/suggestions are welcome.
regz,
/dd
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: 5.5.8 ?
Posted by Remy Maucherat <re...@apache.org>.
Yoav Shapira wrote:
> Hi,
> I think 5.5.8 is a good idea, but I'd like to address the following first:
> - 6582 SERVLETAPI: Sample code does not match behavior
> - 33224 when webapp config file and directory URL is specified, d...
> (this one may already be addressed by your deployer changes)
I think I disagree with this bug. Supplying both a war and a config file
will always be risky, especially if stupid values are in the context file.
> - 33362 setclasspath.bat missing @echo off
> - 33448 wrong policy in $CATALINA_BASE/conf/catalina.policy
> - 33219 Slight code improvement
This seems potentially risky.
> - 32382 First App -> Example App is misleading
> - 33325 add target "clean" to top-level build.xml
>
> All should be fairly easy, I don't have karma for the first, but I'll look
> at the others as I have time. If others fix them first, great ;)
>
> So let's maybe plan for this Saturday for 5.5.8?
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: 5.5.8 ?
Posted by Yoav Shapira <yo...@MIT.EDU>.
Hi,
I think 5.5.8 is a good idea, but I'd like to address the following first:
- 6582 SERVLETAPI: Sample code does not match behavior
- 33224 when webapp config file and directory URL is specified, d...
(this one may already be addressed by your deployer changes)
- 33362 setclasspath.bat missing @echo off
- 33448 wrong policy in $CATALINA_BASE/conf/catalina.policy
- 33219 Slight code improvement
- 32382 First App -> Example App is misleading
- 33325 add target "clean" to top-level build.xml
All should be fairly easy, I don't have karma for the first, but I'll look
at the others as I have time. If others fix them first, great ;)
So let's maybe plan for this Saturday for 5.5.8?
Yoav
> -----Original Message-----
> From: Remy Maucherat [mailto:remm@apache.org]
> Sent: Wednesday, February 16, 2005 7:04 AM
> To: tomcat-dev@jakarta.apache.org
> Subject: 5.5.8 ?
>
> Hi Yoav,
>
> What do you think about the idea of doing a 5.5.8 ?
>
> The list of fixes gets longer, and there were actually two regressions
> in 5.5.7:
> - JSP precompilation with taglibs in some cases
> - DataSource realm connection leaking; the fix needs testing
>
> My latest deployer changes need testing as well, as it would be good to
> avoid regressions.
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org