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
