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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
