cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: svn commit: r608369 - /incubator/cxf/trunk/common/common/src/main/java/org/apache/cxf/helpers/XMLUtils.java
Date Fri, 04 Jan 2008 18:34:41 GMT

Actually, this inspired me to make a better fix...  :-)

Basically, any attempt to check parent classloaders, configurations, 
etc... is going to have cases where this isn't going to work.  Example: 
a firewall style classloader in the parent chain someplace.    Either 
that, or trying to figure out whether is will or will not work is more 
expensive than a map lookup.

Thus, I've changed the parserFactory to a 
WeakHashMap<ClassLoader, DocumentBuilderFactory> 
where we store based on the context ClassLoader.   Thus, each app ends up 
with it's own DocumentBuilderFactory.  If a new classloader is found, a 
new docbuilder is created.   This should allow each app to properly 
configure it's own stuff.     :-)

Also, while digging in there, I noticed there are other statics in 
XmlUtils which can have really nasty affects.   I'm removing those.   
(example: if someone calls XmlUtils.setIndent(4), then ALL docs written 
out after that end up indented)   I've now made those as optional flags 
to the write methods.

Dan



On Thursday 03 January 2008, Freeman Fang wrote:
> Hi Dan,
>
> Sure, added check for parents of the contextClassLoader.
> If it's ok, would you please sync this commit[1] to 2.0.x fixes
> branch? [1]http://svn.apache.org/viewvc?rev=608731&view=rev
>
> Thanks
>
> Freeman
>
> Daniel Kulp wrote:
> > Freeman,
> >
> > This is definitely not a "complete" fix.   With the way we setup the
> > TCK, this will result in a new ParserFactory being created almost
> > all the time which will suck.    The main reason is that the Thread
> > contextClassLoader is the webapps classloader, but the parser is
> > loaded from the tomcat classloader which would be one of the parents
> > of the contextClassloader.
> >
> > Thus, the fix probably should check the parents of the
> > contextClassLoader as well.
> >
> > Dan
> >
> > On Thursday 03 January 2008, ffang@apache.org wrote:
> >> Author: ffang
> >> Date: Wed Jan  2 23:42:20 2008
> >> New Revision: 608369
> >>
> >> URL: http://svn.apache.org/viewvc?rev=608369&view=rev
> >> Log:
> >> [CXF-1351] static DocumentBuilderFactory in XMLUtils cause
> >> ClassCastException when use different classloader
> >>
> >> Modified:
> >>
> >> incubator/cxf/trunk/common/common/src/main/java/org/apache/cxf/help
> >>ers /XMLUtils.java
> >>
> >> Modified:
> >> incubator/cxf/trunk/common/common/src/main/java/org/apache/cxf/help
> >>ers /XMLUtils.java URL:
> >> http://svn.apache.org/viewvc/incubator/cxf/trunk/common/common/src/
> >>mai
> >> n/java/org/apache/cxf/helpers/XMLUtils.java?rev=608369&r1=608368&r2
> >>=608 369&view=diff
> >> ===================================================================
> >>=== ======== ---
> >> incubator/cxf/trunk/common/common/src/main/java/org/apache/cxf/help
> >>ers /XMLUtils.java (original) +++
> >> incubator/cxf/trunk/common/common/src/main/java/org/apache/cxf/help
> >>ers /XMLUtils.java Wed Jan  2 23:42:20 2008 @@ -88,6 +88,13 @@ }
> >>
> >>      public static DocumentBuilder getParser() throws
> >> ParserConfigurationException { +        if
> >> (parserFactory.getClass().getClassLoader() != null +            &&
> >> !parserFactory.getClass().getClassLoader().equals( +
> >> Thread.currentThread().getContextClassLoader())) { +           
> >> //not the same classloader which init parserFactory, so create
> >> parserFactory with new classLoader +            parserFactory =
> >> DocumentBuilderFactory.newInstance(); +
> >> parserFactory.setNamespaceAware(true);
> >> +        }
> >>          return parserFactory.newDocumentBuilder();
> >>      }



-- 
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog

Mime
View raw message