tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Funk <funk...@joedog.org>
Subject Re: [5] hotfixes
Date Fri, 18 Jul 2003 15:11:05 GMT
Yeah, I am scared of side effects too. This funtionality will be helpful in 
the following situations:
- My previous post where the access log doesn't print '+' in front of the offset
- ExtendedAccessLogValve printed the date instead of bytes (recent patch)
- The recent Connector fixes we have seen for SSL related issues
- JDBC, JNDI realm fixes
- Misc valve or clustering fixes

In all of the above - they are for bug fixes that don't warrant an immediate 
release. They are usually for fringe cases where it makes tomcat a PITA to 
use if not fixed.

If one chooses not to use this feature, then the current functionality stays 
the same.

The patch I have in mind will not include the webapp classloader. Since the 
spec doesn't seem to define a jar order - I prefer not to impose one.

Currently a user has 2 workarounds:
- Take the milestone source tree and apply the patches and build
- Build from HEAD
- Place the fix in XXX/classes

The first two scenarios is a lot of work and very risky since other 
unintended changes can easily be introduced. (At least the HEAD method is)
The third scenario can be hard to maintain from an admin point of view if the 
user also uses their own classes in the lib directory.

I also like Martin 's idea of possibly introducing another directory called 
lib-hotfix. That seems cleaner and clearer than a date (or file) based sort.

-Tim

Shapira, Yoav wrote:
> Perhaps I'm misinterpreting what small patches are, though?  Did you
> have examples in mind?  I think it's the component owner's
> responsibility to provide the fix/patch, and to do so in the manner best
> fitting the component.  In most java cases, I think that's an updated
> jar.  If the fix requires many jars, then probably the product wasn't
> properly divided into modular jars to start with.



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


Mime
View raw message