You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Jon Barber <jo...@acm.org> on 2013/05/13 17:03:10 UTC
DOSGi service still available after being unregistered
Hi,
I have a simple OSGi service I've exposed via CXF DOSGi 1.4.0 using
Karaf 2.2.11 - it's pretty much a straight copy from the discovery
sample from the 1.4.0 release of cxf-dosgi. The service is exposed by
the bundle activator as follows :
private ServiceRegistration reg;
public void start(BundleContext bc) throws Exception {
Dictionary<String, Object> props = new Hashtable<String,
Object>();
String host = getHostName();
int port = getPort();
String address = getAddress(host,port);
LOG.info("Registering ws address {}",address);
props.put("service.exported.interfaces", "*");
props.put("service.exported.configs", "org.apache.cxf.ws");
props.put("org.apache.cxf.ws.address", address); // old obsolete
value
props.put("endpoint.id", address);
reg = bc.registerService(PingService.class.getName(),
new SimplePingService(), props);
}
public void stop(BundleContext bc) throws Exception {
LOG.info("Unregistering ping service");
reg.unregister();
}
And sure enough it gets registered as a SOAP service and I can see it in
zookeeper too. However, when I stop the bundle the service is indeed
removed in the local OSGi registry but I can still access the SOAP
endpoint, and it's still visible in zookeeper too. Furthermore, if I
re-activate the bundle the service is now available on the old endpoint
and the new one.
So either my understanding is wrong (I would have thought unregistering
the service would remove the SOAP service too) or there's a bug in
DOSGi, or I'm missing something / doing something wrong.
Could someone give some guidance please ?
Thanks,
Jon.
Re: DOSGi service still available after being unregistered
Posted by Christian Schneider <ch...@die-schneider.net>.
If you do not have the standard port then you need to change the
cxf-dsw.cfg.
There are two relevant attributes:
cxfServletAlias default: /cxf
httpBase default: http://<host name>:8181
So using the httpBase you can make sure two containers on the same
server can work together.
Christian
On 14.05.2013 12:51, Jon Barber wrote:
> Hi Christian,
>
> Many thanks for looking at this.
>
> I should have made it clearer in the README - I started zookeeper
> externally, but your method makes it even easier to reproduce.
>
> I explicitly set the port & server to get around an issue when I had 2
> Karaf containers running - at least one would not use the default 8181
> port and CXF seemed to default to this, leading to the service not being
> registered (or at least that seemed to be the case). If I can omit that
> line even better.
>
> Jon.
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: DOSGi service still available after being unregistered
Posted by Jon Barber <jo...@acm.org>.
Hi,
I'm still seeing the behaviour where the zookeeper node isn't deleted,
and after several hours debugging I think I can see why. This is against
the current trunk of the DOSGi code.
When I stop the bundle I see that the ServiceTracker declared at
org.apache.cxf.dosgi.dsw.service/ExportRegistrationImpl line 178 is
invoked - in fact it's the removedService() method of that. This in turn
calls close() on the ExportReferenceImpl, which simply sets the
endpointDescription and serviceReference fields to null.
Some time after this then the ServiceListener declared at line 96 of
org.apache.cxf.dosgi.topologymanager.exporter.TopologyManagerExport
gets called. This in turn works out what EndpointListeners to notify
that the endpoint has been removed ( the method notifyListenersOfRemoval
at line 126 in
org.apache.cxf.dosgi.topologymanager.exporter.EndpointListenerNotifier )
- and it's one of these
(org.apache.cxf.dosgi.discovery.zookeeper.PublishingEndpointListener)
which deleted the zookeeper node.
However, the logic in notifyListenersOfRemoval uses the
endpointDescription to work out which listeners to notify - and at this
point it's set to null, so none at all are selected, meaning that the
zookeeper node isn't deleted.
So it looks like this may be a race condition - is there any reason why
the correct sequence (ServiceListeners called before ServiceTracker ?)
should happen which would mean the the node is deleted ?
I've placed the logging config I used at
https://gist.github.com/sneakybeaky/5579559. If you use that and stop
the bundle with the service you can see the sequence happening in that
order :
Jon.
On Tue, May 14, 2013, at 01:25 PM, Christian Schneider wrote:
> The zookeeper node of the service should be deleted.
>
> I just tested this on my system.
>
> When I start the service then the following node is created:
> /osgi/service_registry/com/ninedemons/spikes/dosgi/shared/PingService/192.168.7.2#8181##cxf#display
>
> When I stop the service the node is deleted. The parent node is still
> there but that should be no problem.
> /osgi/service_registry/com/ninedemons/spikes/dosgi/shared/PingService
>
> Christian
>
> On 14.05.2013 13:59, Jon Barber wrote:
> > Hi,
> >
> > So I used CXF DOSGi current snapshot from trunk, and that sort of fixes
> > the issue in that the service is removed when the bundle is stopped, but
> > the entry in zookeeper remains, meaning consuming services still try and
> > use it.
> >
> > Is this a bug, or my misunderstanding of what should happen ?
> >
> > Thanks,
> >
> > Jon.
> >
> > On Tue, May 14, 2013, at 11:51 AM, Jon Barber wrote:
> >> Hi Christian,
> >>
> >> Many thanks for looking at this.
> >>
> >> I should have made it clearer in the README - I started zookeeper
> >> externally, but your method makes it even easier to reproduce.
> >>
> >> I explicitly set the port & server to get around an issue when I had 2
> >> Karaf containers running - at least one would not use the default 8181
> >> port and CXF seemed to default to this, leading to the service not being
> >> registered (or at least that seemed to be the case). If I can omit that
> >> line even better.
> >>
> >> Jon.
> >>
> >> On Tue, May 14, 2013, at 10:57 AM, Christian Schneider wrote:
> >>> Hi Jon,
> >>>
> >>> I was not able to run your example as is.
> >>> The first problem was that zookeeper was missing. So I needed to run:
> >>> features:install cxf-dosgi-zookeeper-server
> >>> cxf-dosgi-discovery-distributed
> >>>
> >>> Then it tried to come up but I got the message that a jetty was already
> >>> started on this port. So this may point to another bug.
> >>>
> >>> I simplified your example a but by doing:
> >>>
> >>> props.put("service.exported.interfaces", "*");
> >>> props.put("service.exported.configs", "org.apache.cxf.ws");
> >>> props.put("org.apache.cxf.ws.address", "/display"); // old
> >>> obsolete value
> >>> // props.put("endpoint.id", address);
> >>>
> >>> So I simply used an address without server and port. This signals dosgi
> >>> to use the servlet transport. So it uses the default port 8181 and the
> >>> default cxf servlet alias of "cxf". The full address then looks like
> >>> this: http://192.168.7.2:8181/cxf/display
> >>>
> >>> Is there a special reason why you explicitly specify a port and a server
> >>> name? I think using the servlet transport is much easier and allows to
> >>> centrally manage the port at one place.
> >>>
> >>> So this allowed me to get the service published. I then tried to stop
> >>> the bundle. The service was still available like you reported.
> >>> I will track the issue in:
> >>> https://issues.apache.org/jira/browse/DOSGI-180
> >>>
> >>> As a next step I will test with the current snapshot and try to debug
> >>> where the problem is originated.
> >>>
> >>> Christian
> >>>
> >>>
> >>> On 14.05.2013 10:11, Jon Barber wrote:
> >>>> Hi Christian,
> >>>>
> >>>> The code I'm using is available at
> >>>> https://github.com/sneakybeaky/DOSGi-Spike and I've added details to the
> >>>> README about how to recreate.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Jon.
> >>>>
> >>>> On Mon, May 13, 2013, at 11:48 PM, Christian Schneider wrote:
> >>>>> I think the patch will not work for your problem as you only register
> >>>>> the service once.
> >>>>>
> >>>>> I will try to recreate the problem on my system.
> >>>>>
> >>>>> Christian
> >>>>>
> >>>>> Am 13.05.2013 21:36, schrieb Jon Barber:
> >>>>>> Hi,
> >>>>>>
> >>>>>> I applied that patch, built as 1.5.0-SNAPSHOT and loaded into a running
> >>>>>> Karaf instance. Same issue - this doesn't seem to fix the problem.
> >>>>>>
> >>>>>> Jon.
> >>>>>>
> >>>>>> On Mon, May 13, 2013, at 04:36 PM, Sergey Beryozkin wrote:
> >>>>>>> Hi
> >>>>>>>
> >>>>>>> Please watch the following JIRA:
> >>>>>>>
> >>>>>>> https://issues.apache.org/jira/browse/DOSGI-177
> >>>>>>>
> >>>>>>> it even has a patch attached, so will be fixed for DOSGi 1.5
> >>>>>>>
> >>>>>>> Sergey
> >>>>>>> On 13/05/13 16:03, Jon Barber wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> I have a simple OSGi service I've exposed via CXF DOSGi 1.4.0 using
> >>>>>>>> Karaf 2.2.11 - it's pretty much a straight copy from the discovery
> >>>>>>>> sample from the 1.4.0 release of cxf-dosgi. The service is exposed by
> >>>>>>>> the bundle activator as follows :
> >>>>>>>>
> >>>>>>>> private ServiceRegistration reg;
> >>>>>>>>
> >>>>>>>> public void start(BundleContext bc) throws Exception {
> >>>>>>>> Dictionary<String, Object> props = new Hashtable<String,
> >>>>>>>> Object>();
> >>>>>>>>
> >>>>>>>> String host = getHostName();
> >>>>>>>> int port = getPort();
> >>>>>>>>
> >>>>>>>> String address = getAddress(host,port);
> >>>>>>>> LOG.info("Registering ws address {}",address);
> >>>>>>>>
> >>>>>>>> props.put("service.exported.interfaces", "*");
> >>>>>>>> props.put("service.exported.configs", "org.apache.cxf.ws");
> >>>>>>>> props.put("org.apache.cxf.ws.address", address); // old obsolete
> >>>>>>>> value
> >>>>>>>> props.put("endpoint.id", address);
> >>>>>>>>
> >>>>>>>> reg = bc.registerService(PingService.class.getName(),
> >>>>>>>> new SimplePingService(), props);
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> public void stop(BundleContext bc) throws Exception {
> >>>>>>>> LOG.info("Unregistering ping service");
> >>>>>>>>
> >>>>>>>> reg.unregister();
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> And sure enough it gets registered as a SOAP service and I can see it in
> >>>>>>>> zookeeper too. However, when I stop the bundle the service is indeed
> >>>>>>>> removed in the local OSGi registry but I can still access the SOAP
> >>>>>>>> endpoint, and it's still visible in zookeeper too. Furthermore, if I
> >>>>>>>> re-activate the bundle the service is now available on the old endpoint
> >>>>>>>> and the new one.
> >>>>>>>>
> >>>>>>>> So either my understanding is wrong (I would have thought unregistering
> >>>>>>>> the service would remove the SOAP service too) or there's a bug in
> >>>>>>>> DOSGi, or I'm missing something / doing something wrong.
> >>>>>>>>
> >>>>>>>> Could someone give some guidance please ?
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> Jon.
> >>>>>>> --
> >>>>>>> Sergey Beryozkin
> >>>>>>>
> >>>>>>> Talend Community Coders
> >>>>>>> http://coders.talend.com/
> >>>>>>>
> >>>>>>> Blog: http://sberyozkin.blogspot.com
> >>>>> --
> >>>>>
> >>>>> Christian Schneider
> >>>>> http://www.liquid-reality.de
> >>>>>
> >>>>> Open Source Architect
> >>>>> Talend Application Integration Division http://www.talend.com
> >>>>>
> >>>
> >>> --
> >>> Christian Schneider
> >>> http://www.liquid-reality.de
> >>>
> >>> Open Source Architect
> >>> http://www.talend.com
> >>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
Re: DOSGi service still available after being unregistered
Posted by Christian Schneider <ch...@die-schneider.net>.
The zookeeper node of the service should be deleted.
I just tested this on my system.
When I start the service then the following node is created:
/osgi/service_registry/com/ninedemons/spikes/dosgi/shared/PingService/192.168.7.2#8181##cxf#display
When I stop the service the node is deleted. The parent node is still
there but that should be no problem.
/osgi/service_registry/com/ninedemons/spikes/dosgi/shared/PingService
Christian
On 14.05.2013 13:59, Jon Barber wrote:
> Hi,
>
> So I used CXF DOSGi current snapshot from trunk, and that sort of fixes
> the issue in that the service is removed when the bundle is stopped, but
> the entry in zookeeper remains, meaning consuming services still try and
> use it.
>
> Is this a bug, or my misunderstanding of what should happen ?
>
> Thanks,
>
> Jon.
>
> On Tue, May 14, 2013, at 11:51 AM, Jon Barber wrote:
>> Hi Christian,
>>
>> Many thanks for looking at this.
>>
>> I should have made it clearer in the README - I started zookeeper
>> externally, but your method makes it even easier to reproduce.
>>
>> I explicitly set the port & server to get around an issue when I had 2
>> Karaf containers running - at least one would not use the default 8181
>> port and CXF seemed to default to this, leading to the service not being
>> registered (or at least that seemed to be the case). If I can omit that
>> line even better.
>>
>> Jon.
>>
>> On Tue, May 14, 2013, at 10:57 AM, Christian Schneider wrote:
>>> Hi Jon,
>>>
>>> I was not able to run your example as is.
>>> The first problem was that zookeeper was missing. So I needed to run:
>>> features:install cxf-dosgi-zookeeper-server
>>> cxf-dosgi-discovery-distributed
>>>
>>> Then it tried to come up but I got the message that a jetty was already
>>> started on this port. So this may point to another bug.
>>>
>>> I simplified your example a but by doing:
>>>
>>> props.put("service.exported.interfaces", "*");
>>> props.put("service.exported.configs", "org.apache.cxf.ws");
>>> props.put("org.apache.cxf.ws.address", "/display"); // old
>>> obsolete value
>>> // props.put("endpoint.id", address);
>>>
>>> So I simply used an address without server and port. This signals dosgi
>>> to use the servlet transport. So it uses the default port 8181 and the
>>> default cxf servlet alias of "cxf". The full address then looks like
>>> this: http://192.168.7.2:8181/cxf/display
>>>
>>> Is there a special reason why you explicitly specify a port and a server
>>> name? I think using the servlet transport is much easier and allows to
>>> centrally manage the port at one place.
>>>
>>> So this allowed me to get the service published. I then tried to stop
>>> the bundle. The service was still available like you reported.
>>> I will track the issue in:
>>> https://issues.apache.org/jira/browse/DOSGI-180
>>>
>>> As a next step I will test with the current snapshot and try to debug
>>> where the problem is originated.
>>>
>>> Christian
>>>
>>>
>>> On 14.05.2013 10:11, Jon Barber wrote:
>>>> Hi Christian,
>>>>
>>>> The code I'm using is available at
>>>> https://github.com/sneakybeaky/DOSGi-Spike and I've added details to the
>>>> README about how to recreate.
>>>>
>>>> Thanks,
>>>>
>>>> Jon.
>>>>
>>>> On Mon, May 13, 2013, at 11:48 PM, Christian Schneider wrote:
>>>>> I think the patch will not work for your problem as you only register
>>>>> the service once.
>>>>>
>>>>> I will try to recreate the problem on my system.
>>>>>
>>>>> Christian
>>>>>
>>>>> Am 13.05.2013 21:36, schrieb Jon Barber:
>>>>>> Hi,
>>>>>>
>>>>>> I applied that patch, built as 1.5.0-SNAPSHOT and loaded into a running
>>>>>> Karaf instance. Same issue - this doesn't seem to fix the problem.
>>>>>>
>>>>>> Jon.
>>>>>>
>>>>>> On Mon, May 13, 2013, at 04:36 PM, Sergey Beryozkin wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> Please watch the following JIRA:
>>>>>>>
>>>>>>> https://issues.apache.org/jira/browse/DOSGI-177
>>>>>>>
>>>>>>> it even has a patch attached, so will be fixed for DOSGi 1.5
>>>>>>>
>>>>>>> Sergey
>>>>>>> On 13/05/13 16:03, Jon Barber wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I have a simple OSGi service I've exposed via CXF DOSGi 1.4.0 using
>>>>>>>> Karaf 2.2.11 - it's pretty much a straight copy from the discovery
>>>>>>>> sample from the 1.4.0 release of cxf-dosgi. The service is exposed by
>>>>>>>> the bundle activator as follows :
>>>>>>>>
>>>>>>>> private ServiceRegistration reg;
>>>>>>>>
>>>>>>>> public void start(BundleContext bc) throws Exception {
>>>>>>>> Dictionary<String, Object> props = new Hashtable<String,
>>>>>>>> Object>();
>>>>>>>>
>>>>>>>> String host = getHostName();
>>>>>>>> int port = getPort();
>>>>>>>>
>>>>>>>> String address = getAddress(host,port);
>>>>>>>> LOG.info("Registering ws address {}",address);
>>>>>>>>
>>>>>>>> props.put("service.exported.interfaces", "*");
>>>>>>>> props.put("service.exported.configs", "org.apache.cxf.ws");
>>>>>>>> props.put("org.apache.cxf.ws.address", address); // old obsolete
>>>>>>>> value
>>>>>>>> props.put("endpoint.id", address);
>>>>>>>>
>>>>>>>> reg = bc.registerService(PingService.class.getName(),
>>>>>>>> new SimplePingService(), props);
>>>>>>>> }
>>>>>>>>
>>>>>>>> public void stop(BundleContext bc) throws Exception {
>>>>>>>> LOG.info("Unregistering ping service");
>>>>>>>>
>>>>>>>> reg.unregister();
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> And sure enough it gets registered as a SOAP service and I can see it in
>>>>>>>> zookeeper too. However, when I stop the bundle the service is indeed
>>>>>>>> removed in the local OSGi registry but I can still access the SOAP
>>>>>>>> endpoint, and it's still visible in zookeeper too. Furthermore, if I
>>>>>>>> re-activate the bundle the service is now available on the old endpoint
>>>>>>>> and the new one.
>>>>>>>>
>>>>>>>> So either my understanding is wrong (I would have thought unregistering
>>>>>>>> the service would remove the SOAP service too) or there's a bug in
>>>>>>>> DOSGi, or I'm missing something / doing something wrong.
>>>>>>>>
>>>>>>>> Could someone give some guidance please ?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Jon.
>>>>>>> --
>>>>>>> Sergey Beryozkin
>>>>>>>
>>>>>>> Talend Community Coders
>>>>>>> http://coders.talend.com/
>>>>>>>
>>>>>>> Blog: http://sberyozkin.blogspot.com
>>>>> --
>>>>>
>>>>> Christian Schneider
>>>>> http://www.liquid-reality.de
>>>>>
>>>>> Open Source Architect
>>>>> Talend Application Integration Division http://www.talend.com
>>>>>
>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: DOSGi service still available after being unregistered
Posted by Jon Barber <jo...@acm.org>.
Hi,
So I used CXF DOSGi current snapshot from trunk, and that sort of fixes
the issue in that the service is removed when the bundle is stopped, but
the entry in zookeeper remains, meaning consuming services still try and
use it.
Is this a bug, or my misunderstanding of what should happen ?
Thanks,
Jon.
On Tue, May 14, 2013, at 11:51 AM, Jon Barber wrote:
> Hi Christian,
>
> Many thanks for looking at this.
>
> I should have made it clearer in the README - I started zookeeper
> externally, but your method makes it even easier to reproduce.
>
> I explicitly set the port & server to get around an issue when I had 2
> Karaf containers running - at least one would not use the default 8181
> port and CXF seemed to default to this, leading to the service not being
> registered (or at least that seemed to be the case). If I can omit that
> line even better.
>
> Jon.
>
> On Tue, May 14, 2013, at 10:57 AM, Christian Schneider wrote:
> > Hi Jon,
> >
> > I was not able to run your example as is.
> > The first problem was that zookeeper was missing. So I needed to run:
> > features:install cxf-dosgi-zookeeper-server
> > cxf-dosgi-discovery-distributed
> >
> > Then it tried to come up but I got the message that a jetty was already
> > started on this port. So this may point to another bug.
> >
> > I simplified your example a but by doing:
> >
> > props.put("service.exported.interfaces", "*");
> > props.put("service.exported.configs", "org.apache.cxf.ws");
> > props.put("org.apache.cxf.ws.address", "/display"); // old
> > obsolete value
> > // props.put("endpoint.id", address);
> >
> > So I simply used an address without server and port. This signals dosgi
> > to use the servlet transport. So it uses the default port 8181 and the
> > default cxf servlet alias of "cxf". The full address then looks like
> > this: http://192.168.7.2:8181/cxf/display
> >
> > Is there a special reason why you explicitly specify a port and a server
> > name? I think using the servlet transport is much easier and allows to
> > centrally manage the port at one place.
> >
> > So this allowed me to get the service published. I then tried to stop
> > the bundle. The service was still available like you reported.
> > I will track the issue in:
> > https://issues.apache.org/jira/browse/DOSGI-180
> >
> > As a next step I will test with the current snapshot and try to debug
> > where the problem is originated.
> >
> > Christian
> >
> >
> > On 14.05.2013 10:11, Jon Barber wrote:
> > > Hi Christian,
> > >
> > > The code I'm using is available at
> > > https://github.com/sneakybeaky/DOSGi-Spike and I've added details to the
> > > README about how to recreate.
> > >
> > > Thanks,
> > >
> > > Jon.
> > >
> > > On Mon, May 13, 2013, at 11:48 PM, Christian Schneider wrote:
> > >> I think the patch will not work for your problem as you only register
> > >> the service once.
> > >>
> > >> I will try to recreate the problem on my system.
> > >>
> > >> Christian
> > >>
> > >> Am 13.05.2013 21:36, schrieb Jon Barber:
> > >>> Hi,
> > >>>
> > >>> I applied that patch, built as 1.5.0-SNAPSHOT and loaded into a running
> > >>> Karaf instance. Same issue - this doesn't seem to fix the problem.
> > >>>
> > >>> Jon.
> > >>>
> > >>> On Mon, May 13, 2013, at 04:36 PM, Sergey Beryozkin wrote:
> > >>>> Hi
> > >>>>
> > >>>> Please watch the following JIRA:
> > >>>>
> > >>>> https://issues.apache.org/jira/browse/DOSGI-177
> > >>>>
> > >>>> it even has a patch attached, so will be fixed for DOSGi 1.5
> > >>>>
> > >>>> Sergey
> > >>>> On 13/05/13 16:03, Jon Barber wrote:
> > >>>>> Hi,
> > >>>>>
> > >>>>> I have a simple OSGi service I've exposed via CXF DOSGi 1.4.0 using
> > >>>>> Karaf 2.2.11 - it's pretty much a straight copy from the discovery
> > >>>>> sample from the 1.4.0 release of cxf-dosgi. The service is exposed by
> > >>>>> the bundle activator as follows :
> > >>>>>
> > >>>>> private ServiceRegistration reg;
> > >>>>>
> > >>>>> public void start(BundleContext bc) throws Exception {
> > >>>>> Dictionary<String, Object> props = new Hashtable<String,
> > >>>>> Object>();
> > >>>>>
> > >>>>> String host = getHostName();
> > >>>>> int port = getPort();
> > >>>>>
> > >>>>> String address = getAddress(host,port);
> > >>>>> LOG.info("Registering ws address {}",address);
> > >>>>>
> > >>>>> props.put("service.exported.interfaces", "*");
> > >>>>> props.put("service.exported.configs", "org.apache.cxf.ws");
> > >>>>> props.put("org.apache.cxf.ws.address", address); // old obsolete
> > >>>>> value
> > >>>>> props.put("endpoint.id", address);
> > >>>>>
> > >>>>> reg = bc.registerService(PingService.class.getName(),
> > >>>>> new SimplePingService(), props);
> > >>>>> }
> > >>>>>
> > >>>>> public void stop(BundleContext bc) throws Exception {
> > >>>>> LOG.info("Unregistering ping service");
> > >>>>>
> > >>>>> reg.unregister();
> > >>>>> }
> > >>>>>
> > >>>>>
> > >>>>> And sure enough it gets registered as a SOAP service and I can see it in
> > >>>>> zookeeper too. However, when I stop the bundle the service is indeed
> > >>>>> removed in the local OSGi registry but I can still access the SOAP
> > >>>>> endpoint, and it's still visible in zookeeper too. Furthermore, if I
> > >>>>> re-activate the bundle the service is now available on the old endpoint
> > >>>>> and the new one.
> > >>>>>
> > >>>>> So either my understanding is wrong (I would have thought unregistering
> > >>>>> the service would remove the SOAP service too) or there's a bug in
> > >>>>> DOSGi, or I'm missing something / doing something wrong.
> > >>>>>
> > >>>>> Could someone give some guidance please ?
> > >>>>>
> > >>>>> Thanks,
> > >>>>>
> > >>>>> Jon.
> > >>>> --
> > >>>> Sergey Beryozkin
> > >>>>
> > >>>> Talend Community Coders
> > >>>> http://coders.talend.com/
> > >>>>
> > >>>> Blog: http://sberyozkin.blogspot.com
> > >>
> > >> --
> > >>
> > >> Christian Schneider
> > >> http://www.liquid-reality.de
> > >>
> > >> Open Source Architect
> > >> Talend Application Integration Division http://www.talend.com
> > >>
> >
> >
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Open Source Architect
> > http://www.talend.com
> >
Re: DOSGi service still available after being unregistered
Posted by Jon Barber <jo...@acm.org>.
Hi Christian,
Many thanks for looking at this.
I should have made it clearer in the README - I started zookeeper
externally, but your method makes it even easier to reproduce.
I explicitly set the port & server to get around an issue when I had 2
Karaf containers running - at least one would not use the default 8181
port and CXF seemed to default to this, leading to the service not being
registered (or at least that seemed to be the case). If I can omit that
line even better.
Jon.
On Tue, May 14, 2013, at 10:57 AM, Christian Schneider wrote:
> Hi Jon,
>
> I was not able to run your example as is.
> The first problem was that zookeeper was missing. So I needed to run:
> features:install cxf-dosgi-zookeeper-server
> cxf-dosgi-discovery-distributed
>
> Then it tried to come up but I got the message that a jetty was already
> started on this port. So this may point to another bug.
>
> I simplified your example a but by doing:
>
> props.put("service.exported.interfaces", "*");
> props.put("service.exported.configs", "org.apache.cxf.ws");
> props.put("org.apache.cxf.ws.address", "/display"); // old
> obsolete value
> // props.put("endpoint.id", address);
>
> So I simply used an address without server and port. This signals dosgi
> to use the servlet transport. So it uses the default port 8181 and the
> default cxf servlet alias of "cxf". The full address then looks like
> this: http://192.168.7.2:8181/cxf/display
>
> Is there a special reason why you explicitly specify a port and a server
> name? I think using the servlet transport is much easier and allows to
> centrally manage the port at one place.
>
> So this allowed me to get the service published. I then tried to stop
> the bundle. The service was still available like you reported.
> I will track the issue in:
> https://issues.apache.org/jira/browse/DOSGI-180
>
> As a next step I will test with the current snapshot and try to debug
> where the problem is originated.
>
> Christian
>
>
> On 14.05.2013 10:11, Jon Barber wrote:
> > Hi Christian,
> >
> > The code I'm using is available at
> > https://github.com/sneakybeaky/DOSGi-Spike and I've added details to the
> > README about how to recreate.
> >
> > Thanks,
> >
> > Jon.
> >
> > On Mon, May 13, 2013, at 11:48 PM, Christian Schneider wrote:
> >> I think the patch will not work for your problem as you only register
> >> the service once.
> >>
> >> I will try to recreate the problem on my system.
> >>
> >> Christian
> >>
> >> Am 13.05.2013 21:36, schrieb Jon Barber:
> >>> Hi,
> >>>
> >>> I applied that patch, built as 1.5.0-SNAPSHOT and loaded into a running
> >>> Karaf instance. Same issue - this doesn't seem to fix the problem.
> >>>
> >>> Jon.
> >>>
> >>> On Mon, May 13, 2013, at 04:36 PM, Sergey Beryozkin wrote:
> >>>> Hi
> >>>>
> >>>> Please watch the following JIRA:
> >>>>
> >>>> https://issues.apache.org/jira/browse/DOSGI-177
> >>>>
> >>>> it even has a patch attached, so will be fixed for DOSGi 1.5
> >>>>
> >>>> Sergey
> >>>> On 13/05/13 16:03, Jon Barber wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I have a simple OSGi service I've exposed via CXF DOSGi 1.4.0 using
> >>>>> Karaf 2.2.11 - it's pretty much a straight copy from the discovery
> >>>>> sample from the 1.4.0 release of cxf-dosgi. The service is exposed by
> >>>>> the bundle activator as follows :
> >>>>>
> >>>>> private ServiceRegistration reg;
> >>>>>
> >>>>> public void start(BundleContext bc) throws Exception {
> >>>>> Dictionary<String, Object> props = new Hashtable<String,
> >>>>> Object>();
> >>>>>
> >>>>> String host = getHostName();
> >>>>> int port = getPort();
> >>>>>
> >>>>> String address = getAddress(host,port);
> >>>>> LOG.info("Registering ws address {}",address);
> >>>>>
> >>>>> props.put("service.exported.interfaces", "*");
> >>>>> props.put("service.exported.configs", "org.apache.cxf.ws");
> >>>>> props.put("org.apache.cxf.ws.address", address); // old obsolete
> >>>>> value
> >>>>> props.put("endpoint.id", address);
> >>>>>
> >>>>> reg = bc.registerService(PingService.class.getName(),
> >>>>> new SimplePingService(), props);
> >>>>> }
> >>>>>
> >>>>> public void stop(BundleContext bc) throws Exception {
> >>>>> LOG.info("Unregistering ping service");
> >>>>>
> >>>>> reg.unregister();
> >>>>> }
> >>>>>
> >>>>>
> >>>>> And sure enough it gets registered as a SOAP service and I can see it in
> >>>>> zookeeper too. However, when I stop the bundle the service is indeed
> >>>>> removed in the local OSGi registry but I can still access the SOAP
> >>>>> endpoint, and it's still visible in zookeeper too. Furthermore, if I
> >>>>> re-activate the bundle the service is now available on the old endpoint
> >>>>> and the new one.
> >>>>>
> >>>>> So either my understanding is wrong (I would have thought unregistering
> >>>>> the service would remove the SOAP service too) or there's a bug in
> >>>>> DOSGi, or I'm missing something / doing something wrong.
> >>>>>
> >>>>> Could someone give some guidance please ?
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Jon.
> >>>> --
> >>>> Sergey Beryozkin
> >>>>
> >>>> Talend Community Coders
> >>>> http://coders.talend.com/
> >>>>
> >>>> Blog: http://sberyozkin.blogspot.com
> >>
> >> --
> >>
> >> Christian Schneider
> >> http://www.liquid-reality.de
> >>
> >> Open Source Architect
> >> Talend Application Integration Division http://www.talend.com
> >>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
Re: DOSGi service still available after being unregistered
Posted by Christian Schneider <ch...@die-schneider.net>.
I just tested with the current CXF DOSGi 1.5-SNAPSHOT.
features:chooseurl cxf-dosgi 1.5-SNAPSHOT
features:install cxf-dosgi-discovery-distributed cxf-dosgi-zookeeper-server
features:addUrl
mvn:com.ninedemons.spikes.dosgi/features/1.0.0-SNAPSHOT/xml/features
features:install dosgi-service
The service installs and the CXF endpoint appears. After I stop the
bundle the service has disappeared again. So I think this is fixed.
I will now check the other problem with jetty reporting it was already
started.
Christian
On 14.05.2013 11:57, Christian Schneider wrote:
> Hi Jon,
>
> I was not able to run your example as is.
> The first problem was that zookeeper was missing. So I needed to run:
> features:install cxf-dosgi-zookeeper-server
> cxf-dosgi-discovery-distributed
>
> Then it tried to come up but I got the message that a jetty was
> already started on this port. So this may point to another bug.
>
> I simplified your example a but by doing:
>
> props.put("service.exported.interfaces", "*");
> props.put("service.exported.configs", "org.apache.cxf.ws");
> props.put("org.apache.cxf.ws.address", "/display"); // old
> obsolete value
> // props.put("endpoint.id", address);
>
> So I simply used an address without server and port. This signals
> dosgi to use the servlet transport. So it uses the default port 8181
> and the default cxf servlet alias of "cxf". The full address then
> looks like this: http://192.168.7.2:8181/cxf/display
>
> Is there a special reason why you explicitly specify a port and a
> server name? I think using the servlet transport is much easier and
> allows to centrally manage the port at one place.
>
> So this allowed me to get the service published. I then tried to stop
> the bundle. The service was still available like you reported.
> I will track the issue in:
> https://issues.apache.org/jira/browse/DOSGI-180
>
> As a next step I will test with the current snapshot and try to debug
> where the problem is originated.
>
> Christian
>
>
> On 14.05.2013 10:11, Jon Barber wrote:
>> Hi Christian,
>>
>> The code I'm using is available at
>> https://github.com/sneakybeaky/DOSGi-Spike and I've added details to the
>> README about how to recreate.
>>
>> Thanks,
>>
>> Jon.
>>
>> On Mon, May 13, 2013, at 11:48 PM, Christian Schneider wrote:
>>> I think the patch will not work for your problem as you only register
>>> the service once.
>>>
>>> I will try to recreate the problem on my system.
>>>
>>> Christian
>>>
>>> Am 13.05.2013 21:36, schrieb Jon Barber:
>>>> Hi,
>>>>
>>>> I applied that patch, built as 1.5.0-SNAPSHOT and loaded into a
>>>> running
>>>> Karaf instance. Same issue - this doesn't seem to fix the problem.
>>>>
>>>> Jon.
>>>>
>>>> On Mon, May 13, 2013, at 04:36 PM, Sergey Beryozkin wrote:
>>>>> Hi
>>>>>
>>>>> Please watch the following JIRA:
>>>>>
>>>>> https://issues.apache.org/jira/browse/DOSGI-177
>>>>>
>>>>> it even has a patch attached, so will be fixed for DOSGi 1.5
>>>>>
>>>>> Sergey
>>>>> On 13/05/13 16:03, Jon Barber wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I have a simple OSGi service I've exposed via CXF DOSGi 1.4.0 using
>>>>>> Karaf 2.2.11 - it's pretty much a straight copy from the discovery
>>>>>> sample from the 1.4.0 release of cxf-dosgi. The service is
>>>>>> exposed by
>>>>>> the bundle activator as follows :
>>>>>>
>>>>>> private ServiceRegistration reg;
>>>>>>
>>>>>> public void start(BundleContext bc) throws Exception {
>>>>>> Dictionary<String, Object> props = new Hashtable<String,
>>>>>> Object>();
>>>>>>
>>>>>> String host = getHostName();
>>>>>> int port = getPort();
>>>>>>
>>>>>> String address = getAddress(host,port);
>>>>>> LOG.info("Registering ws address {}",address);
>>>>>>
>>>>>> props.put("service.exported.interfaces", "*");
>>>>>> props.put("service.exported.configs",
>>>>>> "org.apache.cxf.ws");
>>>>>> props.put("org.apache.cxf.ws.address", address); //
>>>>>> old obsolete
>>>>>> value
>>>>>> props.put("endpoint.id", address);
>>>>>>
>>>>>> reg = bc.registerService(PingService.class.getName(),
>>>>>> new SimplePingService(), props);
>>>>>> }
>>>>>>
>>>>>> public void stop(BundleContext bc) throws Exception {
>>>>>> LOG.info("Unregistering ping service");
>>>>>>
>>>>>> reg.unregister();
>>>>>> }
>>>>>>
>>>>>>
>>>>>> And sure enough it gets registered as a SOAP service and I can
>>>>>> see it in
>>>>>> zookeeper too. However, when I stop the bundle the service is indeed
>>>>>> removed in the local OSGi registry but I can still access the SOAP
>>>>>> endpoint, and it's still visible in zookeeper too. Furthermore, if I
>>>>>> re-activate the bundle the service is now available on the old
>>>>>> endpoint
>>>>>> and the new one.
>>>>>>
>>>>>> So either my understanding is wrong (I would have thought
>>>>>> unregistering
>>>>>> the service would remove the SOAP service too) or there's a bug in
>>>>>> DOSGi, or I'm missing something / doing something wrong.
>>>>>>
>>>>>> Could someone give some guidance please ?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jon.
>>>>> --
>>>>> Sergey Beryozkin
>>>>>
>>>>> Talend Community Coders
>>>>> http://coders.talend.com/
>>>>>
>>>>> Blog: http://sberyozkin.blogspot.com
>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> Talend Application Integration Division http://www.talend.com
>>>
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: DOSGi service still available after being unregistered
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Jon,
I was not able to run your example as is.
The first problem was that zookeeper was missing. So I needed to run:
features:install cxf-dosgi-zookeeper-server cxf-dosgi-discovery-distributed
Then it tried to come up but I got the message that a jetty was already
started on this port. So this may point to another bug.
I simplified your example a but by doing:
props.put("service.exported.interfaces", "*");
props.put("service.exported.configs", "org.apache.cxf.ws");
props.put("org.apache.cxf.ws.address", "/display"); // old
obsolete value
// props.put("endpoint.id", address);
So I simply used an address without server and port. This signals dosgi
to use the servlet transport. So it uses the default port 8181 and the
default cxf servlet alias of "cxf". The full address then looks like
this: http://192.168.7.2:8181/cxf/display
Is there a special reason why you explicitly specify a port and a server
name? I think using the servlet transport is much easier and allows to
centrally manage the port at one place.
So this allowed me to get the service published. I then tried to stop
the bundle. The service was still available like you reported.
I will track the issue in:
https://issues.apache.org/jira/browse/DOSGI-180
As a next step I will test with the current snapshot and try to debug
where the problem is originated.
Christian
On 14.05.2013 10:11, Jon Barber wrote:
> Hi Christian,
>
> The code I'm using is available at
> https://github.com/sneakybeaky/DOSGi-Spike and I've added details to the
> README about how to recreate.
>
> Thanks,
>
> Jon.
>
> On Mon, May 13, 2013, at 11:48 PM, Christian Schneider wrote:
>> I think the patch will not work for your problem as you only register
>> the service once.
>>
>> I will try to recreate the problem on my system.
>>
>> Christian
>>
>> Am 13.05.2013 21:36, schrieb Jon Barber:
>>> Hi,
>>>
>>> I applied that patch, built as 1.5.0-SNAPSHOT and loaded into a running
>>> Karaf instance. Same issue - this doesn't seem to fix the problem.
>>>
>>> Jon.
>>>
>>> On Mon, May 13, 2013, at 04:36 PM, Sergey Beryozkin wrote:
>>>> Hi
>>>>
>>>> Please watch the following JIRA:
>>>>
>>>> https://issues.apache.org/jira/browse/DOSGI-177
>>>>
>>>> it even has a patch attached, so will be fixed for DOSGi 1.5
>>>>
>>>> Sergey
>>>> On 13/05/13 16:03, Jon Barber wrote:
>>>>> Hi,
>>>>>
>>>>> I have a simple OSGi service I've exposed via CXF DOSGi 1.4.0 using
>>>>> Karaf 2.2.11 - it's pretty much a straight copy from the discovery
>>>>> sample from the 1.4.0 release of cxf-dosgi. The service is exposed by
>>>>> the bundle activator as follows :
>>>>>
>>>>> private ServiceRegistration reg;
>>>>>
>>>>> public void start(BundleContext bc) throws Exception {
>>>>> Dictionary<String, Object> props = new Hashtable<String,
>>>>> Object>();
>>>>>
>>>>> String host = getHostName();
>>>>> int port = getPort();
>>>>>
>>>>> String address = getAddress(host,port);
>>>>> LOG.info("Registering ws address {}",address);
>>>>>
>>>>> props.put("service.exported.interfaces", "*");
>>>>> props.put("service.exported.configs", "org.apache.cxf.ws");
>>>>> props.put("org.apache.cxf.ws.address", address); // old obsolete
>>>>> value
>>>>> props.put("endpoint.id", address);
>>>>>
>>>>> reg = bc.registerService(PingService.class.getName(),
>>>>> new SimplePingService(), props);
>>>>> }
>>>>>
>>>>> public void stop(BundleContext bc) throws Exception {
>>>>> LOG.info("Unregistering ping service");
>>>>>
>>>>> reg.unregister();
>>>>> }
>>>>>
>>>>>
>>>>> And sure enough it gets registered as a SOAP service and I can see it in
>>>>> zookeeper too. However, when I stop the bundle the service is indeed
>>>>> removed in the local OSGi registry but I can still access the SOAP
>>>>> endpoint, and it's still visible in zookeeper too. Furthermore, if I
>>>>> re-activate the bundle the service is now available on the old endpoint
>>>>> and the new one.
>>>>>
>>>>> So either my understanding is wrong (I would have thought unregistering
>>>>> the service would remove the SOAP service too) or there's a bug in
>>>>> DOSGi, or I'm missing something / doing something wrong.
>>>>>
>>>>> Could someone give some guidance please ?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jon.
>>>> --
>>>> Sergey Beryozkin
>>>>
>>>> Talend Community Coders
>>>> http://coders.talend.com/
>>>>
>>>> Blog: http://sberyozkin.blogspot.com
>>
>> --
>>
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: DOSGi service still available after being unregistered
Posted by Jon Barber <jo...@acm.org>.
Hi Christian,
The code I'm using is available at
https://github.com/sneakybeaky/DOSGi-Spike and I've added details to the
README about how to recreate.
Thanks,
Jon.
On Mon, May 13, 2013, at 11:48 PM, Christian Schneider wrote:
> I think the patch will not work for your problem as you only register
> the service once.
>
> I will try to recreate the problem on my system.
>
> Christian
>
> Am 13.05.2013 21:36, schrieb Jon Barber:
> > Hi,
> >
> > I applied that patch, built as 1.5.0-SNAPSHOT and loaded into a running
> > Karaf instance. Same issue - this doesn't seem to fix the problem.
> >
> > Jon.
> >
> > On Mon, May 13, 2013, at 04:36 PM, Sergey Beryozkin wrote:
> >> Hi
> >>
> >> Please watch the following JIRA:
> >>
> >> https://issues.apache.org/jira/browse/DOSGI-177
> >>
> >> it even has a patch attached, so will be fixed for DOSGi 1.5
> >>
> >> Sergey
> >> On 13/05/13 16:03, Jon Barber wrote:
> >>> Hi,
> >>>
> >>> I have a simple OSGi service I've exposed via CXF DOSGi 1.4.0 using
> >>> Karaf 2.2.11 - it's pretty much a straight copy from the discovery
> >>> sample from the 1.4.0 release of cxf-dosgi. The service is exposed by
> >>> the bundle activator as follows :
> >>>
> >>> private ServiceRegistration reg;
> >>>
> >>> public void start(BundleContext bc) throws Exception {
> >>> Dictionary<String, Object> props = new Hashtable<String,
> >>> Object>();
> >>>
> >>> String host = getHostName();
> >>> int port = getPort();
> >>>
> >>> String address = getAddress(host,port);
> >>> LOG.info("Registering ws address {}",address);
> >>>
> >>> props.put("service.exported.interfaces", "*");
> >>> props.put("service.exported.configs", "org.apache.cxf.ws");
> >>> props.put("org.apache.cxf.ws.address", address); // old obsolete
> >>> value
> >>> props.put("endpoint.id", address);
> >>>
> >>> reg = bc.registerService(PingService.class.getName(),
> >>> new SimplePingService(), props);
> >>> }
> >>>
> >>> public void stop(BundleContext bc) throws Exception {
> >>> LOG.info("Unregistering ping service");
> >>>
> >>> reg.unregister();
> >>> }
> >>>
> >>>
> >>> And sure enough it gets registered as a SOAP service and I can see it in
> >>> zookeeper too. However, when I stop the bundle the service is indeed
> >>> removed in the local OSGi registry but I can still access the SOAP
> >>> endpoint, and it's still visible in zookeeper too. Furthermore, if I
> >>> re-activate the bundle the service is now available on the old endpoint
> >>> and the new one.
> >>>
> >>> So either my understanding is wrong (I would have thought unregistering
> >>> the service would remove the SOAP service too) or there's a bug in
> >>> DOSGi, or I'm missing something / doing something wrong.
> >>>
> >>> Could someone give some guidance please ?
> >>>
> >>> Thanks,
> >>>
> >>> Jon.
> >>
> >> --
> >> Sergey Beryozkin
> >>
> >> Talend Community Coders
> >> http://coders.talend.com/
> >>
> >> Blog: http://sberyozkin.blogspot.com
>
>
> --
>
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
Re: DOSGi service still available after being unregistered
Posted by Christian Schneider <ch...@die-schneider.net>.
I think the patch will not work for your problem as you only register
the service once.
I will try to recreate the problem on my system.
Christian
Am 13.05.2013 21:36, schrieb Jon Barber:
> Hi,
>
> I applied that patch, built as 1.5.0-SNAPSHOT and loaded into a running
> Karaf instance. Same issue - this doesn't seem to fix the problem.
>
> Jon.
>
> On Mon, May 13, 2013, at 04:36 PM, Sergey Beryozkin wrote:
>> Hi
>>
>> Please watch the following JIRA:
>>
>> https://issues.apache.org/jira/browse/DOSGI-177
>>
>> it even has a patch attached, so will be fixed for DOSGi 1.5
>>
>> Sergey
>> On 13/05/13 16:03, Jon Barber wrote:
>>> Hi,
>>>
>>> I have a simple OSGi service I've exposed via CXF DOSGi 1.4.0 using
>>> Karaf 2.2.11 - it's pretty much a straight copy from the discovery
>>> sample from the 1.4.0 release of cxf-dosgi. The service is exposed by
>>> the bundle activator as follows :
>>>
>>> private ServiceRegistration reg;
>>>
>>> public void start(BundleContext bc) throws Exception {
>>> Dictionary<String, Object> props = new Hashtable<String,
>>> Object>();
>>>
>>> String host = getHostName();
>>> int port = getPort();
>>>
>>> String address = getAddress(host,port);
>>> LOG.info("Registering ws address {}",address);
>>>
>>> props.put("service.exported.interfaces", "*");
>>> props.put("service.exported.configs", "org.apache.cxf.ws");
>>> props.put("org.apache.cxf.ws.address", address); // old obsolete
>>> value
>>> props.put("endpoint.id", address);
>>>
>>> reg = bc.registerService(PingService.class.getName(),
>>> new SimplePingService(), props);
>>> }
>>>
>>> public void stop(BundleContext bc) throws Exception {
>>> LOG.info("Unregistering ping service");
>>>
>>> reg.unregister();
>>> }
>>>
>>>
>>> And sure enough it gets registered as a SOAP service and I can see it in
>>> zookeeper too. However, when I stop the bundle the service is indeed
>>> removed in the local OSGi registry but I can still access the SOAP
>>> endpoint, and it's still visible in zookeeper too. Furthermore, if I
>>> re-activate the bundle the service is now available on the old endpoint
>>> and the new one.
>>>
>>> So either my understanding is wrong (I would have thought unregistering
>>> the service would remove the SOAP service too) or there's a bug in
>>> DOSGi, or I'm missing something / doing something wrong.
>>>
>>> Could someone give some guidance please ?
>>>
>>> Thanks,
>>>
>>> Jon.
>>
>> --
>> Sergey Beryozkin
>>
>> Talend Community Coders
>> http://coders.talend.com/
>>
>> Blog: http://sberyozkin.blogspot.com
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: DOSGi service still available after being unregistered
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 13/05/13 20:36, Jon Barber wrote:
> Hi,
>
> I applied that patch, built as 1.5.0-SNAPSHOT and loaded into a running
> Karaf instance. Same issue - this doesn't seem to fix the problem.
>
OK. This may be related to the fact standalone Jetty is used to create
the endpoints, it may be a CXF Jetty transport specific issue.
Can you experiment with HTTP service, instead of
"org.apache.cxf.ws.address" try "org.apache.cxf.ws.http.context" with a
relative value
Cheers, Sergey
> Jon.
>
> On Mon, May 13, 2013, at 04:36 PM, Sergey Beryozkin wrote:
>> Hi
>>
>> Please watch the following JIRA:
>>
>> https://issues.apache.org/jira/browse/DOSGI-177
>>
>> it even has a patch attached, so will be fixed for DOSGi 1.5
>>
>> Sergey
>> On 13/05/13 16:03, Jon Barber wrote:
>>> Hi,
>>>
>>> I have a simple OSGi service I've exposed via CXF DOSGi 1.4.0 using
>>> Karaf 2.2.11 - it's pretty much a straight copy from the discovery
>>> sample from the 1.4.0 release of cxf-dosgi. The service is exposed by
>>> the bundle activator as follows :
>>>
>>> private ServiceRegistration reg;
>>>
>>> public void start(BundleContext bc) throws Exception {
>>> Dictionary<String, Object> props = new Hashtable<String,
>>> Object>();
>>>
>>> String host = getHostName();
>>> int port = getPort();
>>>
>>> String address = getAddress(host,port);
>>> LOG.info("Registering ws address {}",address);
>>>
>>> props.put("service.exported.interfaces", "*");
>>> props.put("service.exported.configs", "org.apache.cxf.ws");
>>> props.put("org.apache.cxf.ws.address", address); // old obsolete
>>> value
>>> props.put("endpoint.id", address);
>>>
>>> reg = bc.registerService(PingService.class.getName(),
>>> new SimplePingService(), props);
>>> }
>>>
>>> public void stop(BundleContext bc) throws Exception {
>>> LOG.info("Unregistering ping service");
>>>
>>> reg.unregister();
>>> }
>>>
>>>
>>> And sure enough it gets registered as a SOAP service and I can see it in
>>> zookeeper too. However, when I stop the bundle the service is indeed
>>> removed in the local OSGi registry but I can still access the SOAP
>>> endpoint, and it's still visible in zookeeper too. Furthermore, if I
>>> re-activate the bundle the service is now available on the old endpoint
>>> and the new one.
>>>
>>> So either my understanding is wrong (I would have thought unregistering
>>> the service would remove the SOAP service too) or there's a bug in
>>> DOSGi, or I'm missing something / doing something wrong.
>>>
>>> Could someone give some guidance please ?
>>>
>>> Thanks,
>>>
>>> Jon.
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Talend Community Coders
>> http://coders.talend.com/
>>
>> Blog: http://sberyozkin.blogspot.com
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: DOSGi service still available after being unregistered
Posted by Jon Barber <jo...@acm.org>.
Hi,
I applied that patch, built as 1.5.0-SNAPSHOT and loaded into a running
Karaf instance. Same issue - this doesn't seem to fix the problem.
Jon.
On Mon, May 13, 2013, at 04:36 PM, Sergey Beryozkin wrote:
> Hi
>
> Please watch the following JIRA:
>
> https://issues.apache.org/jira/browse/DOSGI-177
>
> it even has a patch attached, so will be fixed for DOSGi 1.5
>
> Sergey
> On 13/05/13 16:03, Jon Barber wrote:
> > Hi,
> >
> > I have a simple OSGi service I've exposed via CXF DOSGi 1.4.0 using
> > Karaf 2.2.11 - it's pretty much a straight copy from the discovery
> > sample from the 1.4.0 release of cxf-dosgi. The service is exposed by
> > the bundle activator as follows :
> >
> > private ServiceRegistration reg;
> >
> > public void start(BundleContext bc) throws Exception {
> > Dictionary<String, Object> props = new Hashtable<String,
> > Object>();
> >
> > String host = getHostName();
> > int port = getPort();
> >
> > String address = getAddress(host,port);
> > LOG.info("Registering ws address {}",address);
> >
> > props.put("service.exported.interfaces", "*");
> > props.put("service.exported.configs", "org.apache.cxf.ws");
> > props.put("org.apache.cxf.ws.address", address); // old obsolete
> > value
> > props.put("endpoint.id", address);
> >
> > reg = bc.registerService(PingService.class.getName(),
> > new SimplePingService(), props);
> > }
> >
> > public void stop(BundleContext bc) throws Exception {
> > LOG.info("Unregistering ping service");
> >
> > reg.unregister();
> > }
> >
> >
> > And sure enough it gets registered as a SOAP service and I can see it in
> > zookeeper too. However, when I stop the bundle the service is indeed
> > removed in the local OSGi registry but I can still access the SOAP
> > endpoint, and it's still visible in zookeeper too. Furthermore, if I
> > re-activate the bundle the service is now available on the old endpoint
> > and the new one.
> >
> > So either my understanding is wrong (I would have thought unregistering
> > the service would remove the SOAP service too) or there's a bug in
> > DOSGi, or I'm missing something / doing something wrong.
> >
> > Could someone give some guidance please ?
> >
> > Thanks,
> >
> > Jon.
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com
Re: DOSGi service still available after being unregistered
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
Please watch the following JIRA:
https://issues.apache.org/jira/browse/DOSGI-177
it even has a patch attached, so will be fixed for DOSGi 1.5
Sergey
On 13/05/13 16:03, Jon Barber wrote:
> Hi,
>
> I have a simple OSGi service I've exposed via CXF DOSGi 1.4.0 using
> Karaf 2.2.11 - it's pretty much a straight copy from the discovery
> sample from the 1.4.0 release of cxf-dosgi. The service is exposed by
> the bundle activator as follows :
>
> private ServiceRegistration reg;
>
> public void start(BundleContext bc) throws Exception {
> Dictionary<String, Object> props = new Hashtable<String,
> Object>();
>
> String host = getHostName();
> int port = getPort();
>
> String address = getAddress(host,port);
> LOG.info("Registering ws address {}",address);
>
> props.put("service.exported.interfaces", "*");
> props.put("service.exported.configs", "org.apache.cxf.ws");
> props.put("org.apache.cxf.ws.address", address); // old obsolete
> value
> props.put("endpoint.id", address);
>
> reg = bc.registerService(PingService.class.getName(),
> new SimplePingService(), props);
> }
>
> public void stop(BundleContext bc) throws Exception {
> LOG.info("Unregistering ping service");
>
> reg.unregister();
> }
>
>
> And sure enough it gets registered as a SOAP service and I can see it in
> zookeeper too. However, when I stop the bundle the service is indeed
> removed in the local OSGi registry but I can still access the SOAP
> endpoint, and it's still visible in zookeeper too. Furthermore, if I
> re-activate the bundle the service is now available on the old endpoint
> and the new one.
>
> So either my understanding is wrong (I would have thought unregistering
> the service would remove the SOAP service too) or there's a bug in
> DOSGi, or I'm missing something / doing something wrong.
>
> Could someone give some guidance please ?
>
> Thanks,
>
> Jon.
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com