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). 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). 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 <patrick.conre...@amd.com> 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:justinedel...@gmail.com] On Behalf Of Justin > Edelson > Sent: Wednesday, November 16, 2011 8:17 PM > To: users@felix.apache.org > 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" <patrick.conre...@amd.com> > 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: 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
