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
