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
