njar is not magic, so if it allows jboss access to a nested jar, it must
have unpacked everything up to but perhaps not including that final jar.
To access it, maybe you need to add another njar:...(url)^/ to your url, or
maybe my accessor sucks. I'm not going to have time to remove it before
jbossone, so you still might be able to profitably get something working
with it.
david jencks
On 2002.03.20 17:15:08 -0500 Jules Gosnell wrote:
> David,
>
> As Jan said, njar only unpacks jars nested deeper than one level,
> otherwise it will
> just delegate to a jar: protocol url.
>
> I tried this fix, and unfortunately proved that this is the case. None of
> the jars
> that I was interested in end up being unpacked, because they are all one
> level
> down. I could hack njar further, to unpack everything, but then it would
> not be
> njar anymore. So I shall wait for Marc and you to resolve the situation.
>
> Please keep me posted,
>
>
> Jules
>
>
> David Jencks wrote:
>
> > On 2002.03.19 21:17:09 -0500 Jules Gosnell wrote:
> > > Aha !
> > >
> > >
> > > So I guess I have a couple of options :
> > >
> > > 1. hope that the njar folks will take pity on me, unpack the first
> level
> > > and let
> > > me dereference it....
> >
> > I didn't test it, and I'm not 100%sure of what you want/need, but is
> this
> > close? Do you want njar to unpack down to the level of jsp files?
> Right
> > now it stops with the final jar.
> >
> > You might need to append ^/ to your urls, or change the code not to
> strip
> > same.
> >
> > change Handler so map is static:
> >
> > protected static Map savedJars = new HashMap();
> >
> > public static File getFileForURL(URL url)
> > {
> > String file = url.getFile();
> > String embeddedURL = file;
> >
> > int pos = file.lastIndexOf(NJAR_SEPARATOR);
> > if (pos >= 0)
> > {
> > embeddedURL = file.substring(0, pos);
> > }
> >
> > if (embeddedURL.startsWith(PROTOCOL))
> > {
> > //System.out.println("Opening next nested jar: " +
> embeddedURL);
> > return (File) savedJars.get(embeddedURL);
> > }
> > return null;
> > }
> >
> > david jencks
> >
> > >
> > > 2. take my own local copy of any njars I need in Jasper's
> classpath.....
> > >
> > >
> > > This will be a problem for Tomcat as well.....
> > >
> > > I'm going to sleep on it.....
> > >
> > > It would be a shame to unpack everything when it can be run packed,
> but a
> > > shag for
> > > AbstractWebContainer to have to cache it's own local copies of every
> njar
> > > hooked
> > > into it's classloader hierarchy.....
> > >
> > >
> > > Catch you tomorrow,
> > >
> > >
> > > Jules
> > >
> > >
> > > Jan Bartel wrote:
> > >
> > > > Actually, the njar protocol handler doesn't unpack the contents to
> a
> > > > temp location for urls like:
> > > >
> > > > njar:file:.....^/blah.jar
> > > >
> > > > Only for urls like:
> > > >
> > > > njar:njar:file:...^/xxx.jar^/yyy.jar
> > > >
> > > > As all of the class loader urls for the JSP compile path are like
> > > > the former rather than the latter, then njar internals don't
> unpack.
> > > >
> > > > I suppose it would be possible to do a nasty hack like prepend
> another
> > > > "njar:" onto the front of an njar url and see if we could trick the
> > > > njar protocol handler into unpacking then accessing the temp file
> > > > location it creates ....
> > > >
> > > > Jan
> > > >
> > > > Jules Gosnell wrote:
> > > >
> > > > > No,
> > > > >
> > > > > i know about the njar problem - that was the next on the list.
> > > > >
> > > > > I'm not sure whether a public accessor has been added to allow
> you to
> > > convert
> > > > > njar->file (all the nested jars are unpacked into tmp and an
> index
> > > > > maintained), but there were plans afoot.
> > > > >
> > > > > Jules
> > > > >
> > > > >
> > > > > Jan Bartel wrote:
> > > > >
> > > > >
> > > > >>Jules,
> > > > >>
> > > > >>Furthermore, if you are intending using the URLs returned by the
> > > > >>AbstractWebContainer.getClassLoaderURLs(), then you are going to
> > > > >>run into the njar problem (ie jars within sars etc are not
> unpacked,
> > > > >>so there is no URL to a disk location), which is how we got into
> > > > >>this whole issue in the first place. Or have I misunderstood
> where
> > > > >>your question comes from ?
> > > > >>
> > > > >>Jan
> > > > >>
> > > > >>Jan Bartel wrote:
> > > > >>
> > > > >>
> > > > >>>Jules,
> > > > >>>
> > > > >>>I can see the javax.servlet.jar on the JSP classpath returned
> from
> > > > >>>AbstractWebContainer.getClassLoaderURLs - what jboss
> > > > >>>version are you using? Caveat: I haven't refreshed my tree in
> the
> > > > >>>last 3 days or so, so maybe there has been a recent change ...
> > > > >>>
> > > > >>>
> > > > >>>Jan
> > > > >>>
> > > > >>>Jules Gosnell wrote:
> > > > >>>
> > > > >>>
> > > > >>>>I am trying to crush the two JSP compile errors in this
> testsuite.
> > > > >>>>
> > > > >>>>The classpath for Jasper is being built by walking up the
> > > classloader
> > > > >>>>hierarchy from the WebApp to the top, passing each classloader
> to
> > > > >>>>AbstractWebContainer.getClassLoaderURLs(ClassLoader).
> > > > >>>>
> > > > >>>>My problem is that the javax.servlet.jar does not seem to have
> been
> > > > >>>>loaded by an immediate parent of my webapp's classloader.
> > > > >>>>
> > > > >>>>You will want a fixed width font to view this.
> > > > >>>>
> > > > >>>>
> > > > >>>>sun.misc.Launcher$ExtClassLoader@7d8483
> > > > >>>> |
> > > > >>>> |
> > > > >>>>sun.misc.Launcher$AppClassLoader@7fdcde
> > > > >>>> |
> > > > >>>> |
> > > > >>>>java.net.URLClassLoader@6930e2
> > > > >>>> |
> > > > >>>>
> > > > >>>>-------------------------------------------------------------------.....
> > > > >>>>
> > > > >>>>|
> |
> > > > >>>>org.jboss.system.UnifiedClassLoader@76949770
> > > > >>>>org.jboss.system.UnifiedClassLoader@806b8bd7
> (JAVAX.SERVLET.JAR)
> > > > >>>> |
> > > > >>>> |
> > > > >>>>java.net.FactoryURLClassLoader@5ef658
> > > > >>>> |
> > > > >>>> |
> > > > >>>>org.mortbay.http.ContextLoader (MY WEBAPP)
> > > > >>>>
> > > > >>>>
> > > > >>>>Consequently the servlet jar does not get onto the classpath
> and
> > > JSP
> > > > >>>>compilation fails.....
> > > > >>>>
> > > > >>>>
> > > > >>>>So what should happen here ?
> > > > >>>>
> > > > >>>>Should a UnifiedClassLoader return all it's siblings URLs as
> well -
> > > > >>>>they are all loaded into a flat scope and are available to each
> > > other,
> > > > >>>>are they not?
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>Thanks for your time,
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>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
> > >
> > >
> > > _______________________________________________
> > > 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
>
>
> _________________________________________________________
> 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
