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
>
>
--
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
