You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Serge Merzliakov <sm...@epistatic.net> on 2010/01/27 10:52:27 UTC
Re: service interface classes not being exported into bundle -
ClassCastException
Richard,
I got it working by doing as you suggested below and buy taking a look at
the samples in subversion. I did the 3 things:
a) take the service interface package out of the implementation
bundle
b) changed implementation bundles manifest to import interface
c) Then add the package to the class path via
system.packages.extra
Thanks,
Serge
Richard S. Hall wrote:
>
> On 1/25/10 17:22, Serge Merzliakov wrote:
>> Re felix.bundle.dictionary - this is the package which is contains the
>> dictionary implementation inside the bundle, and so I thought this is
>> what
>> the bundle needs to export as its 'services offered'.
>>
>
> Yes, but the implementation must get the interface it is implementing
> from the class path. In that tutorial example, the interface is packaged
> in the same bundle as the implementation and the bundle doesn't import
> the package. What you will want to do is take the service interface
> package out of the impl bundle (or at a minimum, change its metadata so
> it only imports it). Then add the package to the class path of your
> application and export it from the system bundle using the
> ...system.packages property.
>
>> I am trying to see how a client of some kind (either a host application
>> or
>> another bundle) uses a service provided by a bundle. From the samples, it
>> appears that an interface is created which is shared by client and
>> bundle,
>> with the only catch being that both need to share the same Class<?>
>> instance
>> (loaded from a common classloader - the hosts).
>>
>> If a bundle just exports a package or service of which host app or other
>> bundles do not share a common interface (e.g. a dictionary service with
>> no
>> interface known to client), then the only way to invoke it is to use the
>> reflection API.
>>
>> I thought the way host and client share the same Class<?> instance was
>> through the config setup:
>>
>> config.put(Constants.FRAMEWORK_SYSTEMPACKAGES_EXTRA,
>> "felix.bundle.dictionary.DictionaryService");
>>
>
> This just exposes classes already on the class path, but you have to put
> them on the class path first. See above.
>
> This example also shows an embedded cased:
>
>
> http://felix.apache.org/site/apache-felix-application-demonstration.html
>
> It actually works as a bundle or a stand-alone application.
>
> -> richard
>
>> My ultimate goal is to create a set of java interfaces which have
>> different
>> implementations inside OSGi bundles (1 implementation per bundle) and the
>> decision about which implementation (bundle) to load could be made at
>> runtime.
>>
>> Serge
>>
>>
>>
>> Richard S. Hall wrote:
>>
>>> Why are you making the felix.bundle.dictionary package available inside
>>> from a bundle in the first place?
>>>
>>> If you want to share packages between the host app and bundles inside
>>> the framework, then these packages should be on the class path. There is
>>> really no reason to include them packaged inside of bundles too.
>>>
>>> -> richard
>>>
>>> On 1/25/10 0:35, Serge Merzliakov wrote:
>>>
>>>> Hello,
>>>> I am having trouble with the OSGI tutorials, with the host
>>>> application
>>>> using a bundle service (Tutorial 2 - dictionary service). I have read
>>>> previous posts on classloader issues between host app and bundles and
>>>> also
>>>> read (apache-felix-framework-launching-and-embedding.html) page as
>>>> well.
>>>>
>>>> My problem is that despite trying to 'inject' the service interface
>>>> class
>>>> from the host into the bundle, as detailed in Felix pages above, the
>>>> bundle
>>>> is still using its own service interface, causing the
>>>> ClassCastException.
>>>> I
>>>> have shown this to be the case as if use:
>>>>
>>>> Class<?> bundleInstance =
>>>> felix.getBundleContext().getBundle(1).loadClass("felix.bundle.dictionary.DictionaryService");
>>>> Object dictionary =
>>>> bundleInstance.cast(felix.getBundleContext().getService(ref))
>>>>
>>>> then it works. I find this very 'clunky' and would much rather do:
>>>>
>>>> DictionaryService dictionary = (DictionaryService)
>>>> felix.getBundleContext().getService(ref);
>>>>
>>>> I have attached my host application and would appreciate any feeback as
>>>> to
>>>> how to solve the classloader issue (I have seen the HostActivator code,
>>>> and
>>>> tried it, but fail to see how that would solve my problem).
>>>>
>>>>
>>>> Serge
>>>>
>>>>
>>>> /***********************************************/
>>>> public static void main(String[] argv) throws Exception
>>>> {
>>>> System.out.println("\nWelcome to Felix.");
>>>>
>>>> try
>>>> {
>>>> Properties config = new Properties();
>>>> config.setProperty(AutoProcessor.AUTO_DEPLOY_ACTION_PROPERY,
>>>> "install,start");
>>>> config.setProperty(AutoProcessor.AUTO_DEPLOY_DIR_PROPERY,
>>>> "/Users/serge/dev/osgi/Felix/bundle");
>>>> config.put(Constants.FRAMEWORK_SYSTEMPACKAGES_EXTRA,
>>>> "felix.bundle.dictionary.DictionaryService");
>>>>
>>>> felix = getFrameworkFactory().newFramework(config);
>>>> felix.init();
>>>> AutoProcessor.process(config, felix.getBundleContext());
>>>> felix.start();
>>>>
>>>> ServiceReference ref =
>>>> felix.getBundleContext().getServiceReference(DictionaryService.class.getName());
>>>>
>>>> Class<?> hostClassInstance = DictionaryService.class; //
>>>> hosts
>>>> version
>>>> Class<?> bundleClassInstance =
>>>> felix.getBundleContext().getBundle(1).loadClass("felix.bundle.dictionary.DictionaryService");
>>>> //bundle version
>>>>
>>>> // -------- !!!!
>>>> // THIS LINE FAILS BECAUSE hostClassInstance !=
>>>> bundleClassInstance
>>>> DictionaryService svc = (DictionaryService)
>>>> felix.getBundleContext().getService(ref);
>>>> // ---------- !!!!
>>>>
>>>> boolean found = svc.checkWord("hello");
>>>> System.out.println("word hello exists - " + found);
>>>>
>>>> felix.waitForStop(4000);
>>>> felix.getBundleContext().ungetService(ref); //reference
>>>> counting
>>>> for bundle unloading
>>>> System.exit(0);
>>>> }
>>>> catch (Exception ex)
>>>> {
>>>> .......
>>>> }
>>>> }
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
>
--
View this message in context: http://old.nabble.com/service-interface-classes-not-being-exported-into-bundle---ClassCaseException-tp27302355p27335620.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: service interface classes not being exported into bundle - ClassCastException
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Great! No problem.
-> richard
On 1/27/10 4:52, Serge Merzliakov wrote:
> Richard,
> I got it working by doing as you suggested below and buy taking a look at
> the samples in subversion. I did the 3 things:
>
> a) take the service interface package out of the implementation
> bundle
> b) changed implementation bundles manifest to import interface
> c) Then add the package to the class path via
> system.packages.extra
>
>
> Thanks,
> Serge
>
>
> Richard S. Hall wrote:
>
>> On 1/25/10 17:22, Serge Merzliakov wrote:
>>
>>> Re felix.bundle.dictionary - this is the package which is contains the
>>> dictionary implementation inside the bundle, and so I thought this is
>>> what
>>> the bundle needs to export as its 'services offered'.
>>>
>>>
>> Yes, but the implementation must get the interface it is implementing
>> from the class path. In that tutorial example, the interface is packaged
>> in the same bundle as the implementation and the bundle doesn't import
>> the package. What you will want to do is take the service interface
>> package out of the impl bundle (or at a minimum, change its metadata so
>> it only imports it). Then add the package to the class path of your
>> application and export it from the system bundle using the
>> ...system.packages property.
>>
>>
>>> I am trying to see how a client of some kind (either a host application
>>> or
>>> another bundle) uses a service provided by a bundle. From the samples, it
>>> appears that an interface is created which is shared by client and
>>> bundle,
>>> with the only catch being that both need to share the same Class<?>
>>> instance
>>> (loaded from a common classloader - the hosts).
>>>
>>> If a bundle just exports a package or service of which host app or other
>>> bundles do not share a common interface (e.g. a dictionary service with
>>> no
>>> interface known to client), then the only way to invoke it is to use the
>>> reflection API.
>>>
>>> I thought the way host and client share the same Class<?> instance was
>>> through the config setup:
>>>
>>> config.put(Constants.FRAMEWORK_SYSTEMPACKAGES_EXTRA,
>>> "felix.bundle.dictionary.DictionaryService");
>>>
>>>
>> This just exposes classes already on the class path, but you have to put
>> them on the class path first. See above.
>>
>> This example also shows an embedded cased:
>>
>>
>> http://felix.apache.org/site/apache-felix-application-demonstration.html
>>
>> It actually works as a bundle or a stand-alone application.
>>
>> -> richard
>>
>>
>>> My ultimate goal is to create a set of java interfaces which have
>>> different
>>> implementations inside OSGi bundles (1 implementation per bundle) and the
>>> decision about which implementation (bundle) to load could be made at
>>> runtime.
>>>
>>> Serge
>>>
>>>
>>>
>>> Richard S. Hall wrote:
>>>
>>>
>>>> Why are you making the felix.bundle.dictionary package available inside
>>>> from a bundle in the first place?
>>>>
>>>> If you want to share packages between the host app and bundles inside
>>>> the framework, then these packages should be on the class path. There is
>>>> really no reason to include them packaged inside of bundles too.
>>>>
>>>> -> richard
>>>>
>>>> On 1/25/10 0:35, Serge Merzliakov wrote:
>>>>
>>>>
>>>>> Hello,
>>>>> I am having trouble with the OSGI tutorials, with the host
>>>>> application
>>>>> using a bundle service (Tutorial 2 - dictionary service). I have read
>>>>> previous posts on classloader issues between host app and bundles and
>>>>> also
>>>>> read (apache-felix-framework-launching-and-embedding.html) page as
>>>>> well.
>>>>>
>>>>> My problem is that despite trying to 'inject' the service interface
>>>>> class
>>>>> from the host into the bundle, as detailed in Felix pages above, the
>>>>> bundle
>>>>> is still using its own service interface, causing the
>>>>> ClassCastException.
>>>>> I
>>>>> have shown this to be the case as if use:
>>>>>
>>>>> Class<?> bundleInstance =
>>>>> felix.getBundleContext().getBundle(1).loadClass("felix.bundle.dictionary.DictionaryService");
>>>>> Object dictionary =
>>>>> bundleInstance.cast(felix.getBundleContext().getService(ref))
>>>>>
>>>>> then it works. I find this very 'clunky' and would much rather do:
>>>>>
>>>>> DictionaryService dictionary = (DictionaryService)
>>>>> felix.getBundleContext().getService(ref);
>>>>>
>>>>> I have attached my host application and would appreciate any feeback as
>>>>> to
>>>>> how to solve the classloader issue (I have seen the HostActivator code,
>>>>> and
>>>>> tried it, but fail to see how that would solve my problem).
>>>>>
>>>>>
>>>>> Serge
>>>>>
>>>>>
>>>>> /***********************************************/
>>>>> public static void main(String[] argv) throws Exception
>>>>> {
>>>>> System.out.println("\nWelcome to Felix.");
>>>>>
>>>>> try
>>>>> {
>>>>> Properties config = new Properties();
>>>>> config.setProperty(AutoProcessor.AUTO_DEPLOY_ACTION_PROPERY,
>>>>> "install,start");
>>>>> config.setProperty(AutoProcessor.AUTO_DEPLOY_DIR_PROPERY,
>>>>> "/Users/serge/dev/osgi/Felix/bundle");
>>>>> config.put(Constants.FRAMEWORK_SYSTEMPACKAGES_EXTRA,
>>>>> "felix.bundle.dictionary.DictionaryService");
>>>>>
>>>>> felix = getFrameworkFactory().newFramework(config);
>>>>> felix.init();
>>>>> AutoProcessor.process(config, felix.getBundleContext());
>>>>> felix.start();
>>>>>
>>>>> ServiceReference ref =
>>>>> felix.getBundleContext().getServiceReference(DictionaryService.class.getName());
>>>>>
>>>>> Class<?> hostClassInstance = DictionaryService.class; //
>>>>> hosts
>>>>> version
>>>>> Class<?> bundleClassInstance =
>>>>> felix.getBundleContext().getBundle(1).loadClass("felix.bundle.dictionary.DictionaryService");
>>>>> //bundle version
>>>>>
>>>>> // -------- !!!!
>>>>> // THIS LINE FAILS BECAUSE hostClassInstance !=
>>>>> bundleClassInstance
>>>>> DictionaryService svc = (DictionaryService)
>>>>> felix.getBundleContext().getService(ref);
>>>>> // ---------- !!!!
>>>>>
>>>>> boolean found = svc.checkWord("hello");
>>>>> System.out.println("word hello exists - " + found);
>>>>>
>>>>> felix.waitForStop(4000);
>>>>> felix.getBundleContext().ungetService(ref); //reference
>>>>> counting
>>>>> for bundle unloading
>>>>> System.exit(0);
>>>>> }
>>>>> catch (Exception ex)
>>>>> {
>>>>> .......
>>>>> }
>>>>> }
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> 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