Hi
Am 22.08.2013 um 14:49 schrieb Richard S. Hall:
> On 8/22/13 07:45 , Felix Meschberger 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 ?
>
> As Neil points out, it would be a Felix-only solution. At that rate, why
> not just invent our own property called felix.system.packages.exclude or
> something? Seems easier, because otherwise we'd have to duplicate the
> exported classes in some fashion since the framework is supposed to
> provide a "reasonable" default set of exports when started with no
> configuration (i.e., no conf/config.properties file). I would think the
> javax.* is included in that reasonable default, which means those
> classes have to appear in default.properties in felix.jar, but
> properties for users to edit are in conf/config.properties...thus they'd
> need to be duplicated.
The idea would be something like:
felix.javax.xml = javax.xml,...
felix.javax.sql = javax.sql,...
...packages.extra = ${felix.javax.xml},${felix.javax.sql},...
Now, when launching the framework you could do:
$ java -Dfelix.javax.sql= -jar bin/felix.jar
and the sql stuff would not be exposed.
Just an example and may not well thought through.
Regards
Felix
>
> -> richard
>
>>
>> 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]
