You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Colin Fleming <co...@gmail.com> on 2009/01/05 16:50:43 UTC
Re: Problem with static references for factory components in SCR
Hi all,
Can anyone comment on this? We made a fix which seems to work for us, but
I'd like to make sure this seems like a bug before filing a report.
Cheers,
Colin
2008/12/19 Colin Fleming <co...@gmail.com>
> Hi all,
>
> We're trying to migrate our application from Knopflerfish to Felix at the
> moment. It's almost working, but we've had a lot of problems with the
> following exception:
>
> INFO ERROR: EventDispatcher: Error during dispatch.
> (java.lang.IllegalStateException: Cannot get the Service Registration, owned
> by Thread[SCR Component Actor,5,main])
> WARN java.lang.IllegalStateException: Cannot get the Service Registration,
> owned by Thread[SCR Component Actor,5,main]
> WARN at
> org.apache.felix.scr.impl.AbstractComponentManager.lockServiceRegistration(AbstractComponentManager.java:782)
> WARN at
> org.apache.felix.scr.impl.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:709)
> WARN at
> org.apache.felix.scr.impl.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:549)
> WARN at
> org.apache.felix.scr.impl.AbstractComponentManager.deactivate(AbstractComponentManager.java:238)
> WARN at
> org.apache.felix.scr.impl.AbstractComponentManager.reactivate(AbstractComponentManager.java:171)
> WARN at
> org.apache.felix.scr.impl.DependencyManager.serviceAdded(DependencyManager.java:181)
> WARN at
> org.apache.felix.scr.impl.DependencyManager.serviceChanged(DependencyManager.java:115)
> WARN at
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:765)
>
> This seems to have been fixed in FELIX-550. However we're still seeing it,
> and it seems to be a problem with static references in factory components
> which have a target specified. What seems to happen is when the factory
> component is created, the DependencyManager correctly has the m_target field
> set. However, when the component is activated, the getProperties() method in
> ComponentFactoryImpl doesn't add the properties for the target attributes of
> references as ImmediateComponentManager does. Then, when setTargetFilter on
> the DependencyManager is called, its target parameter is null (because the
> property isn't correctly set) and the SCR interprets this as a change in the
> target. Since the reference is static, the component is deactivated and
> reactivated incorrectly.
>
> As far as I can tell, the incorrect part is that the reference target
> properties are not set for factory components. I can't see anything in 112.6
> of the spec which would imply this should not happen. I guess the fix would
> be to set those properties in the ComponentFactoryImpl as it's done in the
> ImmediateComponentManager?
>
> Cheers,
> Colin
>
Re: Problem with static references for factory components in SCR
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Colin,
Sorry, this was lost in my SCR radar :-(
Can you please provide your fix in a JIRA ? That would be very nice.
Thanks and Regards
Felix
Colin Fleming schrieb:
> Hi all,
>
> Can anyone comment on this? We made a fix which seems to work for us, but
> I'd like to make sure this seems like a bug before filing a report.
>
> Cheers,
> Colin
>
> 2008/12/19 Colin Fleming <co...@gmail.com>
>
>> Hi all,
>>
>> We're trying to migrate our application from Knopflerfish to Felix at the
>> moment. It's almost working, but we've had a lot of problems with the
>> following exception:
>>
>> INFO ERROR: EventDispatcher: Error during dispatch.
>> (java.lang.IllegalStateException: Cannot get the Service Registration, owned
>> by Thread[SCR Component Actor,5,main])
>> WARN java.lang.IllegalStateException: Cannot get the Service Registration,
>> owned by Thread[SCR Component Actor,5,main]
>> WARN at
>> org.apache.felix.scr.impl.AbstractComponentManager.lockServiceRegistration(AbstractComponentManager.java:782)
>> WARN at
>> org.apache.felix.scr.impl.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:709)
>> WARN at
>> org.apache.felix.scr.impl.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:549)
>> WARN at
>> org.apache.felix.scr.impl.AbstractComponentManager.deactivate(AbstractComponentManager.java:238)
>> WARN at
>> org.apache.felix.scr.impl.AbstractComponentManager.reactivate(AbstractComponentManager.java:171)
>> WARN at
>> org.apache.felix.scr.impl.DependencyManager.serviceAdded(DependencyManager.java:181)
>> WARN at
>> org.apache.felix.scr.impl.DependencyManager.serviceChanged(DependencyManager.java:115)
>> WARN at
>> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:765)
>>
>> This seems to have been fixed in FELIX-550. However we're still seeing it,
>> and it seems to be a problem with static references in factory components
>> which have a target specified. What seems to happen is when the factory
>> component is created, the DependencyManager correctly has the m_target field
>> set. However, when the component is activated, the getProperties() method in
>> ComponentFactoryImpl doesn't add the properties for the target attributes of
>> references as ImmediateComponentManager does. Then, when setTargetFilter on
>> the DependencyManager is called, its target parameter is null (because the
>> property isn't correctly set) and the SCR interprets this as a change in the
>> target. Since the reference is static, the component is deactivated and
>> reactivated incorrectly.
>>
>> As far as I can tell, the incorrect part is that the reference target
>> properties are not set for factory components. I can't see anything in 112.6
>> of the spec which would imply this should not happen. I guess the fix would
>> be to set those properties in the ComponentFactoryImpl as it's done in the
>> ImmediateComponentManager?
>>
>> Cheers,
>> Colin
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org