You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by Jeremy Boynes <jb...@apache.org> on 2006/08/09 08:07:59 UTC
ClassLoader used to locate StAX implementation
StAXUtils creates XMLInputFactory and XMLOutputFactory instances from
the pool using the default newInstance() method e.g.
synchronized public static XMLInputFactory getXMLInputFactory() {
if (!xmlInputFactoryPool.empty()) {
return (XMLInputFactory) xmlInputFactoryPool.pop();
}
return XMLInputFactory.newInstance();
}
The implementation of this uses the Thread context classloader (TCCL)
to locate the implementation class and this is causing problems for
us in Tuscany where we are trying to use Axis from container code
rather than application code. The TCCL is set to application code so
that deserializers have access to the application classes to create
objects but the StAX implementation is bundled with the Tuscany
runtime and is not visible to the application (as we may use a
different one to the application).
Using the TCCL is also dangerous in combination with pooling as the
StAX implementation located each time a new instance is allocated
will be determined by the classpath on the Thread. This may be
different each time (e.g. if called from different applications)
which may result in factories from different implementations being
added to the pool.
As a simple change I would like to suggest that StAXUtils should try
and locate implementations using its own classloader. This would mean
changing the creation to use the version that takes a ClassLoader:
return XMLInputFactory.newInstance
("javax.xml.stream.XMLInputFactory", StAXUtils.class.getClassLoader());
This should have no impact on most usages - for example, if Axis is
bundled in a webapp then the TCCL will be the webapp loader by
definition, or if Axis is placed in some parent classloader (for
example, Tomcat's common or shared directory) then the StAX
implementation typically would be placed there as well. In general, I
think this will work when the StAX implementation is co-located with
axiom.
Unfortunately, doing this runs into a problem with stax-api 1.0 which
has an incorrect return type for the two-arg version of
XMLOutputFactory; this has been fixed in 1.0.1.
I've attached a patch which makes these changes and updates the
versions to stax-api 1.0.1
--
Jeremy
Re: ClassLoader used to locate StAX implementation
Posted by Jeremy Boynes <jb...@apache.org>.
On Aug 9, 2006, at 2:10 AM, Davanum Srinivas wrote:
> I can't see the patch. Could you please open a JIRA and upload the
> patch?
>
Sorry about that.
Created http://issues.apache.org/jira/browse/WSCOMMONS-70
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: ClassLoader used to locate StAX implementation
Posted by Davanum Srinivas <da...@gmail.com>.
I can't see the patch. Could you please open a JIRA and upload the patch?
thanks,
dims
On 8/9/06, Jeremy Boynes <jb...@apache.org> wrote:
> StAXUtils creates XMLInputFactory and XMLOutputFactory instances from
> the pool using the default newInstance() method e.g.
>
> synchronized public static XMLInputFactory getXMLInputFactory() {
> if (!xmlInputFactoryPool.empty()) {
> return (XMLInputFactory) xmlInputFactoryPool.pop();
> }
> return XMLInputFactory.newInstance();
> }
>
> The implementation of this uses the Thread context classloader (TCCL)
> to locate the implementation class and this is causing problems for
> us in Tuscany where we are trying to use Axis from container code
> rather than application code. The TCCL is set to application code so
> that deserializers have access to the application classes to create
> objects but the StAX implementation is bundled with the Tuscany
> runtime and is not visible to the application (as we may use a
> different one to the application).
>
> Using the TCCL is also dangerous in combination with pooling as the
> StAX implementation located each time a new instance is allocated
> will be determined by the classpath on the Thread. This may be
> different each time (e.g. if called from different applications)
> which may result in factories from different implementations being
> added to the pool.
>
> As a simple change I would like to suggest that StAXUtils should try
> and locate implementations using its own classloader. This would mean
> changing the creation to use the version that takes a ClassLoader:
>
> return XMLInputFactory.newInstance
> ("javax.xml.stream.XMLInputFactory", StAXUtils.class.getClassLoader());
>
> This should have no impact on most usages - for example, if Axis is
> bundled in a webapp then the TCCL will be the webapp loader by
> definition, or if Axis is placed in some parent classloader (for
> example, Tomcat's common or shared directory) then the StAX
> implementation typically would be placed there as well. In general, I
> think this will work when the StAX implementation is co-located with
> axiom.
>
> Unfortunately, doing this runs into a problem with stax-api 1.0 which
> has an incorrect return type for the two-arg version of
> XMLOutputFactory; this has been fixed in 1.0.1.
>
> I've attached a patch which makes these changes and updates the
> versions to stax-api 1.0.1
>
> --
> Jeremy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
>
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org