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
