Closer, but not quite... The osgi.remote.endpoint.location does show up in the Zookeeper entry with the IP address properly externalized, but there is no org.apache.cxf.ws.address entry. That appears to be what the client will bind against, not the enpoint location.
It's also more than possible I didn't update all the requisite bundles. I updated these: cxf-dosgi-ri-dsw-cxf-1.1-SNAPSHOT.jar cxf-dosgi-ri-discovery-local-1.1-SNAPSHOT.jar cxf-dosgi-ri-discovery-distributed-zookeeper-wrapper-1.1-SNAPSHOT.jar cxf-dosgi-ri-discovery-distributed-1.1-SNAPSHOT.jar Missing any? Thanks, Thom -----Original Message----- From: David Bosschaert [mailto:[email protected]] Sent: Friday, August 21, 2009 5:22 AM To: [email protected] Subject: Re: Default endpoint via Zookeeper (D-OSGi) (repost to get its own thread, sorry all) I've just committed a fix in r806505. It should be pushed to 1.1-SNAPSHOT in maven overnight. Please let me know if it works for you. David 2009/8/21 David Bosschaert <[email protected]>: > Hi Thom, > > Just to let you know that using two machines I have reproduced your problem. > I'm currently working on a fix. > > Best regards, > > David > > 2009/8/18 David Bosschaert <[email protected]>: >> Ah, right, and it did work for me because I was trying it out on a >> single machine. >> Let me go back and try to fix this issue. >> >> Cheers, >> >> David >> >> 2009/8/13 Shulok, Thomas <[email protected]>: >>> Hi David, >>> >>> I don't think I explained the problem clearly enough. The node does indeed >>> get registered, but it's missing a property. Instead of doing an ls on the >>> entry, do a get. Inside the entry, I think you'll see that it's missing >>> the org.apache.cxf.ws.address property. Without that, the remote client >>> will bind to localhost (itself) because it can't find the server. >>> >>> Thanks, >>> Thom >>> >>> -----Original Message----- >>> From: David Bosschaert [mailto:[email protected]] >>> Sent: Thursday, August 13, 2009 8:37 AM >>> To: [email protected] >>> Subject: Re: Default endpoint via Zookeeper (D-OSGi) (repost to get >>> its own thread, sorry all) >>> >>> That works for me too. >>> >>> I'm now using the following code: >>> Dictionary props = new Hashtable(); >>> >>> props.put("service.exported.interfaces", "*"); >>> >>> reg = bc.registerService(DisplayService.class.getName(), new >>> DisplayServiceImpl(""), props); >>> >>> Its working fine for me. Could you give it a try? >>> >>> David >>> >>> 2009/8/13 Shulok, Thomas <[email protected]>: >>>> >>>> Hi David, >>>> >>>> Still one difference...I don't specify (the equivalent of) >>>> >>>> props.put("service.exported.configs", "org.apache.cxf.ws"); >>>> >>>> in the service decorator. Maybe I've been leveraging some undocumented >>>> default behavior, but if you just specify the service.exported.interfaces >>>> property, the current D-OSGi implementation will assume you want the web >>>> service config and set it up for you. >>>> >>>> Thanks, >>>> Thom >>>> -----Original Message----- >>>> From: David Bosschaert [mailto:[email protected]] >>>> Sent: Thursday, August 13, 2009 3:11 AM >>>> To: [email protected] >>>> Subject: Re: Default endpoint via Zookeeper (D-OSGi) (repost to get >>>> its own thread, sorry all) >>>> >>>> Hi Thomas, >>>> >>>> I changed my copy of the Discovery demo to reflect your situation, and it >>>> seems to work for me. >>>> In the file >>>> http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/discovery/i >>>> mpl >>>> /src/main/java/org/apache/cxf/dosgi/samples/discovery/impl/Activato >>>> r.j ava I'm registering my services as follows: >>>> Dictionary props = new Hashtable(); >>>> >>>> props.put("service.exported.interfaces", "*"); >>>> props.put("service.exported.configs", "org.apache.cxf.ws"); >>>> >>>> reg = bc.registerService(DisplayService.class.getName(), new >>>> DisplayServiceImpl(""), props); This registers the service under the >>>> default name in ZooKeeper, in this case the DefaultService interface name, >>>> so if I look in the location for >>>> org.apache.cxf.dosgi.samples.discovery.DisplayService in the ZooKeeper >>>> registry I can see my service there: >>>> zkCli> ls >>>> /osgi/service_registry/org/apache/cxf/dosgi/samples/discovery/Displ >>>> ayS >>>> ervice >>>> >>>> [10.2.4.18#9000##org#apache#cxf#dosgi#samples#discovery#DisplayServ >>>> ice >>>> ] >>>> >>>> running the client that is part of this demo works, it can find the >>>> service that is exposed using the defaults. >>>> >>>> Is this what you're trying to do or am I missing something? >>>> >>>> David >>>> >>>> 2009/8/12 Shulok, Thomas <[email protected]>: >>>>> One bug leads to another... :-) >>>>> >>>>> Your fix puts the correct endpoint location into the Zookeeper node. >>>>> Works great, thanks! But... >>>>> >>>>> If I don't specify org.apache.cxf.ws.address in the service decorator, I >>>>> would expect it to default to >>>>> http://localhost:9000/fully/qualified/ClassName as described in the >>>>> reference guide (http://cxf.apache.org/distributed-osgi-reference.html) >>>>> under service provider properties. The default would then get >>>>> transmorgrified into the actual IP of localhost just like the endpoint >>>>> and inserted into the node. Unfortunately, if I don't specify >>>>> org.apache.cxf.ws.address, it doesn't show up in the Zookeeper node at >>>>> all, which means the remote client thinks the web service address is >>>>> localhost (i.e. bad). >>>>> >>>>> Any hope/plan to incorporate the default behavior with the Zookeeper >>>>> integration? >>>>> >>>>> Thanks! >>>>> Thom >>>>> >>>>> -----Original Message----- >>>>> From: David Bosschaert [mailto:[email protected]] >>>>> Sent: Monday, August 10, 2009 6:49 AM >>>>> To: [email protected] >>>>> Subject: Re: Default endpoint via Zookeeper (D-OSGi) (repost to >>>>> get its own thread, sorry all) >>>>> >>>>> Hi Thomas, >>>>> >>>>> Just to let you know I've just committed a fix for this to trunk >>>>> (1.1-SNAPSHOT). The builds should publish a new snapshot of this tonight. >>>>> >>>>> With this fix you can set the org.apache.cxf.ws.address property to a >>>>> localhost value, like this: >>>>> props.put("org.apache.cxf.ws.address", >>>>> "http://localhost:9100/display";); >>>>> >>>>> Once it's pushed into the zookeeper server, the localhost and >>>>> 127.0.0.1 URLs are changed to contain the real IP address of the host, >>>>> like this: >>>>> >>>>> Hope this works for you too. >>>>> zkCli> get >>>>> zkCli> /osgi/service_registry/org/apache/cxf/dosgi/samples/discove >>>>> zkCli> ry/ D is playService/10.2.4.18#9100##display >>>>> # >>>>> #Mon Aug 10 14:37:47 BST 2009 >>>>> osgi.remote.endpoint.location=http\://10.2.4.18\:9100/display >>>>> service.id=40 >>>>> objectClass=[Ljava.lang.String;@188f506 >>>>> osgi.remote.interfaces=* >>>>> osgi.remote.configuration.pojo.address=http\://10.2.4.18\:9100/dis >>>>> pla >>>>> y >>>>> osgi.remote.configuration.type=pojo >>>>> osgi.remote.endpoint.id=f5a3d0ef-b1f6-4fe4-b03f-33190ec28dab >>>>> ... >>>>> >>>>> Cheers, >>>>> >>>>> David >>>>> >>>>> 2009/8/10 David Bosschaert <[email protected]>: >>>>>> Hi Thomas, >>>>>> >>>>>> Here are a couple of pointers. >>>>>> >>>>>> If you look at the Discovery demo, the Service Implementation >>>>>> Activator, you can see that in this activator it figures out the >>>>>> host name and sets that in the "osgi.remote.configuration.pojo.address" >>>>>> property: >>>>>> https://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/discover >>>>>> y/i >>>>>> m >>>>>> p >>>>>> l/src/main/java/org/apache/cxf/dosgi/samples/discovery/impl/Activator. >>>>>> java So you could do something similar when setting the property. >>>>>> >>>>>> However, if you are setting the property from a static file, this >>>>>> isn't really convenient. Therefore there is some additional >>>>>> support for translating 'localhost' into the machine name/IP addr >>>>>> when its registered in Discovery. If you specify the host in your >>>>>> address property as 'localhost', the zookeeper code will do a >>>>>> lookup on your machine name and register it under that (or the IP >>>>>> address). So in my case I'm getting the following registration in >>>>>> ZooKeeper: >>>>>> zkCli> ls >>>>>> zkCli> /osgi/service_registry/org/apache/cxf/dosgi/samples/discov >>>>>> zkCli> ery >>>>>> zkCli> / >>>>>> zkCli> D >>>>>> zkCli> isplayService >>>>>> [10.2.4.18#9100##display] >>>>>> So it translated 'localhost' into 10.2.4.18 >>>>>> >>>>>> However, looking at the properties inside the registration, I see >>>>>> that 'localhost' is still in there: >>>>>> zkCli> get >>>>>> zkCli> /osgi/service_registry/org/apache/cxf/dosgi/samples/discov >>>>>> zkCli> ery / D isplayService/10.2.4.18#9100##display >>>>>> # >>>>>> #Mon Aug 10 10:50:22 BST 2009 >>>>>> osgi.remote.endpoint.location=http\://localhost\:9100/display >>>>>> service.id=40 >>>>>> objectClass=[Ljava.lang.String;@1292ba7 >>>>>> osgi.remote.interfaces=* >>>>>> osgi.remote.configuration.pojo.address=http\://localhost\:9100/di >>>>>> spl >>>>>> a >>>>>> y >>>>>> osgi.remote.configuration.type=pojo >>>>>> osgi.remote.endpoint.id=464a4c2f-205c-4a06-a5e2-2f5127dc0894 >>>>>> ... >>>>>> >>>>>> So that's clearly a bug, I've filed >>>>>> https://issues.apache.org/jira/browse/CXF-2385 and will try to >>>>>> fix this over the coming few days. >>>>>> >>>>>> Hope this helps, >>>>>> >>>>>> David >>>>>> >>>>>> 2009/8/7 Shulok, Thomas <[email protected]>: >>>>>>> Hi All, >>>>>>> >>>>>>> Working with the Zookeeper discovery setup, and things are >>>>>>> working as long as I explicitly specify >>>>>>> org.apache.cxf.ws.address in my service decoration xml file. If >>>>>>> I don't specify it, it will default to localhost. Not >>>>>>> unreasonable, but the problem is, localhost will be the endpoint >>>>>>> that gets registered with Zookeeper. So, when another box looks for the >>>>>>> interface, Zookeeper will tell it that it is on localhost (i.e. >>>>>>> the client itself), and that will fail. With this setup, do you >>>>>>> have to explicitly specify the endpoint, or is there some other >>>>>>> default behavior to leverage that will actually use the real IP >>>>>>> of the registering localhost when it gets entered into Zookeeper >>>>>>> so other clients can find it? >>>>>>> >>>>>>> Many thanks, >>>>>>> >>>>>>> Thom >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
