I hear you, but you're talking about the implementations, not the specs, right ?
Last week, we discussed a problem resulting in hiding the javax.xml.stream package. When hiding that package, the javax.xml.transform.stax isn't usable anymore and that one isn't really provided by any spec, so we'd have to find a way to ship JAXP again. The solution I'm experimenting would really be to hack (by using endorsed jars) the specs, but provide the implementation as bundles (that would be shipped by default by ServiceMix when it makes sense), and I do agree that Servicemix should provide a good out of the box experience on that. On Fri, Nov 18, 2011 at 16:16, Daniel Kulp <[email protected]> wrote: > > Well, I guess I have two questions/thoughts on this: > > 1) CAN we get them to support the in JDK versions? > 2) SHOULD we, specifically for ServiceMix, etc... Particularly by default. > > You've obviously been digging into the code to find the answer to #1. I'll > leave that to you. > > However, for #2, I STRONGLY STRONGLY feel that the default SMX installs > need > to provide a high quality and consistent experience for the users. To me, > that means making sure we have the in-jdk versions blocked and provide > bundles > to provide that functionality. With the exception of XSLT/XPath, the > versions in the JDK are buggy and way behind the versions that are > available > (and that we test with for the most part). What's worse, the versions in > the > JDK are very inconsistent. Depending on what version of the JDK the user > uses, they can get COMPLETELY different results. Also, IBM JDK is very > different than Sun's which is different than the Oracle JRocket which is > different than the Mac, etc..... Couple of examples: > > StAX - the version in the JDK is very slow, buggy (has issues with some > namespace handling, large text contents, etc..), and the factories are not > thread safe. If the libraries/users are used to Woodstox, they might not > even realize that last point and you can get all kinds of issues. > > JAXB - the version in the JDK up to _26 causes thread local leaks and jar > locking of applications preventing undeploys, causes PermGen contention, > and > has other issues. _27 updated to a version that fixes that, but the later > versions provide fixes for 3 other things that CXF users have reported. I > don't think the Mac JDK has been updated to even that level yet. Not > sure on > the IBM JDK. > > Unfortunately, the XSLT stuff is the big exception. Xalan hasn't done a > release in a long time and the version in the JDK is quite a bit ahead of > the > last xalan release. (supports StAXSource for example) > > In any case, I strongly feel we need to make sure that SMX "out of the box" > provides the best experience for the users and, more importantly, the most > consistent and supportable experience for us just to reduce the support > load. > Not knowing what versions of various technologies the users are using will > just cause us a lot more headaches. > > > Dan > > > > > On Thursday, November 17, 2011 2:15:28 PM Guillaume Nodet wrote: > > Deploying java specs jars and providers is a bit tricky in osgi, even > when > > using the servicemix specs. > > I think we face two problems: > > * when deploying a spec bundle, we need to hide the packages from the > jre > > and by doing so we forbid the use of the implementation provided by the > jre > > * when deploying an implementation, it won't be available until the > > bundle is started but this constraint isn't captured > > > > For the first problem, I was thinking about deploying the specs jars in > the > > lib/endorsed dir so that they would be used.by the jre and enhance them > so > > that they would be able to discover the implementations in bundles but > also > > in the jre. This would work as they would use the same packages. This > may > > require some modifications in karaf, though i'm not sure yet. > > > > For the second point, i'm still hoping that the Generic Capabilities > > introduced in osgi 4.3 can be leveraged fo that. I think that's aso > > related to obr. > > > > Anyway, i'd like to find a solution to those problems, so any idea is of > > course welcomed. > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
