Hi Felix, Yes I'm aware that there are sometimes problems, that's why I said that "in general" you don't need to worry. There are times when one doesn't need to worry, but I'd like to know more specific's about OP's scenario.
I'm very familiar with the javax.transaction.xa problem... it's the quintessential split package! Incidentally I'm quite willing to strangle whoever decided to allow this split package in the JRE. Unfortunately just removing from system bundle exports it is not a solution because javax.sql has a uses constraint on javax.transaction.xa. My preferred solution is to get hold of a copy of the full JTA library and put it on the application classpath. I also add an extra system bundle export with version 1.0.0 (i.e. in addition to 0.0.0), because there are some bundles that import the package as version [1.0,2.0). Anyway, splitting up the Felix properties sounds like a useful thing to do. Of course it would only work for Felix, and the OSGi spec would still define the monolithic property unfortunately. Regards Neil On Thu, Aug 22, 2013 at 12:45 PM, Felix Meschberger <[email protected]> wrote: > Hi Neil > > Am 22.08.2013 um 13:04 schrieb Neil Bartlett: > >> It's possible, but unfortunately quite cumbersome. There is no way to >> remove a single package, instead you have to list all of the packages >> you still want using the 'org.osgi.framework.system.packages' >> property. So you'll have to copy the existing value and then remove >> just the package you don't want. >> >> However, why do you need to do this? There is in general no need to >> remove system exports just because another bundle exports the package; >> OSGi can cope with multiple exports of the same package. > > That's the theory which unfortunately breaks in certain contexts. > > Take for example javax.transaction: The Java platform (at least in Java 6 > where this example comes from) provides a subset of this package. The > separate JTA library has the full package. Consider an application compiled > against this library: It will import the JTA package with no version (unless > you build the bundle with a JTA bundle in the class path such as the Geronimo > bundle or explicitly state the imports). > > When deploying such a bundle along with the JTA API bundle you will realize > that more often than not your JTA consumer bundle will wire to the platform > export through the system bundle instead of to the JTA API bundle. Add to > this soup a case where multiple bundles use the JTA API: Some have proper > imports and wire to the JTA API bundle, some don't and wire to the system > bundle. The end result is, that the application just breaks. > > So, maybe we in Felix should really just expose the java.* packages in the > ..system.packages property and expose the javax.* package in some > ..packages.extra mechanism which makes it easy to "omit" them from being > exposed ? > > Regards > Felix > >> >> Incidentally you can easily *add* individual packages by listing them >> with the 'org.osgi.framework.system.packages.extra' property. >> >> Neil >> >> On Thu, Aug 22, 2013 at 11:48 AM, bieniekmat <[email protected]> wrote: >>> Hello, >>> >>> Thanks for creating Felix, I love it! >>> >>> Felix exports many useful packages using org.osgi.framework.system.packages, >>> but it also exports a package that I do not want. I export my own version of >>> the package with one of the bundles. >>> >>> Is there any way I could specify that I do not want Felix framework to >>> export a javax.X package? >>> >>> >>> Thanks! >>> >>> >>> >>> -- >>> View this message in context: >>> http://apache-felix.18485.x6.nabble.com/Specify-packages-that-should-not-be-exported-by-Felix-framework-tp5004647.html >>> Sent from the Apache Felix - Users mailing list archive at Nabble.com. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
