cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: CXF-DOSGi Zookeeper discovery data transformation
Date Mon, 25 Jun 2012 10:32:28 GMT
Hi David

Thanks for the explanation,
On 25/06/12 09:02, David Bosschaert wrote:
> Hi Sergey,
> On 22 June 2012 17:43, Sergey Beryozkin<>  wrote:
>> Hi David
>> On 22/06/12 15:58, David Bosschaert wrote:
>>> Hi all,
>>> I'm currently playing with CXF-DOSGi in the context of a cloud setup
>>> and I'm also using the Zookeeper-based discovery.
>>> The problem that I'm facing is that the host and port as known by the
>>> local framework (running inside a cloud instance) is not the same as
>>> the public host and port. Obviously to be able to access the remoted
>>> service from outside you need the public host and port.
>>> So I came up with a DiscoveryPlugin interface which bundles can
>>> register in the OSGi Service Registry (in the true OSGi Whiteboard
>>> pattern way) to support such a transformation.
>>> It has the following API:
>>> public interface DiscoveryPlugin {
>>>      String process(Map<String, Object>    mutableMap, String fullPath);
>>> }
>>> Before the ZooKeeper client code in CXF registers the endpoint with
>>> the ZooKeeper server all registered DiscoveryPlugin are given a chance
>>> to process the data. They can change the properties of the service
>>> registration and change the path. So in my case I can change the URL
>>> where the local framework thinks it registers it (e.g.
>>> to the URL from where things are publicly accessible
>>> (e.g.
>>> Would everyone be happy with me adding this feature to the
>>> cxf-dosgi-ri-discovery-distributed module? It's backward compatible -
>>> if you have no plugins registered nothing happens.
>> Looks like a neat idea.
>> What does mutableMap will represent ?
> You're right - I could have made that a little more clear :) It
> represents the service registration properties that will be stored in
> ZooKeeper. For an example service they look like this:
>    endpoint.framework.uuid=609a4e6b-9abe-0011-1888-adf8693241e9,
>    objectClass=[],
>    service.imported.configs=[],
>    service.imported=true,
>    service.intents=[SOAP.1_1, HTTP, SOAP],
> So it might be more appropriate to call the argument mutableProperties
> instead of mutableMap (I'll make sure to add proper JavaDoc too :).
> Whatever you change in that map will be stored in ZooKeeper using the
> changed value (note that the actual service registration in the local
> framework doesn't change).
> The plugin also allows you to change the path where it is changed by
> returning a different path, so for example in my case the fullPath
> variable is
>    /osgi/service_registry/org/acme/foo/SomeInterface/
> It would allow you to change that to something like
>    /osgi/service_registry/org/acme/foo/SomeInterface/
Sounds good. Minor observation is I guess that the plugin would only be 
interested in replacing the the "" part, and if yes 
then may be it will be marginally simpler to have:

String process(Map<String, Object> mutableProperties,
                String registryPath,
                String hostInformation);

String actualHostInfo = plugin.process(properties,

Not sure if it make sense :-). Having a plugin to do a basic parsing of 
the fullPath would not ne a big issue I guess :-)

Cheers, Sergey

> Cheers,
> David

View raw message