felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clement Escoffier <clement.escoff...@gmail.com>
Subject Re: Can iPOJO inject an instance in the same bundle
Date Sat, 08 Oct 2011 11:42:53 GMT
Hi,

Issac is right, you should not assigned the service dependency to null, because it overrides
the value injected by iPOJO.

Regards,

Clement

On 07.10.2011, at 23:25, Issac Noé García wrote:

> The problem I think is with the line:
> 
> /** Reference to the dispatcher to use. */
> private EventDispatcher dispatcher = null;
> 
> As you initialize the field (even with null), there is a strange behavior
> (Clement could explain it better) that make that
> your field has always the reference to null. So if you want iPOJO to handle
> the injections, you should leave fields without assign some value.
> 
> regards
> 
> 2011/10/7 Benoît Thiébault <thiebault@artenum.com>
> 
>> Hi Clément,
>> 
>> Here is my configuration.
>> 
>> In a first bundle called "messaging", I have an EventDispatcher and a
>> default implementation that is instantiated and provided as a service by
>> iPOJO (I don't use annotations so that my classes remain POJOs):
>> 
>> <component classname="org.messaging.internal.DefaultEventDispatcher"
>>   name="DefaultEventDispatcher"
>>    public="true"
>>   immediate="true">
>>   <callback transition="invalidate" method="terminate" />
>>   <provides />
>> </component>
>> <instance component="DefaultEventDispatcher" />
>> 
>> The EventDispatcher, as its names implies, dispatches events from one
>> bundle to another. It will potentially be used in a lot of classes by a
>> lot of bundles.
>> 
>> Its usage is however not very simple and I have created, in the same
>> bundle, a helper class, called EventBuilder, to simplify the dispatching
>> of events. It is declared in iPOJO like this:
>> <component classname="org.messaging.EventBuilder"
>>   name="EventBuilder"
>>   public="true">
>>   <requires field="dispatcher" />
>> </component>
>> <instance component="EventBuilder" />
>> 
>> It is a based on the builder design pattern
>> (http://drdobbs.com/java/208403883?pgno=2) and is called statically by
>> my bundles like this:
>> EventBuilder.event(myEventKey).triggerCallEvent();
>> or
>> EventBuilder.event(myEventKey).triggerSignalEvent();
>> etc.
>> 
>> The EventBuilder class contains a reference to the dispatcher and I
>> would like this instance to be injected automatically.
>> 
>> The implementation looks like this (this is a simplified version of it):
>> 
>> public final class EventBuilder {
>>   /** Unique instance of the builder */
>>   private static final EventBuilder INSTANCE = new EventBuilder();
>>   /** Event to trigger. */
>>   private static Event eventToTrigger;
>>   /** Reference to the dispatcher to use. */
>>   private EventDispatcher dispatcher = null;
>>   /** Lock to prevent concurrent modifications. */
>>   private static final Lock LOCK = new ReentrantLock();
>> 
>> public static EventBuilder event(final EventKey key) {
>>       LOCK.lock();
>>       eventToTrigger = new DefaultEvent(key);
>>       return INSTANCE;
>> }
>> 
>> public void triggerCallEvent() {
>>       try {
>>           dispatcher.triggerCallEvent(eventToTrigger);
>>       } finally {
>>           LOCK.unlock();
>>       }
>> }
>> }
>> 
>> I have a HelloWorld bundle that just calls the Builder in its start()
>> method. The stack trace is (line 81 of the EventBuilder is the one that
>> calls dispatcher.triggerCallEvent(eventToTrigger);... apparently, the
>> injection is not done):
>> 
>> [ERROR]  : [HelloWorldBundleStarter-0] The callback method start has
>> thrown an exception : null
>> java.lang.NullPointerException
>>       at
>> org.messaging.EventBuilder.__triggerCallEvent(EventBuilder.java:81)
>>       at org.messaging.EventBuilder.triggerCallEvent(EventBuilder.java)
>>       at org.helloworld.osgi.BundleStarter.__start(BundleStarter.java:23)
>>       at org.helloworld.osgi.BundleStarter.start(BundleStarter.java)
>>       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>       at
>> 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>       at
>> 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>       at java.lang.reflect.Method.invoke(Method.java:597)
>>       at org.apache.felix.ipojo.util.Callback.call(Callback.java:237)
>>       at org.apache.felix.ipojo.util.Callback.call(Callback.java:193)
>>       at
>> 
>> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallback.call(LifecycleCallback.java:86)
>>       at
>> 
>> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.__stateChanged(LifecycleCallbackHandler.java:162)
>>       at
>> 
>> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.stateChanged(LifecycleCallbackHandler.java)
>>       at
>> org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:471)
>>       at
>> org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:353)
>>       at
>> 
>> org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:166)
>>       at
>> 
>> org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:301)
>>       at
>> 
>> org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:238)
>>       at org.apache.felix.ipojo.InstanceCreator
>> $ManagedInstance.create(InstanceCreator.java:343)
>>       at
>> org.apache.felix.ipojo.InstanceCreator.addInstance(InstanceCreator.java:89)
>>       at org.apache.felix.ipojo.Extender.parse(Extender.java:269)
>>       at
>> org.apache.felix.ipojo.Extender.startManagementFor(Extender.java:208)
>>       at org.apache.felix.ipojo.Extender.access$600(Extender.java:52)
>>       at
>> org.apache.felix.ipojo.Extender$CreatorThread.run(Extender.java:682)
>>       at java.lang.Thread.run(Thread.java:662)
>> [ERROR]  : null
>> java.lang.IllegalStateException
>>       at
>> 
>> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.__stateChanged(LifecycleCallbackHandler.java:171)
>>       at
>> 
>> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.stateChanged(LifecycleCallbackHandler.java)
>>       at
>> org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:471)
>>       at
>> org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:353)
>>       at
>> 
>> org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:166)
>>       at
>> 
>> org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:301)
>>       at
>> 
>> org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:238)
>>       at org.apache.felix.ipojo.InstanceCreator
>> $ManagedInstance.create(InstanceCreator.java:343)
>>       at
>> org.apache.felix.ipojo.InstanceCreator.addInstance(InstanceCreator.java:89)
>>       at org.apache.felix.ipojo.Extender.parse(Extender.java:269)
>>       at
>> org.apache.felix.ipojo.Extender.startManagementFor(Extender.java:208)
>>       at org.apache.felix.ipojo.Extender.access$600(Extender.java:52)
>>       at
>> org.apache.felix.ipojo.Extender$CreatorThread.run(Extender.java:682)
>>       at java.lang.Thread.run(Thread.java:662)
>> 
>> 
>> Le mardi 04 octobre 2011 à 16:36 +0200, Clement Escoffier a écrit :
>>> Hi,
>>> 
>>> This scenario is supported out of the box.
>>> 
>>> Let's imagine a simple component A:
>>> @Component(name="comp-a")
>>> @Provides
>>> class Component1
>>> {
>>>  @Validate
>>>  public void init() {
>>>      System.out.println("Ping from " + getClass());
>>>  }
>>> 
>>>  public boolean doSomething() {
>>>      System.out.println("I'm doing something cool");
>>>      return true;
>>>  }
>>> }
>>> 
>>> Let's also imagine a simple component B (in the same bundle):
>>> @Component(name="comp-b")
>>> class Component2
>>> {
>>>   @Requires
>>>   private Component1 cmp;
>>> 
>>> 
>>>  @Validate
>>>  public void init() {
>>>      System.out.println("Ping from " + getClass());
>>>      System.out.println(cmp.doSomething());
>>>  }
>>> }
>>> 
>>> And now, the metadata.xml declaring the instances:
>>> <ipojo xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xsi:schemaLocation="org.apache.felix.ipojo
>> http://felix.apache.org/ipojo/schemas/CURRENT/core.xsd"
>>> xmlns="org.apache.felix.ipojo"
>> xmlns:c="org.apache.felix.ipojo.composite">
>>> 
>>>    <instance component="comp-a" />
>>>    <instance component="comp-b" />
>>> 
>>> </ipojo>
>>> 
>>> If you deploy this bundle, you will see:
>>> Ping from class
>> ipojo.test.org.apache.felix.ipojo.instance.injection.Component1
>>> Ping from class
>> ipojo.test.org.apache.felix.ipojo.instance.injection.Component2
>>> I'm doing something cool
>>> true
>>> 
>>> So, nothing else should be required. Could you give me more details about
>> your case as well as the stack trace.
>>> 
>>> Regards,
>>> 
>>> Clement
>>> 
>>> On 04.10.2011, at 09:57, Benoît Thiébault wrote:
>>> 
>>>> Hi everyone,
>>>> 
>>>> I'm using iPOJO in my application and I would like to inject a service
>>>> instance in another class of the same bundle.
>>>> 
>>>> Something like this:
>>>> <iPOJO xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>    xmlns="org.apache.felix.ipojo"
>>>>    xsi:schemaLocation="org.apache.felix.ipojo
>>>> http://felix.apache.org/ipojo/schemas/CURRENT/core.xsd">
>>>>    <component classname="org.test.ServiceImpl"
>>>>            name="ServiceImpl" public="true" immediate="true">
>>>>            <callback transition="invalidate" method="terminate" />
>>>>            <provides />
>>>>    </component>
>>>>    <instance component="ServiceImpl" />
>>>>    <component classname="org.test.User"
>>>>            name="User" public="true">
>>>>            <requires field="serviceInstance"/>
>>>>    </component>
>>>>    <instance component="User" />
>>>> </iPOJO>
>>>> 
>>>> Is is supported by iPOJO? Is there a special way to do it?
>>>> 
>>>> I tried it and have a null pointer exception on the instance...
>>>> 
>>>> Kind regards
>>>> 
>>>> Ben
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> 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
>> 
>> 
> 
> 
> -- 
> Issac Noé García Garza


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message