Hhmm, I have just written the compiler shell, and if my JBoss was working would have had it running by now - so I could answer your question.
IF I get it running AND the classpath contains no URLs AND the sourcefile is a simple filepath THEN I will stick in a trivial URL->FILE cache and try it ELSE - forget it ! Jules Greg Wilkins wrote: > Narrow band reply, as I am not sure about this..... > > I think jasper already gets the jsps as URLs and/or resources. > That's why last modified does not work unless it is using jdk1.4.... > > cheers > > Jules Gosnell wrote: > > 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 > > > > > > -- > Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)7092063462 > Mort Bay Consulting Australia and UK. Mbl Phone: +61-(0)4 17786631 > http://www.mortbay.com AU Phone: +61-(0)2 98107029 > > _______________________________________________ > 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
