felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Bartlett <njbartl...@gmail.com>
Subject Re: System packages should not contain osgi.core packages (packages that are exported by the framework)
Date Tue, 27 Oct 2015 22:51:34 GMT

> On 27 Oct 2015, at 22:45, Balázs Zsoldos <balazs.zsoldos@everit.biz> wrote:
> 
>> 
>> As an application developer, you don’t need to import anything from
>> extender bundles.
>> I would estimate that 90% of my bundles do not import anything from the
>> core OSGi framework, and I almost *never* write a BundleActivator.
> 
> 
> Probably "Import" was not the right word. As an application developer, you
> either have to implement BundleActivator, or use some technology that
> implements the extender pattern. That technology must either implement
> BundleActivator or use another technology that implements another extender
> pattern. And so on...
> 
> If org.osgi.framework is not part of the system packages, at least one of
> the bundles will not be able to resolve (the one that implements
> BundleActivator). As a result, no code will be executed in any of the
> bundles. (It can be executed if someone starts the framework
> programmatically than gets a class type from one of the bundles than
> instantiates it with reflection... I do not think anybody wants to do this).
> 
> In other words: The org.osgi.framework must ALWAYS export the
> org.osgi.framework package, otherwise no business logic will be executed.

Umm… yes. Luckily it already does this.

Sorry, struggling to see the deeper point you are making.


> 
> 
> On Tue, Oct 27, 2015 at 11:18 PM, Neil Bartlett <njbartlett@gmail.com>
> wrote:
> 
>> 
>>> On 27 Oct 2015, at 17:33, Balázs Zsoldos <balazs.zsoldos@everit.biz>
>> wrote:
>>> 
>>>> 
>>>> As an application developer, I don't need to implement the extender
>>>> pattern since framework developers have done that for me. It's all about
>>>> layers and perspective.
>>> 
>>> 
>>> As a technology developer, how would you implement an extender pattern
>>> without the framework packages? You could not. If those packages are not
>>> exported by the system bundle, you cannot implement the extender pattern.
>>> As an application developer, you could not import a bundle that
>> implements
>>> the extender pattern, as the bundle would not resolve.
>> 
>> 
>> As an application developer, you don’t need to import anything from
>> extender bundles.
>> 
>> I would estimate that 90% of my bundles do not import anything from the
>> core OSGi framework, and I almost *never* write a BundleActivator.
>> 
>> Regards,
>> Neil
>> 
>> 
>>> 
>>> You mean that the Framework developers should implement technologies like
>>> Declarative Services and include it into the Framework?
>>> 
>>> 
>>> On Tue, Oct 27, 2015 at 6:27 PM, Richard S. Hall <heavy@ungoverned.org>
>>> wrote:
>>> 
>>>> On 10/27/15 13:14 , Balázs Zsoldos wrote:
>>>> 
>>>>> That is not my interpretation. System packages are those packages
>> provided
>>>>>> by the system bundle. From a wiring perspective, all of the JRE
>> packages
>>>>>> look like they are coming from the system bundle just like the OSGi
>> core
>>>>>> packages, so your distinction doesn't really make sense to me.
>>>>>> 
>>>>> 
>>>>> Seems that we are different :). I interpret rules based on use-cases.
I
>>>>> cannot find any use-case where I wanted to handle framework packages
>> like
>>>>> JDK packages. On the other hand, I see use-cases where I want to handle
>>>>> them separately.
>>>>> 
>>>> 
>>>> It is much more consistent to defines system.packages like,
>>>> "system.packages represents all packages that will be exported by the
>>>> system bundle", instead of something like "system.packages represents
>> all
>>>> packages exported by the system bundle plus some additional packages
>> that
>>>> will tacked on but may vary by framework implementation".
>>>> 
>>>> 
>>>>> Wrong. The extender pattern is based almost wholly around such an
>>>>> approach.
>>>>> 
>>>>> 
>>>>> How would you implement the extender pattern without the framework
>>>>> packages?
>>>>> 
>>>> 
>>>> As an application developer, I don't need to implement the extender
>>>> pattern since framework developers have done that for me. It's all about
>>>> layers and perspective.
>>>> 
>>>> -> richard
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>> 
>>>>> On Tue, Oct 27, 2015 at 6:04 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.
>>>>>>> 
>>>>>>> That is not my interpretation. System packages are those packages
>>>>>> provided
>>>>>> by the system bundle. From a wiring perspective, all of the JRE
>> packages
>>>>>> look like they are coming from the system bundle just like the OSGi
>> core
>>>>>> packages, so your distinction doesn't really make sense to me.
>>>>>> 
>>>>>> 
>>>>>> 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).
>>>>>>> 
>>>>>>> Wrong. The extender pattern is based almost wholly around such
an
>>>>>> approach.
>>>>>> 
>>>>>> -> richard
>>>>>> 
>>>>>>    - Can you imagine any use-case where exporting org.osgi.* packages
>>>>>> by
>>>>>> 
>>>>>>>    the system bundle could cause any issue? I cannot.
>>>>>>>    - Is it an extra work that org.osgi.* packages have to be
>> appended
>>>>>>> if
>>>>>>>    system.packages are overridden? Yes, always.
>>>>>>> 
>>>>>>> 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
>> 
>> 


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


Mime
View raw message