felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: System packages should not contain osgi.core packages (packages that are exported by the framework)
Date Tue, 27 Oct 2015 20:27:27 GMT
On 10/27/15 16:10 , Balázs Zsoldos wrote:
> I guess your needs came from an environment I am not familiar with. I have
> never had to use Permissions within OSGi, so I must discontinue the
> argument here (until I get familiar once with OSGi security ;-) ).
>
> Probably the different opinions come from the name "system.packages". If
> there were "framework.packages" and "environment.packages" that would give
> a better separation. The chance of having such discussion has gone long ago.

Considering that the system bundle is called a "system" bundle, then it 
would seem that the relationship to "system" packages would be clear... :-)

> Anyway, I would like to ask kindly you if it is possible to implement the
> idea that you (Richard) proposed in one of your previous emails:
>
> org.osgi.framework.system.packages= ${dollar}{framework-exports} \
>   ${dollar}{jre-${dollar}{java.specification.version}}
>
> That could save lots of work in the future for developers who want to
> specify explicitly those JDK packages they need. I hope that in one day all
> packages can come from bundles (all, even swing or other built-in
> solutions), and we need to export only the framework packages.

You can certainly create an issue for this...

-> richard

>
>
> On Tue, Oct 27, 2015 at 6:33 PM, Richard S. Hall <heavy@ungoverned.org>
> wrote:
>
>> On 10/27/15 13:27 , Balázs Zsoldos wrote:
>>
>>> Also, we used to package some framework services separately (e.g.,
>>>> PackageAdmin, etc.) and some framework still might, so this assumption
>>>> also
>>>> is not correct.
>>>>
>>> I am wondering why PackageAdmin had to be re-implemented. If it was
>>> possible to re-implement it based on other features of OSGi Core, does
>>> that
>>> mean that OSGi Core contained something that it should not have? If some
>>> services can be implemented based on others, they are more like libraries
>>> than part of the core.
>>>
>> I didn't say it was re-implemented, I said it was packaged separately. We
>> still do, for example, package the permission-related services separately.
>> It did, however, use some special hooks to do what it needed to do.
>>
>> -> richard
>>
>>
>>
>>> E.g.: BundleTracker and ServiceTracker is part of a very helpful library.
>>> It can be implemented based on OSGi Core. I am probably alone with the
>>> opinion that is should not have been moved into OSGi Core. Also, it is
>>> another discussion (I am sure this was discussed internally before
>>> releasing OSGi Core 5).
>>>
>>>
>>> On Tue, Oct 27, 2015 at 6:08 PM, Richard S. Hall <heavy@ungoverned.org>
>>> wrote:
>>>
>>> On 10/27/15 11:27 , Balázs Zsoldos wrote:
>>>> @David:
>>>>> I know about the *org.osgi.framework.system.**packages.extra* property,
>>>>> but
>>>>> that is about another use-case.
>>>>>
>>>>> *org.osgi.framework.system.**packages.extra *can be used to extend the
>>>>> list
>>>>> of system packages.
>>>>> *org.osgi.framework.system.**packages* can be used to reduce the list
of
>>>>> the system packages.
>>>>>
>>>>> I want to reduce the list of system packages as some packages are coming
>>>>> from bundles. More specifically, I want to list only those packages
>>>>> that I
>>>>> actually need from the JDK. Reason: Many packages are incomplete or
>>>>> buggy
>>>>> in the JDK: javax.transaction.*, javax.xml.*...
>>>>>
>>>>> @Andy:
>>>>>
>>>>> The text at
>>>>>
>>>>>
>>>>> https://osgi.org/javadoc/r5/core/org/osgi/framework/Constants.html#FRAMEWORK_SYSTEMPACKAGES
>>>>>     says:* Framework launching property identifying packages which the
>>>>> system
>>>>> bundle must export.*
>>>>>
>>>>> "Must" does not mean that only those packages should be exported by the
>>>>> system bundle.
>>>>>
>>>>> @Everyone:
>>>>>
>>>>> Questions:
>>>>>
>>>>>       - What is the exact meaning of system packages from the
>>>>> perspective of
>>>>>       this setting? In my opinion, the list of packages that are coming
>>>>> outside
>>>>>       the OSGi container. org.osgi.* packages do not come outside from
>>>>> the
>>>>> OSGi
>>>>>       container.
>>>>>       - Could the org.osgi.* packages come from custom bundles? I think,
>>>>> no.
>>>>>       - Can you write an application that does not need any of the
>>>>> org.osgi.*
>>>>>       package? I think you cannot. At least one bundle has to implement
>>>>> an
>>>>>       Activator to have any kind of functionality in the system.
>>>>> Otherwise
>>>>> the
>>>>>       bundles will be resolved, but they will do nothing (not even a
>>>>> static
>>>>> block
>>>>>       will be called).
>>>>>       - Can you imagine any use-case where exporting org.osgi.* packages
>>>>> by
>>>>>       the system bundle could cause any issue? I cannot.
>>>>>
>>>>> Also, we used to package some framework services separately (e.g.,
>>>> PackageAdmin, etc.) and some framework still might, so this assumption
>>>> also
>>>> is not correct.
>>>>
>>>>       - Is it an extra work that org.osgi.* packages have to be appended
>>>> if
>>>>
>>>>>       system.packages are overridden? Yes, always.
>>>>>
>>>>> Sure, this is correct, but not really relevant to the meaning of system
>>>> packages.
>>>>
>>>> -> richard
>>>>
>>>>
>>>> If we answer these questions, we will come to the conclusion (at least I
>>>>> :)
>>>>> ) that org.osgi.* packages should always be exported by the system
>>>>> bundle.
>>>>> They are not in the scope of the meaning of system.packages setting.
>>>>>
>>>>>
>>>>> Kind regards,
>>>>> *Balázs **Zsoldos*
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Oct 27, 2015 at 3:21 PM, David Bosschaert <
>>>>> david.bosschaert@gmail.com> wrote:
>>>>>
>>>>> Yes, that's precisely what the
>>>>>
>>>>>> org.osgi.framework.system.packages.extra was designed for. That way
>>>>>> you don't need to remember what the framework puts on
>>>>>> org.osgi.framework.system.packages in order to augment it.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> David
>>>>>>
>>>>>> On 27 October 2015 at 14:18, Andy Lee <thelees.andy@gmail.com>
wrote:
>>>>>>
>>>>>> If you are trying to extend the set of packages exported by the system
>>>>>>> bundle, you should use org.osgi.framework.system.packages.extra.
 By
