Hi,
Yeah it would be great if application server vendors would comply to that
idea, it seems like its getting worse and worse with every new release
(weblogic, websphere...). They are all packaging and loading several
libraries (all xml related ones especially but also for example axis on
was)
Normally, when you package a StAX implementation into a J2EE
application, it is expected that the application will get that StAX
implementation, and not the implementation provided by the JRE or the
application server (it's the same as for DOM and XSLT processor
implementations). If that's not the
Hi,
It is giving me: weblogic.xml.stax.XMLStreamInputFactory
This is on a WebLogic server, we also deploy on WebSphere and JBOSS --
some approach that would work on all app servers would be great!
thanks
No. Axiom is not a StAX implementation. It is a dependency of Axis2
that requires a StAX implementation.
If Woodstox is already on your classpath, then it means that there are
multiple StAX implementations present and that an implementation other
than Woodstox is selected. Can you add some test co
Hi,
I looked a bit further and found the woodstox jar (wstx-asl-3.2.9.jar) on
the classpath, should I delete the axiom*.jar instances to enable woodstox
stax implementation?
thanks
Hello,
Thanks for your response.
Could you please indicate how we could apply your suggestion?
Is there a jar which we need to add to the classpath and/or is there
configuration involved?
Additionally, is it also possible to replace the axiom jar included in the
axis2 1.5.3 library set (v1.2.
That is a known issue in Axiom:
https://issues.apache.org/jira/browse/AXIOM-421
A workaround is to use Woodstox as StAX implementation (which is
recommended anyway).
Andreas
On Fri, Aug 24, 2012 at 1:39 PM, Jan Swaelens wrote:
> Hello,
>
> I am having an issue on a stub generated with axis2 ve
