Hi, Am 17.11.2011 um 05:46 schrieb Justin Edelson:
> Ah. OK. Your email sounded to me like there was documentation which > *specifically* referred to the SCR Bundle. > > The problem you are running into is that the SCR Bundle does not > import org.apache.felix.scr. Compare this with the Event Admin bundle > which does import org.osgi.service.event. As a result, the SCR bundle > doesn't see the package exported by the system bundle (except if you > use bootdelegation). Exactly. The thing here is, that the SCR bundle is -- currently -- the only exporting the API so at development time we didn't really care to re-import our own export. > > As I see it you have two options: > 1) Patch the scr bundle to have it import the org.apache.felix.scr > package (as well as export it). Mybe this should be changed and the SCR bundle should just import its own API (just like it re-imports the OSGi component API). I have fixed this already in trunk for the next release (and deployed a SNAPSHOT). But then, you would have to make sure, that the system bundle exports the correct version for the SCR bundle to import ! Regards Felix > 2) Don't deploy the scr bundle and include the SCR bundle's activator > in the felix.systembundle.activators property so that the SCR service > is instantiated with the classloader of the system bundle rather than > its own bundle. > > HTH, > Justin > > > On Wed, Nov 16, 2011 at 7:52 PM, Conreaux, Patrick > <[email protected]> wrote: >> Hi Justin, >> >> I am attempting to utilize the ScrService from a host application. In order >> to use this service, I have used the following as a guide. >> http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html >> >> Here is an excerpt... >> "The main complication for the host application using a service from a >> bundle is the fact that both the host application and the bundle must be >> using the same class definitions for the service interface classes. Since >> the host application cannot import classes from a bundle, this means that >> the service interface classes must be accessible on the class path, >> typically as part of the host application itself. The host application then >> must export the service interface package via the system bundle so that >> bundles installed into the embedded framework instance can import it. This >> is achieved using the org.osgi.framework.system.packages.extra configuration >> property previously presented." >> >> Similarly, Neil Bartlett states the following in his blog entry on embedding >> OSGi..." You can publish a service from the System Bundle (i.e., the host >> application) and consume it from the bundles, OR you can publish a service >> from the bundles and consume it from the host application. The only >> limitation is that the service API (that is, the abstract Java interfaces) >> are exported by the System Bundle." (from >> http://njbartlett.name/2011/03/07/embedding-osgi.html) >> >> As I stated, this works fine for accessing the EventAdmin service, but not >> so for the ScrService. >> If this strategy is incorrect, do you have any guidance? >> >> Cheers, >> Patrick >> >> -----Original Message----- >> From: Justin Edelson [mailto:[email protected]] On Behalf Of Justin >> Edelson >> Sent: Wednesday, November 16, 2011 8:17 PM >> To: [email protected] >> Subject: Re: Embedded Felix ScrService ClassCastException >> >> Where is it documented to put the SCR bundle on the host app classpath and >> export it from the system bundle? That seems totally wrong and would make >> sense as the source of this issue. >> >> Justin >> >> On Nov 16, 2011, at 12:35 PM, "Conreaux, Patrick" <[email protected]> >> wrote: >> >>> Hi, >>> >>> I have encountered the following ClassCastException while attempting to >>> cast the ScrService object (from a ServiceTracker) in my host app. >>> Following the documented procedure, I have put the SCR jar on the host >>> app classpath and exported the org.apache.felix.scr package via the >>> org.osgi.framework.system.packages.extra property. >>> >>> java.lang.ClassCastException: >>> org.apache.felix.scr.impl.config.ConfigurationComponentRegistry cannot >>> be cast to org.apache.felix.scr.ScrService >>> >>> Using a similar approach, I can successfully obtain and cast the EventAdmin >>> service. >>> Also, I am successful if I instead list the the org.apache.felix.scr >>> package in the org.osgi.framework.bootdelegation property. >>> However, this is not the desirable solution as it breaks modularity. >>> >>> Any ideas? >>> >>> Installed bundles are the following: >>> org.apache.felix.shell-1.2.0.jar >>> org.apache.felix.scr-1.6.0.jar >>> org.apache.felix.configadmin-1.2.4.jar >>> org.apache.felix.eventadmin-1.2.14.jar >>> >>> Cheers, >>> Patrick >>> >>> >> >> --------------------------------------------------------------------- >> 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]
