Hi Am 22.08.2013 um 13:56 schrieb Neil Bartlett:
> 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. Wow, they really f^Hmessed it up ;-) > 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. Yeah. Regards Felix > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
