tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darryl L. Miles" <dar...@netbauds.net>
Subject WIN32 anti-resource-locking support in 5.5.x, would a back port be acceptable ?
Date Thu, 16 Feb 2006 03:07:57 GMT

What is the chance of getting this feature supported in 5.0.x or 4.x to 
help developers using the WIN32 platform under an IDE ?  I'm not asking 
someone to do it, I can investigate and spend some time on it, but I'd 
like to understand the on going maintenance implications that has for 
you guys and me.

What would the arguments be for / against accepting patches to back port 
this feature ?

If against would it be feasible to reliably support this type of 
modification as external addon by dumping files into a classes directory 
to override distribution behavior ?  When I say reliably are there 
fairly solid internal interfaces to work to ?

Google found http://forum.springframework.org/showthread.php?t=19516 on 
a related thread that Costin explained the mechanics of the situation.  
Is it possible to see (even for a split second) a locked .class file in 
the WEB-INF/classes directory (the thread explains the trick is only 
used on resources inside jars) and if this is the case I think an IDE 
driven environment on WIN32 is able to hit this problem frequently.

Are there any unwanted side effects to using it, the documentation 
states there are, at http://tomcat.apache.org/faq/windows.html there are 
details.  Is there a technical reason / argument not to have the JSP 
reload side effect, if re-compilation is necessary for the temp/ dir 
copy to be deleted/replaced, if thats not possible then create a random 
filename and re-map that resource to that new file (requires class 
loader support).

I appreciate that some of this stuff is pure bloat in a production 
environment, is there a simple way to keep it out of the core 
distribution and put it into some sort of developer support addon 
package cleanly.  I want development to be a dream but production to be 
stable.

RFC

-- 
Darryl L. Miles


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


Mime
View raw message