You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cxf.apache.org by ff...@apache.org on 2008/01/03 08:42:20 UTC
svn commit: r608369 -
/incubator/cxf/trunk/common/common/src/main/java/org/apache/cxf/helpers/XMLUtils.java
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/helpers/XMLUtils.java
Modified: incubator/cxf/trunk/common/common/src/main/java/org/apache/cxf/helpers/XMLUtils.java
URL: http://svn.apache.org/viewvc/incubator/cxf/trunk/common/common/src/main/java/org/apache/cxf/helpers/XMLUtils.java?rev=608369&r1=608368&r2=608369&view=diff
==============================================================================
--- incubator/cxf/trunk/common/common/src/main/java/org/apache/cxf/helpers/XMLUtils.java (original)
+++ incubator/cxf/trunk/common/common/src/main/java/org/apache/cxf/helpers/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();
}
Re: svn commit: r608369 - /incubator/cxf/trunk/common/common/src/main/java/org/apache/cxf/helpers/XMLUtils.java
Posted by Freeman Fang <fr...@iona.com>.
Hi Dan,
Yeah, that's much better than my solution.
Cheers
Freeman
Daniel Kulp wrote:
> 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();
>>>> }
>>>>
>
>
>
>
Re: svn commit: r608369 - /incubator/cxf/trunk/common/common/src/main/java/org/apache/cxf/helpers/XMLUtils.java
Posted by Daniel Kulp <dk...@apache.org>.
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
Re: svn commit: r608369 - /incubator/cxf/trunk/common/common/src/main/java/org/apache/cxf/helpers/XMLUtils.java
Posted by Freeman Fang <fr...@iona.com>.
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/helpers
>> /XMLUtils.java
>>
>> Modified:
>> incubator/cxf/trunk/common/common/src/main/java/org/apache/cxf/helpers
>> /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/helpers
>> /XMLUtils.java (original) +++
>> incubator/cxf/trunk/common/common/src/main/java/org/apache/cxf/helpers
>> /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();
>> }
>>
>
>
>
>
Re: svn commit: r608369 - /incubator/cxf/trunk/common/common/src/main/java/org/apache/cxf/helpers/XMLUtils.java
Posted by Freeman Fang <fr...@iona.com>.
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/helpers
>> /XMLUtils.java
>>
>> Modified:
>> incubator/cxf/trunk/common/common/src/main/java/org/apache/cxf/helpers
>> /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/helpers
>> /XMLUtils.java (original) +++
>> incubator/cxf/trunk/common/common/src/main/java/org/apache/cxf/helpers
>> /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();
>> }
>>
>
>
>
>
Re: svn commit: r608369 - /incubator/cxf/trunk/common/common/src/main/java/org/apache/cxf/helpers/XMLUtils.java
Posted by Daniel Kulp <dk...@apache.org>.
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/helpers
>/XMLUtils.java
>
> Modified:
> incubator/cxf/trunk/common/common/src/main/java/org/apache/cxf/helpers
>/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/helpers
>/XMLUtils.java (original) +++
> incubator/cxf/trunk/common/common/src/main/java/org/apache/cxf/helpers
>/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
Re: svn commit: r608369 - /incubator/cxf/trunk/common/common/src/main/java/org/apache/cxf/helpers/XMLUtils.java
Posted by Daniel Kulp <dk...@apache.org>.
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/helpers
>/XMLUtils.java
>
> Modified:
> incubator/cxf/trunk/common/common/src/main/java/org/apache/cxf/helpers
>/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/helpers
>/XMLUtils.java (original) +++
> incubator/cxf/trunk/common/common/src/main/java/org/apache/cxf/helpers
>/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