ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <jalbe...@cellectivity.com>
Subject RE: Selecting XML Parsers
Date Mon, 12 Jan 2004 12:28:16 GMT
I took a look at JAXPUtils to try to make it use 
classloaders and found that the class is doing static
caching. What this means is that once one parser
is found (using whichever classloader as specified
in the ContextClassLoader) the class will return 
the same parser no matter what.

Question 1: How important is caching here? I presume
it is important.

Assuming it is important to cache, what I could do
is use a static WeakHashMap (JDK 1.2) to keep the references
based on the effective classloader to use. 

Question 2: How good are we now at reusing classloaders?
I see we ask the project to construct a classloader based
on a claspath, does the same classpath (or classpath-ref)
will give you the same classloader instance? That would really
be a good thing.

So, does any body object to this type of approach in principle?

Jose Alberto

> -----Original Message-----
> From: Stefan Bodewig [mailto:bodewig@apache.org] 
> Sent: 08 January 2004 15:13
> To: dev@ant.apache.org
> Subject: Re: Selecting XML Parsers
> 
> 
> On Wed, 7 Jan 2004, Jose Alberto Fernandez <jalberto@cellectivity.com>
> wrote:
> >> From: Stefan Bodewig [mailto:bodewig@apache.org]
> >> 
> >> On Tue, 30 Dec 2003, Jose Alberto Fernandez
> >> <jalberto@cellectivity.com> wrote:
> >> 
> >> > That does not seem to work in 1.6.0 since <style/> only uses the

> >> > classpath to find the the Liason but the TRAX liason 
> does not uses 
> >> > it to find the factories.
> >> 
> >> I don't think this has changed in 1.6 at all.
> >> 
> > 
> > Were we using JAXPUtils in 1.5.x?
> 
> Only to resolve systemIds, just as the code in CVS HEAD does.
> 
> > What it seem to me is that the API for JAXPUtils is wrong since it 
> > does not take into account tasks passing a ClassLoader.
> 
> Go ahead and change it, I agree with you about setting the 
> context classloader.
> 
> > JAXPUtils methods should expect a ClassLoader. I would like to just 
> > change the API instead of adding more methods, but I am not sure if 
> > this API is considered to be public already.
> 
> They are public.  We can assume that people have set the 
> context classloader before calling the old method signatures.
> 
> > In 1.5.x I had saxon.jar (which includes a non validating 
> parser) in 
> > my project libraries and not in ANT. I used the 
> <classpath/> to make 
> > it available to <style/>. In 1.6.0 I was unable to make that 
> > configuration work (not sure why).
> 
> Probably because your <classpath> didn't contain some parts 
> of Ant that have traditionally been there.
> 
> > In general, I think all ANT maintained tasks should be more 
> > ClassLoader aware than they are right now.
> 
> No objections.
> 
> > Have a similar problem with the <script[def]/> tasks which 
> do not make 
> > use of the calls in BSF to set the classloader (which are there).
> 
> The original <script> task is about four years old and didn't 
> change much after that.
> 
> Stefan
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message