On 3/25/2010 3:46 AM, Ivan wrote:
Yes, just found that we have already used the bundlized one from
servicemix, this one might be imported by some other components. It is
not a big problem.
Just check the way we use to make the service lookup work in Geronimo
3.0, seems that :
1. If we use the api shipped in the jre, it might not work correctly
in the OSGI environment if we want to use non-ri implementation, as I
found that all our spec apis have been hacked to use OSGI service
registry to lookup service. If it does, do we need to recover some api
that we removed before, such as saaj, as in the past, IIRC, we use
axis2's impl for our geronimo-tomcat distribution.
I'm currently working on the issues involving the JRE-provided
specifications. Right now, I'm struggling with a puzzling problem with
jaxb, but I suspect I'll end up touching on all of these.
2. I found that current logic will detect that whether there is a head
named SPI-provider in the manifest.mf file, if not, it would not scan
the service folder for mapped files. Does it work for design ? So we
might need to create our own impl-bundle, such as wstx-asl.
Yes, we might need to create our own bundlized version of wstx with the
SPI-Provider header added for opt-in. This was something that was
copied from the Aries project spi-fly prototype. An explicit opt-in
seems like a reasonable thing to prevent unintended services from
automatically getting picked up.
Rick
Any comment ? Thanks !
2010/3/25 David Jencks <[email protected]
<mailto:[email protected]>>
On Mar 24, 2010, at 8:44 PM, Daniel Kulp wrote:
> On Wednesday 24 March 2010 9:44:12 pm Ivan wrote:
>> Hi,
>> Just trying the latest Geronimo 3.0 build, get a CNF
exception for the
>> XMLInputFactory, seems that wstx-asl shipped is not a bundle.
>> I am thinking that since JRE 1.6 contains the API and the
default
>> implementation, do we still need to ship another one ?
>
> Well, I would say get rid of stax-api, but keep wstx. I think
the 4.x
> versions of woodstox are bundles. If not, ServiceMix has
bundles for them.
>
> The parser in the JDK sucks from a performance standpoint. We
recently tried
> to use the JDK parser in CXF and the complete test run took
nearly 25% longer.
> Adding woodstox back in brought it right back down to the normal
times.
> Testing on "real" web services backed that up.
>
> Basically, the in JDK Stax parser will work, but woodstox is so
much faster.
> If you aren't doing anything performance critical with XML, not
using woodstox
> might be OK.
>
I'd prefer to use our spec api jar although I won't insist on it.
We should be using the servicemix woodstox bundle already -- if
wstx-asl is still getting pulled in we need to find out how and
add a maven exclusion for it. If v4 is out an already a bundle,
even better :-)
thanks
david jencks
>
> --
> Daniel Kulp
> [email protected] <mailto:[email protected]>
> http://dankulp.com/blog
--
Ivan
