On 2002.03.10 16:21:14 -0500 Jan Bartel wrote: > 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?
I'm not exactly sure how to get to the njar Handler object. If you can do this, then it is one line of code: the Handler has a map from URLs to the File copies it creates. Maybe we could make the map static and use a static method? The class is in jboss common module, org.jboss.net.protocol.njar.Handler. david jencks > > 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 > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
