Some minutes ago after reading the whole thread, I found the solution to my
problem. As Richard already mentioned I have to set the following property:
configMap.put("org.osgi.framework.bundle.parent", "app");
I think that your property does internally the same, or?
Anyway, now my environment is working again :-) Thanks!
BR,
Markus
2009/9/16 Karl Pauls <[email protected]>
> On Tue, Sep 15, 2009 at 4:53 PM, Markus Michel
> <[email protected]> wrote:
> > Hi!
> >
> > After upgrading to the new framework version 2.0.0 the same error
> occurred
> > again, although the event service is still listed in the boot delegation
> > property. Is there another way to solve my problem? Otherwise I probably
> > have to continue using the old framework version ...
>
> They way you set the bootdelegation has changed a little with the new
> framework version. You have to set:
>
> Constants.FRAMEWORK_BUNDLE_PARENT to
> Constants.FRAMEWORK_BUNDLE_PARENT_FRAMEWORK
>
> That should make it work again.
>
> regards,
>
> Karl
>
> > BTW: What happened to the shell command services? Why it isn't included
> in
> > the new version?
> >
> > BR,
> >
> > Markus
> >
> > 2009/7/15 Markus Michel <[email protected]>
> >
> >> I would like to thank you for your help. After adding my services and
> the
> >> event admin service to the boot delegation property, my environment was
> >> working fine. :-)
> >>
> >>
> >> BR,
> >>
> >> Markus
> >>
> >> 2009/7/14 Richard S. Hall <[email protected]>
> >>
> >>> I believe the issue is that you are exporting from the system bundle,
> plus
> >>> your bundle contains the same packages as you are exporting from the
> system
> >>> bundle.
> >>>
> >>> So, you have to make sure only one copy is being used. I think your
> bundle
> >>> was only exporting osgiServices.vehiclePushService. This means your
> bundle
> >>> will always get its own copy, since it doesn't import the package too.
> If
> >>> you import it too, then it would likely get wired to the system
> bundle's
> >>> export, since resolved packages are preferred and the system bundle
> will be
> >>> resolved first.
> >>>
> >>> As I mention in my other message, one way around this is in your
> embedded
> >>> mode, add the shared packages to the boot delegation property to get
> them to
> >>> always load from the class path. Note, if you are using trunk you will
> need
> >>> to set a new property to boot delegate to the app class loader
> >>> (org.osgi.framework.bundle.parent=app).
> >>>
> >>> -> richard
> >>>
> >>> On 7/14/09 3:55 PM, Markus Michel wrote:
> >>>
> >>>> Some weeks ago I tried to use this instructions to get my embedded
> felix
> >>>> instance working, but it didn't worked. Afterwards some guy on
> >>>> stackover.comgave me the hint to put the whole package to the system
> >>>>
> >>>> packages path. If I
> >>>> strictly follow the wiki entry the line within my intialization block
> >>>> should
> >>>> look like:
> >>>>
> >>>> configMap.put(FelixConstants.FRAMEWORK_SYSTEMPACKAGES_EXTRA,
> >>>> "osgiServices.vehiclePushService; version=1.0.0");
> >>>>
> >>>> <path to the service includings it's implementation within the host
> app>
> >>>>
> >>>> But if the entry only contains this value, I'm getting the class
> loading
> >>>> error again.
> >>>>
> >>>> Sorry, but I think that I have some problems in understanding the
> >>>> explanations on that site completely. As far as I understood it all
> >>>> packages
> >>>> within this property should be executed by the some class loader,
> which
> >>>> is
> >>>> used for the system bundle and all other bundles. Therefore there
> >>>> shouldn't
> >>>> occur any class loading problems, when the bundle tries to access the
> >>>> service. Am I wrong? Maybe you can give me a more detailed explanation
> >>>> ...
> >>>>
> >>>> Unfortunately the felix environment has to run in the embedded mode
> >>>> within
> >>>> my program, because I want to run and control several osgi instances
> at
> >>>> once. I hope that we will be able to solve my problem ...
> >>>>
> >>>> BR,
> >>>>
> >>>> Markus
> >>>>
> >>>> 2009/7/14 Richard S. Hall<[email protected]>
> >>>>
> >>>>
> >>>>
> >>>>> You should read:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html
> >>>>>
> >>>>> It gives some pointers to running with an embedded framework
> instance.
> >>>>> In
> >>>>> short, your app and all bundles should go through the class path
> (i.e.,
> >>>>> system bundle) for any packages shared between the host app and the
> >>>>> bundles.
> >>>>>
> >>>>> To make sure this happens, you could actually put the host/bundle
> shared
> >>>>> packages on the boot class path property to make sure everyone gets
> the
> >>>>> same
> >>>>> ones, no matter how the bundles are wired internally. This at least
> has
> >>>>> the
> >>>>> benefit that your bundles will work properly when not used in the
> >>>>> embedded
> >>>>> situation.
> >>>>>
> >>>>> I knew there was more than what met the eye here. :-)
> >>>>>
> >>>>> Embedded mode is alluring to a lot of people coming to OSGi, but
> there
> >>>>> are
> >>>>> lots of hidden issues with it, so better to avoid it if you can.
> >>>>>
> >>>>> -> richard
> >>>>>
> >>>>>
> >>>>> On 7/14/09 1:53 PM, Markus Michel wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> You are right. If I remove that line, I'm able to load the event
> admin
> >>>>>> service. But the problem is that I cannot remove it, because other
> >>>>>> parts
> >>>>>> of
> >>>>>> my program depends on that information: My "vehiclePushService" is
> >>>>>> mostly
> >>>>>> implemented (and started) within the host application but some parts
> >>>>>> are
> >>>>>> implemented within the bundle. If I do not add "vehiclePushService"
> to
> >>>>>> that
> >>>>>> line, I'm getting the class loading exception
> >>>>>>
> >>>>>> java.lang.ClassCastException:
> >>>>>> osgiServices.vehiclePushService.VehiclePushServiceImpl cannot be
> cast
> >>>>>> to
> >>>>>> osgiServices.vehiclePushService.VehiclePushService
> >>>>>>
> >>>>>> , when the bundle tries to use the service. Maybe I have to add the
> >>>>>> event
> >>>>>> admin service to that line, too?!?
> >>>>>>
> >>>>>> BR,
> >>>>>>
> >>>>>> Markus
> >>>>>>
> >>>>>> -----
> >>>>>>
> >>>>>> Markus,
> >>>>>>
> >>>>>> Yes, I believe your embedded configuration is the issue. Why are you
> >>>>>> doing
> >>>>>> this:
> >>>>>>
> >>>>>> configMap.put(FelixConstants.FRAMEWORK_SYSTEMPACKAGES_EXTRA,
> >>>>>> "osgiServices.vehicleCommunicationService;
> >>>>>> osgiServices.vehiclePushService;
> >>>>>> vehiclePushService; vehicleCommunicationService");
> >>>>>>
> >>>>>> ?
> >>>>>>
> >>>>>> It seems like this is incorrect, since your bundle contains these
> >>>>>> packages.
> >>>>>> Try removing this and see what happens.
> >>>>>>
> >>>>>> Hi Richard!
> >>>>>>
> >>>>>> Here's the bundle which tries to use the felix event admin service.
> If
> >>>>>> you
> >>>>>> wish I can provide you the sources of the bundle, too.
> >>>>>>
> >>>>>> If you want to use the bundle, you have to load the following
> bundles:
> >>>>>>
> >>>>>> org.apache.felix.shell-1.2.0.jar
> >>>>>> org.apache.felix.shell.tui-1.2.0.jar
> >>>>>> org.apache.felix.eventadmin-1.0.0.jar
> >>>>>> VehiclePushService_1.0.0.jar
> >>>>>>
> >>>>>> Some minutes ago I noticed that the bundle can be loaded
> successfully
> >>>>>> if
> >>>>>> you
> >>>>>> run it directly from a command-line-based felix instance. The error
> >>>>>> only
> >>>>>> occures if you try to run it
> >>>>>> as an embedded version. Very confusing.
> >>>>>>
> >>>>>> Maybe there's something wrong with the configuration of my felix
> >>>>>> instance:
> >>>>>>
> >>>>>> private void initialize()
> >>>>>> {
> >>>>>> // create new map for storing the felix configuration
> >>>>>> properties
> >>>>>> configMap = new HashMap<String, Object>();
> >>>>>>
> >>>>>> // export the host provided service interface package
> >>>>>> configMap.put(FelixConstants.FRAMEWORK_SYSTEMPACKAGES_EXTRA,
> >>>>>> "osgiServices.vehicleCommunicationService;
> >>>>>> osgiServices.vehiclePushService;
> >>>>>> vehiclePushService; vehicleCommunicationService");
> >>>>>>
> >>>>>> // add autoactivator that specifies all services that shall
> be
> >>>>>> loaded together with the system bundle
> >>>>>> List<Object> list = new ArrayList<Object>();
> >>>>>> list.add(new AutoActivator(configMap));
> >>>>>>
> >>>>>> // create service activators
> >>>>>> vehicleCommunicationServiceActivator = new
> >>>>>> VehicleCommunicationServiceActivator(connection);
> >>>>>> list.add(vehicleCommunicationServiceActivator);
> >>>>>>
> >>>>>> vehiclePushServiceActivator = new
> >>>>>> VehiclePushServiceActivator();
> >>>>>> list.add(vehiclePushServiceActivator);
> >>>>>>
> >>>>>> // add service activators to felix instance
> >>>>>> configMap.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP,
> >>>>>> list);
> >>>>>>
> >>>>>> // set felix-cache folder
> >>>>>> configMap.put("org.osgi.framework.storage", "felix-cache/" +
> >>>>>> id);
> >>>>>> }
> >>>>>>
> >>>>>>
> >>>>>> BR,
> >>>>>>
> >>>>>> Markus
> >>>>>>
> >>>>>> -------
> >>>>>>
> >>>>>> 2009/7/14 Richard S. Hall<[email protected]>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> I don't see anything that immediately looks incorrect. If you want
> to
> >>>>>>> send
> >>>>>>> me your bundle (privately) with the steps to reproduce, I will look
> at
> >>>>>>> it.
> >>>>>>>
> >>>>>>> -> richard
> >>>>>>>
> >>>>>>>
> >>>>>>> On 7/14/09 4:20 AM, Markus Michel wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> Hi Richard!
> >>>>>>>>
> >>>>>>>> Of course I can provide more informations. The manifest file of
> the
> >>>>>>>> bundle
> >>>>>>>> looks like this:
> >>>>>>>>
> >>>>>>>> Manifest-Version: 1.0
> >>>>>>>> Bundle-ManifestVersion: 2
> >>>>>>>> Bundle-Name: VehiclePushService
> >>>>>>>> Bundle-SymbolicName: VehiclePushService
> >>>>>>>> Bundle-Version: 1.0.0
> >>>>>>>> Bundle-Activator: vehiclePushService.Activator
> >>>>>>>> Import-Package: org.osgi.framework;version="1.3.0",
> >>>>>>>> org.osgi.service.event;version="1.1.0",
> >>>>>>>> vehiclePushService
> >>>>>>>> Bundle-RequiredExecutionEnvironment: JavaSE-1.6
> >>>>>>>> Bundle-ClassPath: .,
> >>>>>>>> vehiclePushService.jar
> >>>>>>>> Export-Package:
> >>>>>>>> osgiServices.vehiclePushService,
> >>>>>>>> vehiclePushService
> >>>>>>>>
> >>>>>>>> The content of the bundle looks as follows:
> >>>>>>>>
> >>>>>>>> META-INF/
> >>>>>>>> META-INF/MANIFEST.MF
> >>>>>>>> hostApplication/
> >>>>>>>> hostApplication/vehiclePushService/
> >>>>>>>> osgiFramework/
> >>>>>>>> osgiFramework/vehiclePushService/
> >>>>>>>> vehiclePushService/
> >>>>>>>> META-INF/.classpath
> >>>>>>>> META-INF/.project
> >>>>>>>> vehiclePushService.jar
> >>>>>>>> vehiclePushService/Activator.class
> >>>>>>>> vehiclePushService/OSGiPosition2D.class
> >>>>>>>> vehiclePushService/OSGiVehicle.class
> >>>>>>>> vehiclePushService/OSGiVehiclePushService.class
> >>>>>>>> vehiclePushService/VehicleListener.class
> >>>>>>>> vehiclePushService/VehiclePushEvent.class
> >>>>>>>> vehiclePushService/VehiclePushServiceHandler.class
> >>>>>>>>
> >>>>>>>> Because inside the plug-in dependencies org.eclipse.services is
> >>>>>>>> referenced
> >>>>>>>> I
> >>>>>>>> think that the bundles currently uses the equinox implementation
> of
> >>>>>>>> the
> >>>>>>>> eventadmin service. Later on I will try to load the equinox
> >>>>>>>> eventadmin
> >>>>>>>> service instead
> >>>>>>>> of the felix eventadmin service. Maybe it's then possible to start
> my
> >>>>>>>> bundle
> >>>>>>>> ...
> >>>>>>>>
> >>>>>>>> BR,
> >>>>>>>>
> >>>>>>>> Markus
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 2009/7/13 Richard S. Hall<[email protected]>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On 7/13/09 2:47 PM, Markus Michel wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Hi there!
> >>>>>>>>>>
> >>>>>>>>>> Today I wanted to add the eventadmin service to my OSGi
> >>>>>>>>>> environment.
> >>>>>>>>>> Therefore I extended the import block of my bundle, which is
> >>>>>>>>>> created
> >>>>>>>>>> within
> >>>>>>>>>> an eclipse equinox project, with org.osgi.service.event. After
> >>>>>>>>>> loading
> >>>>>>>>>> the
> >>>>>>>>>> service I tried to access it by running the following command:
> >>>>>>>>>>
> >>>>>>>>>> // get service reference to event admin service
> >>>>>>>>>> serviceReference =
> >>>>>>>>>> bundleContext.getServiceReference(EventAdmin.class.getName());
> >>>>>>>>>>
> >>>>>>>>>> // check if service reference is valid
> >>>>>>>>>> if (serviceReference != null)
> >>>>>>>>>> {
> >>>>>>>>>> eventAdmin = (EventAdmin)
> >>>>>>>>>> bundleContext.getService(serviceReference);
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> But inside the if-loop I'm getting an error:
> >>>>>>>>>>
> >>>>>>>>>> java.lang.ClassCastException:
> >>>>>>>>>>
> >>>>>>>>>>
> org.apache.felix.eventadmin.impl.security.EventAdminSecurityDecorator
> >>>>>>>>>> cannot
> >>>>>>>>>> be cast to org.osgi.service.event.EventAdmin
> >>>>>>>>>>
> >>>>>>>>>> I'm a little bit confused now, because I thought that the Apache
> >>>>>>>>>> Felix
> >>>>>>>>>> framework is fully compatible to the OSGi specifications?!?
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>> While the Felix framework isn't yet 100% compliant, it is very
> close
> >>>>>>>>> and
> >>>>>>>>> getting closer every release.
> >>>>>>>>>
> >>>>>>>>> Isn't it
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> possible to mix equinox components (my bundle) with felix
> >>>>>>>>>> components
> >>>>>>>>>> (the
> >>>>>>>>>> eventadmin service)?
> >>>>>>>>>>
> >>>>>>>>>> Does anybody has an idea how I can solve my problem?
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>> Such a scenario should work, but you didn't provide enough
> >>>>>>>>> information
> >>>>>>>>> to
> >>>>>>>>> say why it isn't. Perhaps you could show us your bundle's
> manifest
> >>>>>>>>> file
> >>>>>>>>> as
> >>>>>>>>> well as a "jar tf" of the bundle.
> >>>>>>>>>
> >>>>>>>>> -> richard
> >>>>>>>>>
> >>>>>>>>> BR,
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Markus
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: [email protected]
> >>>>>>>>> For additional commands, e-mail: [email protected]
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >
>
>
>
> --
> Karl Pauls
> [email protected]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
