On 1/3/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
What do you mean with ignore the classloader?
Neither UrlResourceStreamLoader nor FileResourceStreamLoader are
explicitly using a classLoader. Of course they use a ClassLoader, but
implicitly such as
url.openStream() or new FileInputStream(File). Resource finding is
implemented like url = classloader.getResource(path). I've added debug
msgs to proof that it happens that a URL is found but the inputstream
could not be created.
What piece of code you don't want to do anymore?
We have to load the resources through the classloader, because if we don't
how do we get them in the first place?
Most of the issues that we where having with class loaders are solved now.
if we see a resource in a jar
we only look at the jar. We don't dive into the jar anymore and then
suddenly because UrlConnection doesn't have a disconnect :(
we can't dispose it correctly.
It is not about jars or files in jars. See above.
The only thing that still is a problem i think is our wicket initializer
thing. That still seems to lock the jar files (for reloading inside tomcat)
johan
On 1/2/07, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
>
> Related to this issue: ClassLoader only has getResource(path) and
> getResourceAsStream(url) and no means to determine the file size or
> modify date. Usually you (and we as well) use File or URL for that.
> But neither File nor URL allow you to specify the classloader. If that
> is true, than we can completely ignore the ClassLoader while loading
> resource files. However why did we introduce it than? I guess because
> we had resource loading issue which we thought were classloader
> related. Has our implementation significantly changed since than so
> that resource loading only now is independent of the classloader? J2EE
> and servlet container mail archives are full of classloader issues.
> Are these issues only related to classes (not including resource
> files)?
>
> Juergen
>
> On 1/1/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> > fine by me
> >
> > On 1/1/07, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
> > >
> > > While working on improving resource loading I came across the
> following
> > > issue:
> > >
> > > IResourceFinder: URL find(String path);
> > >
> > > xxxResourceStreamLocator: IResourceStream locate(Class, String path)
> > >
> > > locate(..)
> > > {
> > > URL file = finder.find(path)
> > > if (file != null)
> > > {
> > > IResourceStream stream = new UrlResourceStream(file)
> > > }
> > > }
> > >
> > > The implicit assumption is that if 'file' != null than 'stream' will
> > > be != null as well. But that doesn't seem to be true, I did some
> > > tests. The reason being that the classloader used by the
> > > ResourceFinder may not be the one used by new UrlResourceStream().
> > >
> > > solution: change find() to return an IResourceStream instead of a URL
> > >
> > > any other idea?
> > >
> > > Juergen
> > >
> >
> >
>
