Hi, I've opened https://issues.apache.org/jira/browse/FELIX-4217 to reproduce and track the problem.
Regards, Clement On 3 sept. 2013, at 12:59, Bengt Rodehav <[email protected]> wrote: > Thanks for the tip but I have checked that already. The package containing > the interface is imported. It is the exact same import that the ones that > work use. > > Also, just by replacing Blueprint with iPOJO for my new provider it started > to work - nothing else changed. > > I wonder if there is an inherent problem in the situation where you use > iPOJO's @Require with an array and the required services are published with > Blueprint. Have you tested that combination? > > /Bengt > > > 2013/9/3 Guillaume Sauthier (OW2/GMail) <[email protected]> > >> Can you also check import/exports of your new bundle ? >> Imagine that the INotificationProvider package is not imported (thus not >> shared between ipojo and blueprint components) ... >> That could explain theses kind of issue where everything looks fine. >> >> --G >> >> >> 2013/9/3 Bengt Rodehav <[email protected]> >> >>> Hello Clement, >>> >>> I have already checked that the service is published - it looks OK. I >> have >>> also put some logging in its constructor to verify that an object is >>> instantiated. >>> >>> Here is the contents of the architecture field in the iPOJO tab in the >> web >>> console: >>> >>> *instance name="seco.notification.service-0" state="valid" bundle="86" >>> component.type="seco.notification.service" >>> handler name="org.apache.felix.ipojo:requires" state="valid" >>> requires >>> specification="se.digia.seco.notification.spi.INotificationProvider" >>> id="se.digia.seco.notification.spi.INotificationProvider" >>> optional="false" aggregate="true" proxy="false" >>> binding-policy="dynamic" state="resolved" >>> handler name="org.apache.felix.ipojo:properties" state="valid" >>> managed.service.pid="seco.notification.service" >>> property name="allowZeroProviders" value="false" >>> handler name="org.apache.felix.ipojo:provides" state="valid" >>> provides >>> specifications="[se.digia.seco.notification.api.INotificationService]" >>> state="registered" service.id="358" >>> property name="component" >>> value="se.digia.seco.notification.service.NotificationService" >>> property name="factory.name" >>> value="seco.notification.service" >>> property name="instance.name" >>> value="seco.notification.service-0" >>> handler name="org.apache.felix.ipojo:architecture" state="valid"* >>> >>> >>> >>> If I redesign my new provider to use iPOJO instead of Blueprint it >>> works. I just add these two lines to my provider: >>> >>> >>> *@Provides(specifications = INotificationProvider.class) >>> @Instantiate* >>> >>> >>> Of course this is a workaround for me but I would really like to know >>> why I can't get this to work using Blueprint. I would like to have >>> both possibilities in the future. >>> >>> >>> /Bengt >>> >>> >>> >>> 2013/9/3 Clement Escoffier <[email protected]> >>> >>>> Hi, >>>> >>>> It should not matter if the service is in the service registry. >>>> >>>> Can you check that the new service is published in the service >> registry, >>>> with the web console or the `inspect` gogo command ? >>>> Can you also give me the architecture of the iPOJO instance. >>>> >>>> On Gogo: >>>> ipojo:instance name-of-the-instance >>>> >>>> Or with the web console iPOJO plugin ( >>>> >>> >> http://repo1.maven.org/maven2/org/apache/felix/org.apache.felix.ipojo.webconsole/1.7.0/org.apache.felix.ipojo.webconsole-1.7.0.jar >>>> ). >>>> >>>> Regards, >>>> >>>> Clement >>>> >>>> On 3 sept. 2013, at 07:46, Bengt Rodehav <[email protected]> wrote: >>>> >>>>> I'm using iPOJO 1.8.6 in Karaf 2.3.1 on Felix. >>>>> >>>>> I have an existing mechanism for notifications using iPOJO. Basically >>> my >>>>> notification service (that uses iPOJO) uses all registered notifier >>>>> providers as follows: >>>>> >>>>> * @Requires(optional = false, nullable = false)* >>>>> * private INotificationProvider[] mProviders;* >>>>> >>>>> Whenever I need to create a notification, it will be handled by all >>>>> registered notifier. E g I have a notification provider that logs the >>>>> problem in a log file and another that publishes the notification in >>>>> Windows event log. So far I have published my notification providers >>>> using >>>>> iPOJO as well (the notification service also uses iPOJO). >>>>> >>>>> I now have a notification provider that publishes its service using >>> Aries >>>>> Blueprint, as follows: >>>>> >>>>> *<?xml version="1.0" encoding="UTF-8"?>* >>>>> *<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"; >>>> xmlns:xsi=" >>>>> http://www.w3.org/2001/XMLSchema-instance"* >>>>> * xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0"; >>>>> xmlns:cm=" >> http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0 >>> "* >>>>> * default-activation="eager">* >>>>> * >>>>> * >>>>> * <bean id="notifierService" class="myPackage1.MyNotifierService" >> />* >>>>> * >>>>> * >>>>> * <service ref="notifierService" >>>>> interface="myPackage2.INotificationProvider"/>* >>>>> *</blueprint>* >>>>> >>>>> I've replaced my true package names above but "myPackage2" is the >>> package >>>>> where the INotificationProvider interface resides. >>>>> >>>>> For some reason my notification service does not pick up the service >>>>> published via Blueprint which means that my new notification provider >>> is >>>>> being skipped. >>>>> >>>>> I thought for a while that it is the default "lazy" activation >> strategy >>>>> that plays tricks on me which is why I use "eager" instead but it >>> doesn't >>>>> help. >>>>> >>>>> I thought it shouldn't matter in what way I publish an OSGi service, >>>> iPOJO >>>>> should still pick it up. Does anyone know what I could be doing >> wrong? >>>>> >>>>> /Bengt >>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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]
