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:[EMAIL PROTECTED] > Sent: 08 January 2004 15:13 > To: [EMAIL PROTECTED] > Subject: Re: Selecting XML Parsers > > > On Wed, 7 Jan 2004, Jose Alberto Fernandez <[EMAIL PROTECTED]> > wrote: > >> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > >> > >> On Tue, 30 Dec 2003, Jose Alberto Fernandez > >> <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
