I see your point, Jan. However, even if JBoss supplies us with file: urls, Jasper will still need the WAR unpacked so it can get at the JSPs (Greg, when I said .java in my previous mail I meant .jsp).
My solution, will sort this as well, since .jsps will also be picked up by getResource(). I agree with Greg that some other project SHOULD pick up this work. However, since they haven't, it might not be a bad idea for me to pick this up and play with it for a little. I figure that I can put together a very naive version fairly painlessly. Less painfully, in fact, than having to continually explain the problem on various lists/fora and provide a stream of half hearted attempts at a proper Jasper integration. Furthermore, if it works, it gives JBoss/Jetty an extra win - we can run all apps packed. Since it is not really a production problem (as discussed), a really naive caching approach would probably work (I'm sure URL will probably be caching the whole lot underneath me anyway). I'm going to give it a couple of hours this evening and see how far I get and what problems I uncover. Speak to you soon, Jules Jan Bartel wrote: > Let's consider bang for buck, or effort for reward: how much effort is > it going to be for JBoss to provide a "real" path for items in an njar > format (ie really making their AbstractWebContainer > getCompileClasspath() method *really* return a compilable classpath > rather than a bunch of URLs) versus implementing Jules' undoubtedly > groovy solution? > > In my effort v reward calculation, I'm factoring in that what we are > *in fact* trying to solve here is a development-time problem only: JSPs > in production are usually pre-compiled (speed and undesirability of > having javac on production machines). > > So, my calculator says: > > Fix JBoss getCompileClasspath() v ResourceBasedCompilerAdaptor > small effort:sufficient reward v big effort:sufficient reward > > Jan > > Greg Wilkins wrote: > > > > > Jules, > > > > I guess this is the ultimate solution - ie a compiler that takes URLs > > in the classpath. As that has not been forthcoming from jikes, sun or > > whatever - then your wrapper idea is one way of providing it. > > > > But a couple of notes: > > > > + No matter what we do about unpacking, we have to remove any code > > from anywhere that does new File(url.getPath()) or equivalent. > > This is just not portable and never will be. This code needs to > > be replaced NOW - before any unpacking solution is put in place. > > > > + I don't think we need to look for *.java files as resource. While a > > cool idea - it is the *.jsp files that are resources and *.java files > > are generated in temporary directories. > > > > + A simple initial solution could do away with the whole cache thing. > > On every compile the classpath can be unpacked, converted to a file > > classpath and then discarded after the compile. OK it will run > > slowly, but it is simple and will be able to test the idea first up. > > > > > > No matter what, your wrapper idea is a fair bit of work. My > > preferred solutions in priority order are: > > > > 1) Ban all use of JSPs :-) > > 2) Only support precompiled JSPs :-| > > 3) Provide a unpack everything option in JBoss > > 4) Get the compiler writers (jikes et al?) to support URLs > > 5) Get the jakarta folks to write your wrapper > > 6) Get the JBoss folks to write your wrapper. > > 7) You can write your wrapper > > 8) Somebody suggest that the jetty people write the wrapper. > > > > cheers > > > > > > Jules Gosnell wrote: > > > >>I was giving Jasper and all the related unpacking problems some thought > >>in the car on the way home this evening and reckon I have a nice, simple > >>solution to all our woes (and Tomcat's, if they are interested...). > >> > >>Jasper supports pluggable compilers. > >> > >>We simply write a ResourceBasedCompilerAdaptor Compiler. > >> > >>This has 3 main features : > >> > >>1. it understands URLs on it's classpath. Any non-file: URL is treated > >>as a resource available to > >>Thread.currentThread().getContextClassLoader(), copied into a cache, and > >>replaced on the classpath with a file: URL to the copy. > >> > >>2. when looking for the .java file that it is being asked to compile, as > >>well as looking in the file system, it will try getting the file as a > >>resource from Thread.currentThread().getContextClassLoader(), copying it > >>into the same cache and substituting the original filename with a new > >>one pointing to the copy. > >> > >>3. It wrap-n-delegates to the actual required compiler - javac, jikes > >>etc. Which may then painlessly compile away, oblivious to the fact that > >>it is running in a resource based, rather than file-based, environment. > >> > >> > >>Anyone see any problems ? > >> > >>I reckon that with this, we can forget all those painful unpacking > >>problems, whilst still being able to run apps that are already unpacked, > >>with no overhead. > >> > >>At the same time the code maintains compatibility with future versions > >>of Jasper (unless they change the compiler API) whilst having no > >>dependencies on ServletContainer or AppServer. > >> > >>Lastly, a URL->file cache may come in useful for local caching of remote > >>resources, if JBoss or Jetty does not already contain one...... > >> > >>Before you ask, I haven't given any thought to timing out the cache, but > >>it should be possible to check the date on the remote resource shouldn't > >>it (do I need 1.4 to do this?). > >> > >>Jules > >> > >> > >> > >>_________________________________________________________ > >>Do You Yahoo!? > >>Get your free @yahoo.com address at http://mail.yahoo.com > >> > >> > >> > > > > > > > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
