This is solved in Marko's branch. I had a talk with him about it yesterday, he said he still has some minor issues he wants to discuss (will post on the forum). Scott, I remember you promising you'll have a look at it. ;-) and try it out tonight. He's also missing NoCopy feature, but said he'll look into it, how we currently do that, and how can be reused in his impl. I don't really see when people are modifying their jars @ runtime. The workaround here is of course exploded dir. :-) I wrote a test for this: - http://anonsvn.jboss.org/repos/jbossas/projects/vfs/trunk/src/test/java/o... Probably not the best test, but it exposes the problem. In its current state (see TODO), it exposes the problem with caching (JBVSF-2). To resolve JBVFS-7 I think we would need to implement a lot more: - http://www.jboss.com/index.html?module=bb&op=viewtopic&t=134200 Adrian explained a few things here: - http://www.jboss.com/index.html?module=bb&op=viewtopic&t=134177&a... I can look at this, but dunno how to test it. :-) Will Cygwin do the trick? I did this one today. ;-) - http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152255#... And Adrian added simple cache in classloading subproject. But I still think we should do this more generic, see my yesterday's email to this list: 'improving AS boot time' I agree. If we don't have all what we currently have, it's still a step back, despite the obvious/cool locking fix. But I'm sure Marko will surprise us again. ;-)

Ales Justin wrote: I've seen folks use this in development when they don't have proper dependency declarations (ie. JAR A depends on JAR B, JAR B is removed, then put in place again). So the development build instead keeps the existing JAR, but modifies internal contents. Yes, hacky, but worked best for their setup (they should have been using an EAR or exploded directory).

On Fri, May 23, 2008 at 4:27 PM, Scott Stark <sstark(a)redhat.com&gt; wrote: Tomcat uses the VFS right now (through a dir context implementation, which was very easy to do). The VFS would need an optional case sensitivity option (which would default to case insensitive, and would probably do nothing expect if based on straight files). The best way to implement it is normally to compare the path that is requested with the canonical path of the file (you already quoted the code in the forum topic). I think moving Tomcat away from the VFS would be bad. Another option would be to see if it is possible to hack something in the VFS dir context implementation that Tomcat uses (I'll look at the API that is exposed to see if it is possible). Rémy

On Tue, May 27, 2008 at 10:54 AM, Ales Justin <ales.justin(a)gmail.com&gt; wrote: Yes, there are some tests somewhere in Tomcat. I'll see if I can add them to the AS testsuite. I'll do some manual testing very soon to see what happens with the current code (the usual trick is to have a test.jsp file, and then access it through test.jSp so that it does not match *.jsp and accesses the source code instead; this demonstrates that you can get around mappings and security to access static files directly on a case insensitive filesystem). I wonder where else it could be useful. Classloading of individual .class files maybe ? Rémy

On Tue, May 27, 2008 at 2:47 PM, Ales Justin <ales.justin(a)gmail.com&gt; wrote: Probably not, as those are web tests, which look very similar to the ones from the Servlet TCK (deploy a WAR, make HTTP request, compare response with golden file). Rémy