[
https://issues.apache.org/jira/browse/FELIX-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12703028#action_12703028
]
Felix Meschberger commented on FELIX-1053:
------------------------------------------
This is actually a regression introduced with FELIX-993: As for this issue I
removed the target filter check on removal. The consequence is that the m_size
field is decremented on each service removal, regardless of this makes any
sense or not.
Will have to investigate various options with respect to target filters:
(1) add service with matching / non-matching filter --> no issue works right
now
(2) remove service with matching / non-matching filter --> used to work before
FELIX-993
(3) change service such that the filter match changes --> used to not work
before FELIX-993, does not work correctly now.
The problem really is handling the service properties update and its influence
on the target filter matching.... Copying with service properties update
requires more work than just removing/adding the service.
> SCR: Bound Service Replacement regression ?
> -------------------------------------------
>
> Key: FELIX-1053
> URL: https://issues.apache.org/jira/browse/FELIX-1053
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
> Environment: linux/java version "1.5.0_18"
> Reporter: Pierre De Rop
> Assignee: Felix Meschberger
> Fix For: scr-1.0.8
>
> Attachments: bound-replacement.tgz
>
>
> With the SCR trunk version, it looks like the "Bound Service Replacement"
> feature does not work anymore, and
> I think it might be a regression, because it works fine with the SCR version
> 1.0.6
> I have attached to this issue a sample code which reproduces the problem. In
> the sample, there are two bundles:
> client-1.0.jar
> =========
> - contains a Client which has a dynamic/required/unary dependency over the
> "service.Service" interface, with the service property "foo=bar"
> - Here is the serviceComponent.xml description:
> <?xml version="1.0" encoding="UTF-8"?>
> <component name="Client">
> <implementation class="client.Client"/>
> <reference name="SERVICE"
> interface="service.Service"
> policy="dynamic"
> cardinality="1..1"
> target="(foo=bar)"
> bind="bind"/>
> </component>
> service-1.0.jar
> ==========
> - contains the Service interface: "service.Service"
> - contains the Service implementation: "service.impl.ServiceImpl"
> - contains a ComponentFactory ("service.impl.ServiceFactory") which is in
> charge of creating component instances of type "ServiceImpl".
> Here is the serviceComponent.xml:
> <?xml version="1.0" encoding="UTF-8"?>
> <component name="Service" factory="ServiceFactory">
> <service>
> <provide interface="service.Service"/>
> </service>
> <implementation class="service.impl.ServiceImpl"/>
> </component>
>
> <component name="ServiceFactory">
> <implementation class="service.impl.ServiceFactory"/>
> <reference name="COMPONENT_FACTORY"
> interface="org.osgi.service.component.ComponentFactory"
> target="(component.name=Service)"
> bind="bind"/>
> </component>
> The ComponentFactory does the following, in a separate thread:
> while (true) {
> 1- create a ServiceImpl component instance with property "foo=bar2"
> 2- dispose eventual previously created ServiceImpl with property
> "foo=bar2"
> 3- create a ServiceImpl component instance with property "foo=bar"
> 4- dispose eventual previously created ServiceImpl with property
> "foo=bar"
> 5- Sleep 500 seconds
> }
> The issue arises in the step 4: Indeed, when the old ServiceImpl (with
> property "foo=bar") is disposed, the Client is deactivated, but
> I think it should not, mainly because SCR should actually replace the old
> bound ServiceImpl with the new one that was created in step 3.
> When you will start the test, you will see the following logs:
> ServiceFactory: creating Service instance with property "foo=bar2" ...
> ServiceFactory: creating Service instance with property "foo=bar" ...
> ServiceFactory: Sleeping 500 ms ...
> Client: bound Service : service.impl.servicei...@1bca5f1
> Client: activated with properties={component.name=Client; component.id=4;
> SERVICE.target=(foo=bar); }
> ServiceFactory: creating Service instance with property "foo=bar2" ...
> ServiceFactory: disposing old Service instance with property "foo=bar2" ...
> ServiceFactory: creating Service instance with property "foo=bar" ...
> ServiceFactory: disposing old Service instance with property "foo=bar" ...
> Client: DEACTIVATED !
> Felix, could you please take a look at the sample code and check if my
> analysis is correct ?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
