Actually, it is exactly the internally unpacked tmp files from njar that is needed! What jasper wants on the class path are path references to classes/jars rather than URL references to them.
How hard would it be to get the njar stuff to return the path to the unpacked files? Jan David Jencks wrote: > Looks like a great idea to me. > > Incidently, jar already copies remote files to a local tmp copy and njar > takes this one step further. However, these still typically aren't the > .java or .class files you are apt to need, so it probably wouldn't do any > good to poke around in their local copies. > > david jencks > > On 2002.03.10 15:23:04 -0500 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 >> >> >> > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
