You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2013/01/13 18:34:01 UTC
woodstox and jackson?
Hi,
two questions about next release and dependencies:
1) David reworked our JavaEE descriptors parsing to use sxc. In this
refactoring we now use woodstox under the stax api (was it mandatory?)
-> do we want it? if yes do we shade it or simply skip it in the
classloader to avoid classloader issues if an app provides it? (+ 500ko
about)
2) same kind of question about jackson. In two work jackson is THE library
to do JSon. It is very friendly for JAXRS. Currently we use default
providers of cxf. We saw a bunch of users switching it to jackson. I tested
the default one and got some issues we can't workaround (one bothering
thing is the fact the string values are escaped by jettison and that's too
low level to be changed, so basically you never have what you expect after
marshalling).
-> do we want to keep default providers of cxf or do we switch to a real
implementation (ie jackson, +1.2M about)
about licensing no issue both are dual ilcensed Apache License 2 and LGPL
2.1
I'd like to get it fixed by the end of the week (the 17th) the be able to
prepare the release on a pretty stable trunk
wdyt?
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
Re: woodstox and jackson?
Posted by Alex The Rocker <al...@gmail.com>.
Is woodstox performance gain visible for what TomEE does with it?
If that for parsing a few web.xml fragments and other configuration files,
then maybe the acceleration isn't visible to make it worth the extra kb in
TomEE distrib
Alex
On Sun, Jan 13, 2013 at 7:06 PM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> just to add some word on woodstox: because it is the fastest one
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>
>
>
> 2013/1/13 Alex The Rocker <al...@gmail.com>
>
> > Hello,
> >
> > My two cents:
> >
> > woodstox : -1 why adding woodstox, when we have a pull parser included
> in
> > Java standard libraries since Java 6 ?
> > Jackson instead of Jettison : +1 (i also see everyone in my company
> using
> > Jackson for r/w JSON)
> >
> > Alex
> >
> > On Sun, Jan 13, 2013 at 6:34 PM, Romain Manni-Bucau
> > <rm...@gmail.com>wrote:
> >
> > > woodstox
> >
>
Re: woodstox and jackson?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
just to add some word on woodstox: because it is the fastest one
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/1/13 Alex The Rocker <al...@gmail.com>
> Hello,
>
> My two cents:
>
> woodstox : -1 why adding woodstox, when we have a pull parser included in
> Java standard libraries since Java 6 ?
> Jackson instead of Jettison : +1 (i also see everyone in my company using
> Jackson for r/w JSON)
>
> Alex
>
> On Sun, Jan 13, 2013 at 6:34 PM, Romain Manni-Bucau
> <rm...@gmail.com>wrote:
>
> > woodstox
>
Re: woodstox and jackson?
Posted by Alex The Rocker <al...@gmail.com>.
Hello,
My two cents:
woodstox : -1 why adding woodstox, when we have a pull parser included in
Java standard libraries since Java 6 ?
Jackson instead of Jettison : +1 (i also see everyone in my company using
Jackson for r/w JSON)
Alex
On Sun, Jan 13, 2013 at 6:34 PM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> woodstox
Re: woodstox and jackson?
Posted by David Blevins <da...@gmail.com>.
Portable, yes.
Generated, yes. So safe to edit, not really. Ideally we'd figure out why it didn't generate correctly and fix there.
I saw you made a couple fixes to the generated source. Pragmatically, if we can add a test case to the container/openejb-jee-accessors/ for the fixes that would give us at least some lasting awareness that something certain fixes need to be made. That's good enough protection for now. We can migrate the fix to the proper place later.
When we generate again and overwrite the hand-made fixes, we'll have the test cases to ensure we haven't lost anything.
-David
On Jan 13, 2013, at 2:40 PM, Romain Manni-Bucau <rm...@gmail.com> wrote:
> Is it portable?
>
> Was accessor module generated (= are the changes we do to it safe?)
> Le 13 janv. 2013 23:37, "David Blevins" <da...@gmail.com> a écrit :
>
>>
>> On Jan 13, 2013, at 2:06 PM, David Blevins <da...@gmail.com>
>> wrote:
>>
>>>
>>> On Jan 13, 2013, at 1:56 PM, David Blevins <da...@gmail.com>
>> wrote:
>>>
>>>>
>>>> On Jan 13, 2013, at 12:32 PM, David Blevins <da...@gmail.com>
>> wrote:
>>>>
>>>>>
>>>>> On Jan 13, 2013, at 9:34 AM, Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>>>>>
>>>>>> two questions about next release and dependencies:
>>>>>> 1) David reworked our JavaEE descriptors parsing to use sxc. In this
>>>>>> refactoring we now use woodstox under the stax api (was it mandatory?)
>>>>>> -> do we want it? if yes do we shade it or simply skip it in the
>>>>>> classloader to avoid classloader issues if an app provides it? (+
>> 500ko
>>>>>> about)
>>>>>
>>>>> Digging in the SXC code to see how tightly woodstox is integrated.
>>>>
>>>> Interestingly enough the built-in vm impl appears to be faster on the
>> unmarshal. Getting encoding errors on the marshal though. Digging into it.
>>>
>>> Never mind, my IDE classpath as 3 copies of woodstocks, 2 of jettison
>> and of course the built-in vm version (intellij's maven support doesn't
>> really manage the classpath like maven does). Let me clean up and try
>> again.
>>
>> Confirmed. The com.sun.* impl is indeed faster for our purposes than
>> Woodstox. Yanked Woodstox from the openejb-jee-accessors module.
>>
>>
>> -David
>>
>>
Re: woodstox and jackson?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Is it portable?
Was accessor module generated (= are the changes we do to it safe?)
Le 13 janv. 2013 23:37, "David Blevins" <da...@gmail.com> a écrit :
>
> On Jan 13, 2013, at 2:06 PM, David Blevins <da...@gmail.com>
> wrote:
>
> >
> > On Jan 13, 2013, at 1:56 PM, David Blevins <da...@gmail.com>
> wrote:
> >
> >>
> >> On Jan 13, 2013, at 12:32 PM, David Blevins <da...@gmail.com>
> wrote:
> >>
> >>>
> >>> On Jan 13, 2013, at 9:34 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> >>>
> >>>> two questions about next release and dependencies:
> >>>> 1) David reworked our JavaEE descriptors parsing to use sxc. In this
> >>>> refactoring we now use woodstox under the stax api (was it mandatory?)
> >>>> -> do we want it? if yes do we shade it or simply skip it in the
> >>>> classloader to avoid classloader issues if an app provides it? (+
> 500ko
> >>>> about)
> >>>
> >>> Digging in the SXC code to see how tightly woodstox is integrated.
> >>
> >> Interestingly enough the built-in vm impl appears to be faster on the
> unmarshal. Getting encoding errors on the marshal though. Digging into it.
> >
> > Never mind, my IDE classpath as 3 copies of woodstocks, 2 of jettison
> and of course the built-in vm version (intellij's maven support doesn't
> really manage the classpath like maven does). Let me clean up and try
> again.
>
> Confirmed. The com.sun.* impl is indeed faster for our purposes than
> Woodstox. Yanked Woodstox from the openejb-jee-accessors module.
>
>
> -David
>
>
Re: woodstox and jackson?
Posted by David Blevins <da...@gmail.com>.
On Jan 13, 2013, at 2:06 PM, David Blevins <da...@gmail.com> wrote:
>
> On Jan 13, 2013, at 1:56 PM, David Blevins <da...@gmail.com> wrote:
>
>>
>> On Jan 13, 2013, at 12:32 PM, David Blevins <da...@gmail.com> wrote:
>>
>>>
>>> On Jan 13, 2013, at 9:34 AM, Romain Manni-Bucau <rm...@gmail.com> wrote:
>>>
>>>> two questions about next release and dependencies:
>>>> 1) David reworked our JavaEE descriptors parsing to use sxc. In this
>>>> refactoring we now use woodstox under the stax api (was it mandatory?)
>>>> -> do we want it? if yes do we shade it or simply skip it in the
>>>> classloader to avoid classloader issues if an app provides it? (+ 500ko
>>>> about)
>>>
>>> Digging in the SXC code to see how tightly woodstox is integrated.
>>
>> Interestingly enough the built-in vm impl appears to be faster on the unmarshal. Getting encoding errors on the marshal though. Digging into it.
>
> Never mind, my IDE classpath as 3 copies of woodstocks, 2 of jettison and of course the built-in vm version (intellij's maven support doesn't really manage the classpath like maven does). Let me clean up and try again.
Confirmed. The com.sun.* impl is indeed faster for our purposes than Woodstox. Yanked Woodstox from the openejb-jee-accessors module.
-David
Re: woodstox and jackson?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
why cxf doesn't use jackson? i don't know...everybody uses it in real life.
Probably because they use jaxb as main API so the bridge to jettison was
quite easy and light.
The issue? just return an attribute with an url "http://foo.com" and you'll
get "http:\/\/foo.com". This is escaped so low in the layers you can't
avoid it (and no boolean or custom stuff to do easily). Moreover the
marshalling is too closed to jaxb to be easy (management of list, map
etc...). Since json is a lot used with js clients it never really matches
(this one is not a bug but not a really nice default).
I'm ok to keep jettison for this release (1.5.2) then to choose (or not)
for 1.6.0 jackson (the issue of including it would be app
overriding...probably another potential shade :s).
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/1/13 David Blevins <da...@gmail.com>
>
> On Jan 13, 2013, at 1:56 PM, David Blevins <da...@gmail.com>
> wrote:
>
> >
> > On Jan 13, 2013, at 12:32 PM, David Blevins <da...@gmail.com>
> wrote:
> >
> >>
> >> On Jan 13, 2013, at 9:34 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> >>
> >>> two questions about next release and dependencies:
> >>> 1) David reworked our JavaEE descriptors parsing to use sxc. In this
> >>> refactoring we now use woodstox under the stax api (was it mandatory?)
> >>> -> do we want it? if yes do we shade it or simply skip it in the
> >>> classloader to avoid classloader issues if an app provides it? (+ 500ko
> >>> about)
> >>
> >> Digging in the SXC code to see how tightly woodstox is integrated.
> >
> > Interestingly enough the built-in vm impl appears to be faster on the
> unmarshal. Getting encoding errors on the marshal though. Digging into it.
>
> Never mind, my IDE classpath as 3 copies of woodstocks, 2 of jettison and
> of course the built-in vm version (intellij's maven support doesn't really
> manage the classpath like maven does). Let me clean up and try again.
>
>
> -David
>
>
Re: woodstox and jackson?
Posted by David Blevins <da...@gmail.com>.
On Jan 13, 2013, at 1:56 PM, David Blevins <da...@gmail.com> wrote:
>
> On Jan 13, 2013, at 12:32 PM, David Blevins <da...@gmail.com> wrote:
>
>>
>> On Jan 13, 2013, at 9:34 AM, Romain Manni-Bucau <rm...@gmail.com> wrote:
>>
>>> two questions about next release and dependencies:
>>> 1) David reworked our JavaEE descriptors parsing to use sxc. In this
>>> refactoring we now use woodstox under the stax api (was it mandatory?)
>>> -> do we want it? if yes do we shade it or simply skip it in the
>>> classloader to avoid classloader issues if an app provides it? (+ 500ko
>>> about)
>>
>> Digging in the SXC code to see how tightly woodstox is integrated.
>
> Interestingly enough the built-in vm impl appears to be faster on the unmarshal. Getting encoding errors on the marshal though. Digging into it.
Never mind, my IDE classpath as 3 copies of woodstocks, 2 of jettison and of course the built-in vm version (intellij's maven support doesn't really manage the classpath like maven does). Let me clean up and try again.
-David
Re: woodstox and jackson?
Posted by David Blevins <da...@gmail.com>.
On Jan 13, 2013, at 12:32 PM, David Blevins <da...@gmail.com> wrote:
>
> On Jan 13, 2013, at 9:34 AM, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
>> two questions about next release and dependencies:
>> 1) David reworked our JavaEE descriptors parsing to use sxc. In this
>> refactoring we now use woodstox under the stax api (was it mandatory?)
>> -> do we want it? if yes do we shade it or simply skip it in the
>> classloader to avoid classloader issues if an app provides it? (+ 500ko
>> about)
>
> Digging in the SXC code to see how tightly woodstox is integrated.
Interestingly enough the built-in vm impl appears to be faster on the unmarshal. Getting encoding errors on the marshal though. Digging into it.
-David
Re: woodstox and jackson?
Posted by David Blevins <da...@gmail.com>.
On Jan 13, 2013, at 9:34 AM, Romain Manni-Bucau <rm...@gmail.com> wrote:
> two questions about next release and dependencies:
> 1) David reworked our JavaEE descriptors parsing to use sxc. In this
> refactoring we now use woodstox under the stax api (was it mandatory?)
> -> do we want it? if yes do we shade it or simply skip it in the
> classloader to avoid classloader issues if an app provides it? (+ 500ko
> about)
Digging in the SXC code to see how tightly woodstox is integrated.
> 2) same kind of question about jackson. In two work jackson is THE library
> to do JSon. It is very friendly for JAXRS. Currently we use default
> providers of cxf. We saw a bunch of users switching it to jackson. I tested
> the default one and got some issues we can't workaround (one bothering
> thing is the fact the string values are escaped by jettison and that's too
> low level to be changed, so basically you never have what you expect after
> marshalling).
> -> do we want to keep default providers of cxf or do we switch to a real
> implementation (ie jackson, +1.2M about)
Can you expand on the String issue with jettison. Is there actually a bug there and people just don't care?
Kind of curious why CXF doesn't use Jackson by default if it is so amazing.
-David