Hi,
seems woodstox is now mandatory to use cxf (tested with v2.6.7) because
of org.apache.cxf.staxutils.StaxUtils
is it normal?
in TomEE we were remove it by default so basically it means we can't upgrade
*Romain Manni-Bucau*
*Twitter: @rmannibucau https://twitter.com/rmannibucau*
*Blog:
Hi,
I believe it's just compile time dependency, during runtime, you still can use
any other stax parser for now.
What's the error you run into?
-
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter:
when unmarshalling
(org.apache.cxf.jaxrs.provider.JAXBElementProvider.readFrom) the reader is
closed thanks to StaxUtils.close(reader); call
and it triggers:
org.apache.cxf.jaxrs.client.ClientWebApplicationException:
java.lang.NoClassDefFoundError: com/ctc/wstx/stax/WstxInputFactory
at
Hi Romain
The latest Woodstox has the superior security characteristics with
regard to managing large payloads, and this is why it is preferred now,
perhaps even TomEE might 'consider' swithcing to it in the future,
however, StaxUtils checks a system
org.apache.cxf.stax.allowInsecureParser
Hi Sergey,
tomee doesn't bring it by default because it is too fatty and not always
mandatory (same reason we don't bring jackson by default).
i think the issue is not with close() but with the loadclass of staxutils
which imports woodstox (i run with java 7)
*Romain Manni-Bucau*
*Twitter:
On 02/04/13 11:01, Romain Manni-Bucau wrote:
Hi Sergey,
tomee doesn't bring it by default because it is too fatty and not always
mandatory (same reason we don't bring jackson by default).
i think the issue is not with close() but with the loadclass of staxutils
which imports woodstox (i run
that generated a required woodstox import in cxf-api's manifest. That
needs to be changed to optional as well.
2013/4/2 Sergey Beryozkin sberyoz...@gmail.com:
On 02/04/13 11:01, Romain Manni-Bucau wrote:
Hi Sergey,
tomee doesn't bring it by default because it is too fatty and not always
On Apr 2, 2013, at 5:25 AM, Aki Yoshida elak...@gmail.com wrote:
that generated a required woodstox import in cxf-api's manifest. That
needs to be changed to optional as well.
No, I explicitly did not mark it optional to make sure the OBR would pull it in.
Dan
2013/4/2 Sergey Beryozkin
On 02/04/13 16:10, Daniel Kulp wrote:
Actually, this stack trace really concerns me. This makes it look like we
have an XMLStreamReader that was not created via one of the StaxUtils methods.
Otherwise, this exception would be raised at creation time, not close. That
bothers me as all
Hi Dan,
I thought the allowInsecureParser option was intended to be used also in osgi.
aki
2013/4/2 Daniel Kulp dk...@apache.org:
On Apr 2, 2013, at 5:25 AM, Aki Yoshida elak...@gmail.com wrote:
that generated a required woodstox import in cxf-api's manifest. That
needs to be changed to
As we don't have dependency=true for woodstox bundles in cxf features.xml, so
I think even cxf-api optionally import woodstox package, the woodstox bundle
could get installed anyway
-
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://fusesource.com |
On Apr 2, 2013, at 10:44 AM, Freeman Fang freeman.f...@gmail.com wrote:
As we don't have dependency=true for woodstox bundles in cxf features.xml,
so I think even cxf-api optionally import woodstox package, the woodstox
bundle could get installed anyway
Thats IF you are using Karaf and the
On Apr 2, 2013, at 11:06 AM, Daniel Kulp dk...@apache.org wrote:
On Apr 2, 2013, at 10:44 AM, Freeman Fang freeman.f...@gmail.com wrote:
As we don't have dependency=true for woodstox bundles in cxf features.xml,
so I think even cxf-api optionally import woodstox package, the woodstox
13 matches
Mail list logo