Darryl L. Miles wrote:
> 
> 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.

There hasn't been a 5.0.x release for some time and I have not seen
any plans for one. Apart from the odd security fix, I have seen any
activity on 5.0.x either. The odds of there being another 5.0.x
release look to be rather slim at present.

antiJARLocking has already been backported to 4.1.x and will be
included in 4.1.32 which I am working towards at the moment. A patch
for antiResourceLocking will get looked at if there is sufficient need
for it. A test and/or use case (keep it simple but realistic) would
help here.

> What would the arguments be for / against accepting patches to back port
> this feature ?
A straight backport of the 5.5.x feature should be OK. Additional
functionality will need a justification.

> 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.
Depends which IDE you use, how you use it. I run on Win32 and rarely
hit this problem. When I have hit it, the antiJARLocking has been
sufficient to resolve it.

> 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).
Makes your dev environment more complex and more likely to break.

> 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.
Don't we all ;)

Seriously, anything that looks like bloat is unlikely to get included.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to