wicket-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johan Compagner" <jcompag...@gmail.com>
Subject Re: Resource loading
Date Wed, 03 Jan 2007 09:21:28 GMT
What do you mean with ignore the classloader?

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.

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 <juergen.donnerstag@gmail.com> 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 <jcompagner@gmail.com> wrote:
> > fine by me
> >
> > On 1/1/07, Juergen Donnerstag <juergen.donnerstag@gmail.com> 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
> > >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message