|

»

Apache Felix - Dev

[jira] Created: (FELIX-862) Services not unregistered on component deactivation

View: New views

5 Messages — Rating Filter: Alert me

	[jira] Created: (FELIX-862) Services not unregistered on component deactivation by JIRA jira@apache.org :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Services not unregistered on component deactivation --------------------------------------------------- Key: FELIX-862 URL: https://issues.apache.org/jira/browse/FELIX-862 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Environment: Felix 1.4.0, SCR 1.0.6 Reporter: Alin Dreghiciu Situation (is about Pax Shell using SCR): Bundle 1: <component name='org.ops4j.pax.shell.threadio.internal.ThreadIOImpl'> <implementation class='org.ops4j.pax.shell.threadio.internal.ThreadIOImpl'/> <service> <provide interface='org.osgi.service.threadio.ThreadIO'/> </service> </component> Bundle 2: <component name='org.ops4j.pax.shell.runtime.internal.CommandProcessorImpl'> <implementation class='org.ops4j.pax.shell.runtime.internal.CommandProcessorImpl'/> <service> <provide interface='org.osgi.service.command.CommandProcessor'/> </service> <reference name='threadIO' interface='org.osgi.service.threadio.ThreadIO' bind='setThreadIO' unbind='unsetThreadIO'/> If both bundles are started bundle 2 exports a CommandProcessor service. This is correct. If I stop bundle 1, I expect that bundle 2 would unregister the CommandProcessor service. But this is not the case, as service is still exported If after the bundle 1 was stopped I stop the bundle 2 and start bundle 2 again, the service CommandProcessor is indeed not exported (as bundle 1 is not started so there is no ThreadIO service). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
	[jira] Commented: (FELIX-862) Services not unregistered on component deactivation by JIRA jira@apache.org :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message [ https://issues.apache.org/jira/browse/FELIX-862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12658728#action_12658728 ] Alin Dreghiciu commented on FELIX-862: -------------------------------------- This may be related to the NPE from FELIX-861. > Services not unregistered on component deactivation > --------------------------------------------------- > > Key: FELIX-862 > URL: https://issues.apache.org/jira/browse/FELIX-862 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) > Environment: Felix 1.4.0, SCR 1.0.6 > Reporter: Alin Dreghiciu > > Situation (is about Pax Shell using SCR): > Bundle 1: > <component name='org.ops4j.pax.shell.threadio.internal.ThreadIOImpl'> > <implementation class='org.ops4j.pax.shell.threadio.internal.ThreadIOImpl'/> > <service> > <provide interface='org.osgi.service.threadio.ThreadIO'/> > </service> > </component> > Bundle 2: > <component name='org.ops4j.pax.shell.runtime.internal.CommandProcessorImpl'> > <implementation class='org.ops4j.pax.shell.runtime.internal.CommandProcessorImpl'/> > <service> > <provide interface='org.osgi.service.command.CommandProcessor'/> > </service> > <reference name='threadIO' interface='org.osgi.service.threadio.ThreadIO' bind='setThreadIO' unbind='unsetThreadIO'/> > If both bundles are started bundle 2 exports a CommandProcessor service. This is correct. > If I stop bundle 1, I expect that bundle 2 would unregister the CommandProcessor service. But this is not the case, as service is still exported > If after the bundle 1 was stopped I stop the bundle 2 and start bundle 2 again, the service CommandProcessor is indeed not exported (as bundle 1 is not started so there is no ThreadIO service). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
	[jira] Commented: (FELIX-862) Services not unregistered on component deactivation by JIRA jira@apache.org :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message [ https://issues.apache.org/jira/browse/FELIX-862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12658816#action_12658816 ] Felix Meschberger commented on FELIX-862: ----------------------------------------- Yes, this may be related, since the component is probably not properly stopped due to the uncaught NullPointerException. Could you try with the patch I posted to FELIX-861, whether it works ? Thanks. > Services not unregistered on component deactivation > --------------------------------------------------- > > Key: FELIX-862 > URL: https://issues.apache.org/jira/browse/FELIX-862 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) > Environment: Felix 1.4.0, SCR 1.0.6 > Reporter: Alin Dreghiciu > > Situation (is about Pax Shell using SCR): > Bundle 1: > <component name='org.ops4j.pax.shell.threadio.internal.ThreadIOImpl'> > <implementation class='org.ops4j.pax.shell.threadio.internal.ThreadIOImpl'/> > <service> > <provide interface='org.osgi.service.threadio.ThreadIO'/> > </service> > </component> > Bundle 2: > <component name='org.ops4j.pax.shell.runtime.internal.CommandProcessorImpl'> > <implementation class='org.ops4j.pax.shell.runtime.internal.CommandProcessorImpl'/> > <service> > <provide interface='org.osgi.service.command.CommandProcessor'/> > </service> > <reference name='threadIO' interface='org.osgi.service.threadio.ThreadIO' bind='setThreadIO' unbind='unsetThreadIO'/> > If both bundles are started bundle 2 exports a CommandProcessor service. This is correct. > If I stop bundle 1, I expect that bundle 2 would unregister the CommandProcessor service. But this is not the case, as service is still exported > If after the bundle 1 was stopped I stop the bundle 2 and start bundle 2 again, the service CommandProcessor is indeed not exported (as bundle 1 is not started so there is no ThreadIO service). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
	[jira] Commented: (FELIX-862) Services not unregistered on component deactivation by JIRA jira@apache.org :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message [ https://issues.apache.org/jira/browse/FELIX-862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12658971#action_12658971 ] Alin Dreghiciu commented on FELIX-862: -------------------------------------- The problem is not solved by applying the patch that solved FELIX-861. Even if the exception is gone the service does not get unregistered, so, the situation is as before. > Services not unregistered on component deactivation > --------------------------------------------------- > > Key: FELIX-862 > URL: https://issues.apache.org/jira/browse/FELIX-862 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) > Environment: Felix 1.4.0, SCR 1.0.6 > Reporter: Alin Dreghiciu > > Situation (is about Pax Shell using SCR): > Bundle 1: > <component name='org.ops4j.pax.shell.threadio.internal.ThreadIOImpl'> > <implementation class='org.ops4j.pax.shell.threadio.internal.ThreadIOImpl'/> > <service> > <provide interface='org.osgi.service.threadio.ThreadIO'/> > </service> > </component> > Bundle 2: > <component name='org.ops4j.pax.shell.runtime.internal.CommandProcessorImpl'> > <implementation class='org.ops4j.pax.shell.runtime.internal.CommandProcessorImpl'/> > <service> > <provide interface='org.osgi.service.command.CommandProcessor'/> > </service> > <reference name='threadIO' interface='org.osgi.service.threadio.ThreadIO' bind='setThreadIO' unbind='unsetThreadIO'/> > If both bundles are started bundle 2 exports a CommandProcessor service. This is correct. > If I stop bundle 1, I expect that bundle 2 would unregister the CommandProcessor service. But this is not the case, as service is still exported > If after the bundle 1 was stopped I stop the bundle 2 and start bundle 2 again, the service CommandProcessor is indeed not exported (as bundle 1 is not started so there is no ThreadIO service). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
	[jira] Resolved: (FELIX-862) Services not unregistered on component deactivation by JIRA jira@apache.org :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message [ https://issues.apache.org/jira/browse/FELIX-862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alin Dreghiciu resolved FELIX-862. ---------------------------------- Resolution: Fixed I retested and seems like the problem is gone. > Services not unregistered on component deactivation > --------------------------------------------------- > > Key: FELIX-862 > URL: https://issues.apache.org/jira/browse/FELIX-862 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) > Environment: Felix 1.4.0, SCR 1.0.6 > Reporter: Alin Dreghiciu > > Situation (is about Pax Shell using SCR): > Bundle 1: > <component name='org.ops4j.pax.shell.threadio.internal.ThreadIOImpl'> > <implementation class='org.ops4j.pax.shell.threadio.internal.ThreadIOImpl'/> > <service> > <provide interface='org.osgi.service.threadio.ThreadIO'/> > </service> > </component> > Bundle 2: > <component name='org.ops4j.pax.shell.runtime.internal.CommandProcessorImpl'> > <implementation class='org.ops4j.pax.shell.runtime.internal.CommandProcessorImpl'/> > <service> > <provide interface='org.osgi.service.command.CommandProcessor'/> > </service> > <reference name='threadIO' interface='org.osgi.service.threadio.ThreadIO' bind='setThreadIO' unbind='unsetThreadIO'/> > If both bundles are started bundle 2 exports a CommandProcessor service. This is correct. > If I stop bundle 1, I expect that bundle 2 would unregister the CommandProcessor service. But this is not the case, as service is still exported > If after the bundle 1 was stopped I stop the bundle 2 and start bundle 2 again, the service CommandProcessor is indeed not exported (as bundle 1 is not started so there is no ThreadIO service). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.