> On Oct 27, 2015, at 18:45, Balázs Zsoldos <balazs.zsol...@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.
This portion of the conversation has definitely gotten off track and I am to blame since I was splitting hairs that shouldn’t have been split… Having said that, though, I did once create a custom launcher that simply probed installed JAR files for some metadata and kicked started the application from the outside (effectively, it was the extender pattern implemented directly in a framework launcher). This work really nicely, because it allowed the installed JAR files to benefit from module metadata, encapsulate, and dependency resolution, but there was no code in the application with any OSGi awareness. So, technically, in that case, the system bundle needn’t have exported any OSGi packages at all, since the launcher got access to them via the class path. See what kind of fun stuff you can do? :-) -> richard > > > On Tue, Oct 27, 2015 at 11:18 PM, Neil Bartlett <njbartl...@gmail.com> > wrote: > >> >>> On 27 Oct 2015, at 17:33, Balázs Zsoldos <balazs.zsol...@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 <he...@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 <he...@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.bosscha...@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.a...@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.zsol...@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-unsubscr...@felix.apache.org >>>>>>>> For additional commands, e-mail: users-h...@felix.apache.org >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>>>>> For additional commands, e-mail: users-h...@felix.apache.org >>>>>> >>>>>> >>>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>>> For additional commands, e-mail: users-h...@felix.apache.org >>>> >>>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
