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
