Re: Curious URL in OSGI support in http_jetty
On Monday, June 25, 2012 12:33:40 PM Benson Margulies wrote: > public static final String JETTY_THREADING = > "http://cxf.apache.org/configuration/parameterized-types";; > > can someone explain the above? "git grep JETTY_THREADING" only shows that one reference in the entire tree. Thus, likely an unused variable that should be removed. :-) -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Curious URL in OSGI support in http_jetty
public static final String JETTY_THREADING = "http://cxf.apache.org/configuration/parameterized-types";; can someone explain the above?
Re: CXF-DOSGi Zookeeper discovery data transformation
Hi Sergey, On 25 June 2012 11:32, Sergey Beryozkin wrote: >> 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/127.0.0.1#8080##foo >> It would allow you to change that to something like >> /osgi/service_registry/org/acme/foo/SomeInterface/my.cloud.host#80##foo >> > Sounds good. Minor observation is I guess that the plugin would only be > interested in replacing the the "127.0.0.1#8080##foo" part, and if yes then > may be it will be marginally simpler to have: > > String process(Map mutableProperties, > String registryPath, > String hostInformation); > > String actualHostInfo = plugin.process(properties, > > "/osgi/service_registry/org/acme/foo/SomeInterface", > "127.0.0.1#8080##foo"); > > 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 :-) Good point. Changing the registryPath doesn't make sense, so I removed it completely from the callback. It now has the following API: String process(Map mutableProperties, String endpointKey); I've committed it all with unit tests in r1353598. Cheers, David
Re: Possible contribution of XKMS server (Key Information and Key Registration Protocols )
Hi Andrei, Are you planning to develop the code at Apache or donate it? If the latter then you may need to sign a code contribution form - not sure on the specifics, Dan will know more. I'm not sure if there are any other major issues to consider, the code can be put into the sandbox and the development can start or continue from there. Colm. On Fri, Jun 22, 2012 at 10:33 AM, Andrei Shakirin wrote: > Hi Colm, > > Actually it has the following deps: > - org.apache.commons.chain > - org.apache.commons.beanutils > - cxf > > Yes, we are going to contribute the XKMS Client as well. > > What is important for contribution additionally to code style, license > headers and dependencies? > > Regards, > Andrei. > > -Original Message- > From: Colm O hEigeartaigh [mailto:cohei...@apache.org] > Sent: 22 June 2012 11:25 > To: dev@cxf.apache.org > Cc: Daniel Kulp > Subject: Re: Possible contribution of XKMS server (Key Information and Key > Registration Protocols ) > > Hi Andrei, > > I think an XKMS server would be a useful component of CXF. I guess it > would go into the services module where the STS is as well. What kind of > dependencies will the project have? Will you also be contributing an XKMS > client? > > Colm. > > On Fri, Jun 22, 2012 at 9:47 AM, Andrei Shakirin >wrote: > > > Hi Dan & Colm, > > > > In next months we are going to implement, extend and improve XKMS > > server (key management) as part as custom project. > > It will include both Key Information and Key Registration Protocols > > implementations with LDAP backend. > > Actually it seems to be possible to implement XKMS under Apache license. > > Questions: from your point of view: does it make sense to contribute > > XKMS server in CXF in the same way as STS? Or is there project that > > fit better for this contribution (Syncope, etc)? What is necessary to > > care about to prepare the contribution? > > > > Regards, > > Andrei. > > > > > > -- > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
Re: CXF-DOSGi Zookeeper discovery data transformation
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(MapmutableMap, 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.
127.5.3.123:8080) to the URL from where things are publicly accessible
(e.g. my.cloud.instance:80).
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,
endpoint.id=http://127.0.0.1:8080/repo,
endpoint.package.version.org.acme.foo=1.0.0.SNAPSHOT
endpoint.service.id=44,
objectClass=[org.acme.foo.SomeInterface],
org.apache.cxf.ws.address=http://127.0.0.1:8080/repo,
service.imported.configs=[org.apache.cxf.ws],
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).
OK
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/127.0.0.1#8080##foo
It would allow you to change that to something like
/osgi/service_registry/org/acme/foo/SomeInterface/my.cloud.host#80##foo
Sounds good. Minor observation is I guess that the plugin would only be
interested in replacing the the "127.0.0.1#8080##foo" part, and if yes
then may be it will be marginally simpler to have:
String process(Map mutableProperties,
String registryPath,
String hostInformation);
String actualHostInfo = plugin.process(properties,
"/osgi/service_registry/org/acme/foo/SomeInterface",
"127.0.0.1#8080##foo");
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
Re: CXF-DOSGi Zookeeper discovery data transformation
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 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.
>> 127.5.3.123:8080) to the URL from where things are publicly accessible
>> (e.g. my.cloud.instance:80).
>>
>> 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,
endpoint.id=http://127.0.0.1:8080/repo,
endpoint.package.version.org.acme.foo=1.0.0.SNAPSHOT
endpoint.service.id=44,
objectClass=[org.acme.foo.SomeInterface],
org.apache.cxf.ws.address=http://127.0.0.1:8080/repo,
service.imported.configs=[org.apache.cxf.ws],
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/127.0.0.1#8080##foo
It would allow you to change that to something like
/osgi/service_registry/org/acme/foo/SomeInterface/my.cloud.host#80##foo
Cheers,
David
