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
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
Hello,
I am having an issue on a stub generated with axis2 version 1.5.3.
Somehow the stub generates the XML containing an element badly causing the
XML to be invalid.
This is how it comes out (notice bad content inside ExecuteRequest):
?xml version='1.0' encoding='utf-8'?
soapenv:Envelope
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 jan.swael...@sofico.be wrote:
Hello,
I am having an issue on a stub