>>>>>>> specifying org.osgi.framework.system.packages you are overriding
the
>>>>>>> default value used by the framework, and hence must include the
>>>>>>> packaged
>>>>>>> that are expected to be supplied by the framework.
>>>>>>>
>>>>>>> See
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> https://osgi.org/javadoc/r5/core/org/osgi/framework/Constants.html#FRAMEWORK_SYSTEMPACKAGES
>>>>>>
>>>>>> --Andy
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Oct 27, 2015 at 10:00 AM, Balázs Zsoldos <
>>>>>>>
>>>>>>> balazs.zsoldos@everit.biz>
>>>>>> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>> I asked this 1-2 years ago, but I think it is worthy to 
ask it
>>>>>>>> again.
>>>>>>>>
>>>>>>>> Are you sure that the set of system packages should include
the OSGi
>>>>>>>>
>>>>>>>> core
>>>>>>> packages?
>>>>>>>
>>>>>>>> In my understanding:
>>>>>>>>
>>>>>>>>       - system packages are the ones coming from outside
of the OSGi
>>>>>>>>
>>>>>>>> container
>>>>>>>       - osgi core packages are offered by the framework bundle,
but
>>>>>>> they
>>>>>>> are
>>>>>>>       not system packages
>>>>>>>
>>>>>>>> In practice:
>>>>>>>>
>>>>>>>>       - If I specify org.osgi.system.packages property for
equinox, I
>>>>>>>> do
>>>>>>>>
>>>>>>>> not
>>>>>>>       have to define the packages implemented by the framework
>>>>>>>
>>>>>>>>       - If I specify the same property for felix, I must
copy-paste
>>>>>>>> the
>>>>>>>>       packages of osgi.core always
>>>>>>>>
>>>>>>>> Do you think there is a use-case when osgi.core packages
offered by
>>>>>>>> the
>>>>>>>> framework should be excluded from the exported packages of
the system
>>>>>>>> bundle? I think Equinox has the right behavior here.
>>>>>>>>
>>>>>>>> Do you see any chance to change this behavior in the future?
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>> *Balázs **Zsoldos*
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message