The reason njar was introduced in the first place was so that we could apply a security policy to the classes that are in a nested jar. Scott seems to have had some success doing that with njar and the sun jdk.
Regards, Hiram >From: "marc fleury" <[EMAIL PROTECTED]> >To: "Hiram Chirino" <[EMAIL PROTECTED]>, ><[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> >CC: <[EMAIL PROTECTED]> >Subject: RE: [JBoss-dev] Jasper problems - Eureka ! >Date: Mon, 11 Mar 2002 04:57:16 -0800 > >i haven't really delved into the njar stuff but at this point it seems we >are complicating the problem with it. > >can't we just unjar all the jars that arrive with web stuff and be done >with >problem? > >yes it will break the jsp if you don't have a filesystem but let's face it >running a webserver without a filesystem is not ideal, > >marcf > >|-----Original Message----- >|From: [EMAIL PROTECTED] >|[mailto:[EMAIL PROTECTED]]On Behalf Of Hiram >|Chirino >|Sent: Sunday, March 10, 2002 8:37 PM >|To: [EMAIL PROTECTED]; [EMAIL PROTECTED] >|Cc: [EMAIL PROTECTED] >|Subject: Re: [JBoss-dev] Jasper problems - Eureka ! >| >| >|The njar protocol only extracts jars out to temp files. So your >|*.jsp's and >|such will not be extracted by using njar. >| >|If you just intrested in getting the local path to the jar that contains >|your resources, I think you should be able to do something like: >| >|URL url = new URL("njar:file:/home/duke/duke.jar^/test.jsp"); >|JarURLConnection jarConnection = (JarURLConnection)url.openConnection(); >|String path = jarConnection.getJarFile().getName(); >| >|But if you do not want to go throught the trouble of opening the >|connection >|yourself, we can like David said provide a static method that you can call >|in to find out the what file the urls were mapped to. >| >|Regards, >|Hiram >| >| >|>From: David Jencks <[EMAIL PROTECTED]> >|>To: Jan Bartel <[EMAIL PROTECTED]> >|>CC: [EMAIL PROTECTED] >|>Subject: Re: [JBoss-dev] Jasper problems - Eureka ! >|>Date: Sun, 10 Mar 2002 17:29:54 -0500 >|> >|>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 >| >| >| >|_________________________________________________________________ >|Send and receive Hotmail on your mobile device: http://mobile.msn.com >| >| >|_______________________________________________ >|Jboss-development mailing list >|[EMAIL PROTECTED] >|https://lists.sourceforge.net/lists/listinfo/jboss-development > _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
