You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by jonathan doklovic <jd...@sysbliss.com> on 2008/01/16 15:41:05 UTC
ClasspathUtils with or vs. JavaResource
Hey,
I've been working on refactoring some code to make it easier to
implement relative resources in things like the import task.
After looking at BaseDef and AntLibDefinition, it seemed that it was a
bit backwards and AntlibDefinition should actually extend a base class
that provides basic classpath lookups.
In trying to do this refactoring, I realized that all of this stuff was
just using ClasspathUtils and not using JavaResource or
ClasspathResource so I figured the refactoring should include this
update as well.
However, after digging in, it seems to get very complex...
ClasspathUtils (and it's Delegate) does a lot of work to figure out the
classloader and reuse one if it can. To do this, there's a bunch of
delegate calls that get made and eventually the calling task takes the
class loader returned by the delegate and loads the resource (unless
it's a file, then it just loads it).
With a ClasspathResource, you basically give it the path and the
resource name, and it does it's own simpler checks to figure out and
reuse the classloader and you can tell it to load the resource. However,
you cannot get a reference to the classloader used.
My question is, should these be used together? It seems a little
overkill to do all the steps required in ClasspathUtils just to get the
path for the resource to then in turn pass it to a ClasspathResource
which is going to use it's own classloader anyway.
There's got to be a cleaner way to do this, i'm just not sure if
ClasspathUtils should be updated to return/use ClasspathResources, or if
the ClasspathResource should get a little smarter to bypass the utils
class alltogether.
any thoughts?
- Jonathan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ClasspathUtils with or vs. JavaResource
Posted by jonathan doklovic <jd...@sysbliss.com>.
Well,
For now, since the relative path stuff should be going into
ResourceFactory, I'll create a new base class that simply checks for
name, classname, resource, classpath, and loadrref args and returns a
JavaResource using the ResourceFactory. I'll use this as the base for
the new import task to allow loading resources (and relative resources)
from the classpath and leave the other stuff (DefBase, etc.) as is.
Once this is done, it will hopefully be clear to see where to put the
http stuff as well.
I should be able to get this working pretty quickly, so it can be
reviewed and decisions can be made about the use of ClasspathUtils or
refactoring the other code.
sound like a plan?
- Jonathan
On Wed, 2008-01-16 at 16:03 +0000, Steve Loughran wrote:
> jonathan doklovic wrote:
> > Hey,
> >
> > I've been working on refactoring some code to make it easier to
> > implement relative resources in things like the import task.
> >
> > After looking at BaseDef and AntLibDefinition, it seemed that it was a
> > bit backwards and AntlibDefinition should actually extend a base class
> > that provides basic classpath lookups.
> >
> > In trying to do this refactoring, I realized that all of this stuff was
> > just using ClasspathUtils and not using JavaResource or
> > ClasspathResource so I figured the refactoring should include this
> > update as well.
> >
> > However, after digging in, it seems to get very complex...
> > ClasspathUtils (and it's Delegate) does a lot of work to figure out the
> > classloader and reuse one if it can. To do this, there's a bunch of
> > delegate calls that get made and eventually the calling task takes the
> > class loader returned by the delegate and loads the resource (unless
> > it's a file, then it just loads it).
> >
> > With a ClasspathResource, you basically give it the path and the
> > resource name, and it does it's own simpler checks to figure out and
> > reuse the classloader and you can tell it to load the resource. However,
> > you cannot get a reference to the classloader used.
> >
> > My question is, should these be used together? It seems a little
> > overkill to do all the steps required in ClasspathUtils just to get the
> > path for the resource to then in turn pass it to a ClasspathResource
> > which is going to use it's own classloader anyway.
> >
> > There's got to be a cleaner way to do this, i'm just not sure if
> > ClasspathUtils should be updated to return/use ClasspathResources, or if
> > the ClasspathResource should get a little smarter to bypass the utils
> > class alltogether.
> >
> > any thoughts?
> >
> > - Jonathan
> >
>
> the two goals of ant's classpath work are
>
> (a) reuse stuff so that you can share data properly
> (b) not leak like a leaky-sieve, and so cause IDEs or app servers to run
> out of memory
>
> The classpath stuff does achieve both, but I'd have to look at all of
> this to see what is going on. You are clearly provoking us into a code
> review
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ClasspathUtils with or vs. JavaResource
Posted by Steve Loughran <st...@apache.org>.
jonathan doklovic wrote:
> Hey,
>
> I've been working on refactoring some code to make it easier to
> implement relative resources in things like the import task.
>
> After looking at BaseDef and AntLibDefinition, it seemed that it was a
> bit backwards and AntlibDefinition should actually extend a base class
> that provides basic classpath lookups.
>
> In trying to do this refactoring, I realized that all of this stuff was
> just using ClasspathUtils and not using JavaResource or
> ClasspathResource so I figured the refactoring should include this
> update as well.
>
> However, after digging in, it seems to get very complex...
> ClasspathUtils (and it's Delegate) does a lot of work to figure out the
> classloader and reuse one if it can. To do this, there's a bunch of
> delegate calls that get made and eventually the calling task takes the
> class loader returned by the delegate and loads the resource (unless
> it's a file, then it just loads it).
>
> With a ClasspathResource, you basically give it the path and the
> resource name, and it does it's own simpler checks to figure out and
> reuse the classloader and you can tell it to load the resource. However,
> you cannot get a reference to the classloader used.
>
> My question is, should these be used together? It seems a little
> overkill to do all the steps required in ClasspathUtils just to get the
> path for the resource to then in turn pass it to a ClasspathResource
> which is going to use it's own classloader anyway.
>
> There's got to be a cleaner way to do this, i'm just not sure if
> ClasspathUtils should be updated to return/use ClasspathResources, or if
> the ClasspathResource should get a little smarter to bypass the utils
> class alltogether.
>
> any thoughts?
>
> - Jonathan
>
the two goals of ant's classpath work are
(a) reuse stuff so that you can share data properly
(b) not leak like a leaky-sieve, and so cause IDEs or app servers to run
out of memory
The classpath stuff does achieve both, but I'd have to look at all of
this to see what is going on. You are clearly provoking us into a code
review
--
Steve Loughran http://www.1060.org/blogxter/publish/5
Author: Ant in Action http://antbook.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org