Excellent, 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 >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
