I am not sure it is a great idea for extenders to attempt to extend the system bundle (and its extension fragments). The point of extension fragments is to place important low level function (for example, subsystem isolation regions) in the system bundle so they are active before any normal bundles resolve. If an extension fragment wants to register a service, it should do it the old fashioned way: use the registerService API. There is no guarantee that an extender (e.g. DS) will ever be installed or started, so an extension bundle should not depend upon extenders to offer their function. --
BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Thomas Watson/Austin/IBM@IBMUS To: OSGi Developer Mail List <[email protected]> Date: 2013/10/28 09:17 Subject: Re: [osgi-dev] service from extension bundle? Sent by: [email protected] Perhaps the framework should be able to be configured to have a Service-Component header to allow framework extensions to have service components. Or maybe we can just have the system bundle have a specified Service-Component header by default that allows the searching of fragment component descriptions. I am pretty sure this would work on Equinox. But I seem to remember other frameworks not supporting loading resources from the system bundle (ala Bundle.findEntries) which is what the SCR needs to use to discover service components. Tom Raymond Auge ---10/27/2013 12:24:45 PM---While I'm sure this is well documented I just can't seem to find it. Is there any way to trigger the From: Raymond Auge <[email protected]> To: OSGi Developer Mail List <[email protected]>, Date: 10/27/2013 12:24 PM Subject: [osgi-dev] service from extension bundle? Sent by: [email protected] While I'm sure this is well documented I just can't seem to find it. Is there any way to trigger the activation of a service provided via an extension bundle on the system bundle? -- Raymond Augé (@rotty3000) Senior Software Architect Liferay, Inc. (@Liferay) _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
<<image/gif>>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
