Resource loading

[Juergen Donnerstag <ju...@gmail.com>]

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

Re: Resource loading

[Igor Vaynberg <ig...@gmail.com>]

sounds good to me

-igor


On 1/1/07, Juergen Donnerstag <ju...@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
>

Re: Resource loading

[Juergen Donnerstag <ju...@gmail.com>]

On 1/3/07, Johan Compagner <jc...@gmail.com> 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 <ju...@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 <jc...@gmail.com> wrote:
> > > fine by me
> > >
> > > On 1/1/07, Juergen Donnerstag <ju...@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
> > > >
> > >
> > >
> >
>
>

Re: Resource loading

[Johan Compagner <jc...@gmail.com>]

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

Re: Resource loading

[Juergen Donnerstag <ju...@gmail.com>]

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

Re: Resource loading

[Johan Compagner <jc...@gmail.com>]

fine by me

On 1/1/07, Juergen Donnerstag <ju...@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
>