You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by David Bosschaert <da...@gmail.com> on 2010/06/02 23:17:51 UTC
Re: CXF-DOSGi passing the OSGi Remote Services and Remote Service
Admin CT
Hi Sergey,
Some comments below...
On 13 May 2010 12:42, Sergey Beryozkin <sb...@gmail.com> wrote:
>> So now that we have a passing RI I think it would make sense to start
>> planning a CXF-DOSGi release. I'm wondering what we should do before
>> that...
>> 1. There are some SEVERE 'warnings' coming up, I believe from the
>> Topology Manager. We should probably take a look at those.
>> 2. I once added some Discovery system tests, which I ended up not
>> enabling because of memory issues. I might want to try and get them
>> working on all platforms.
>> 3. Anything else?
>>
>>
> - consolidation of DOSGI RI specific properties. Example, you added a useful
> property called "org.apache.cxf.ws.port" so JAXRS endpoints need to 'catch
> up' with "org.apache.cxf.rs.port".
> Perhaps we can continue adding such 'parallel' properties, but I'm
> wondering, can "org.apache.cxf.ws.port"
> be replaced with "org.apache.cxf.endpoint.port" or
> "org.apache.cxf.http.port" ? Later on, in post 1.2, we can deprecates some
> of other 'duplicate' properties.
Well, the Remote Services Admin spec mandates that the configuration
properties follow a certain pattern. If the configuration type is
called org.apache.cxf.ws then its specific configuration variables
should be called org.apache.cxf.ws.something (see table 122.1 in the
OSGi 4.2 Enterprise Spec http://www.osgi.org/Download/Release4V42).
This is to avoid name clashes when you want to expose a service using
multiple Remote Service implementations that may not be aware of each
other. So to be compliant we have to live with parallel properties.
I do agree on matching up the properties where this makes sense across
org.apache.cxf.ws and org.apache.cxf.rs
> - HTTPS support ? May be a discussion on the dev list can be initiated, a
> solution agreed upon and then someone from the community can step forward
> and work on it ? As a side note, a CXF user has approached me regarding
> fixing a JAXRS Jettison issue in DOSGI 1.1 (default Jettison provider does
> not work in DOSGi 1.1, needs to be fixed for 1.2 too) so I think there are
> experienced and motivated users who can help...
While I agree that this would be great to have, I'm not sure if we
should wait for it to be finished. I'm not aware of anyone working on
this at the moment (please correct me if I'm wrong!). Months of work
have gone in making CXF-DOSGi compliant with the spec and I don't
think we should hold releasing this off until a nice piece of
functionality which hasn't even been started on has been finished.
There's nothing wrong with releasing often, so if this functionality
appears we can do a release again, unless someone is already working
on HTTPS support of course...
Best regards,
David
Re: CXF-DOSGi passing the OSGi Remote Services and Remote Service
Admin CT
Posted by Julien Vey <Ju...@bull.net>.
Le 04/06/2010 14:32, David Bosschaert a écrit :
> Yes, if the configuration type was called org.apache.cxf then the
> configuration for it is allowed to be called org.apache.cxf.something.
>
> I guess I'm wondering whether this is worth the effort though.
> Originally the configuration type was called 'pojo'. When we moved to
> org.apache.cxf.ws we made sure 'pojo' continued to work as
> backward-compatibility measure in case people were using it. I think
> if we move to org.apache.cxf instead of org.apache.cxf.ws we should
> again keep backward compatibility, which in itself means a lot of
> duplication...
>
> Cheers,
>
> David
>
Yes I agree
Maybe would it be better to keep it the way it is for now and introduce
this new configuration for a future major release.
Cheers,
Julien
> On 4 June 2010 13:26, Julien Vey<Ju...@bull.net> wrote:
>
>> Le 04/06/2010 14:20, Sergey Beryozkin a écrit :
>>
>>> Well, actually it does break compliance as the spec says that the
>>>
>>>
>>>
>>>> properties should be called:
>>>> <configuration-type>.something
>>>>
>>>> Given that the configuration type is called org.apache.cxf.ws the
>>>> property should be called org.apache.cxf.ws.<something>
>>>>
>>>> Yeah, I understand that. See, I was trying to explore if we could avoid
>>>>
>>>>
>>> adding the properties which are not specific to a given type, given that
>>> we
>>> are still in an org.apache.cfx space - it's hard to see any practical
>>> negative side-effects...But I'm sorted...
>>>
>>> Generally speaking, I agree the compliance has to be a top priority. But
>>> even RI can benefit from adding extensions.
>>>
>>> thanks, Sergey
>>>
>>>
>> Isn't it possible to call the configuration-type org.apache.cxf
>> and then add a property such as "org.apache.cxf.type = rs | ws"
>>
>> So it would be possible to have properties org.apache.cxf.port,
>> org.apache.cxf.address which wouldn't break compliance
>>
>> Cheers,
>>
>> Julien
>>
>>>
>>>
>>>> Cheers,
>>>>
>>>> David
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: CXF-DOSGi passing the OSGi Remote Services and Remote Service
Admin CT
Posted by David Bosschaert <da...@gmail.com>.
Yes, if the configuration type was called org.apache.cxf then the
configuration for it is allowed to be called org.apache.cxf.something.
I guess I'm wondering whether this is worth the effort though.
Originally the configuration type was called 'pojo'. When we moved to
org.apache.cxf.ws we made sure 'pojo' continued to work as
backward-compatibility measure in case people were using it. I think
if we move to org.apache.cxf instead of org.apache.cxf.ws we should
again keep backward compatibility, which in itself means a lot of
duplication...
Cheers,
David
On 4 June 2010 13:26, Julien Vey <Ju...@bull.net> wrote:
> Le 04/06/2010 14:20, Sergey Beryozkin a écrit :
>>
>> Well, actually it does break compliance as the spec says that the
>>
>>
>>>
>>> properties should be called:
>>> <configuration-type>.something
>>>
>>> Given that the configuration type is called org.apache.cxf.ws the
>>> property should be called org.apache.cxf.ws.<something>
>>>
>>> Yeah, I understand that. See, I was trying to explore if we could avoid
>>>
>>
>> adding the properties which are not specific to a given type, given that
>> we
>> are still in an org.apache.cfx space - it's hard to see any practical
>> negative side-effects...But I'm sorted...
>>
>> Generally speaking, I agree the compliance has to be a top priority. But
>> even RI can benefit from adding extensions.
>>
>> thanks, Sergey
>>
>
> Isn't it possible to call the configuration-type org.apache.cxf
> and then add a property such as "org.apache.cxf.type = rs | ws"
>
> So it would be possible to have properties org.apache.cxf.port,
> org.apache.cxf.address which wouldn't break compliance
>
> Cheers,
>
> Julien
>>
>>
>>>
>>> Cheers,
>>>
>>> David
>>>
>>>
>>
>>
>
>
Re: CXF-DOSGi passing the OSGi Remote Services and Remote Service
Admin CT
Posted by Julien Vey <Ju...@bull.net>.
Le 04/06/2010 14:20, Sergey Beryozkin a écrit :
> Well, actually it does break compliance as the spec says that the
>
>
>> properties should be called:
>> <configuration-type>.something
>>
>> Given that the configuration type is called org.apache.cxf.ws the
>> property should be called org.apache.cxf.ws.<something>
>>
>> Yeah, I understand that. See, I was trying to explore if we could avoid
>>
> adding the properties which are not specific to a given type, given that we
> are still in an org.apache.cfx space - it's hard to see any practical
> negative side-effects...But I'm sorted...
>
> Generally speaking, I agree the compliance has to be a top priority. But
> even RI can benefit from adding extensions.
>
> thanks, Sergey
>
Isn't it possible to call the configuration-type org.apache.cxf
and then add a property such as "org.apache.cxf.type = rs | ws"
So it would be possible to have properties org.apache.cxf.port,
org.apache.cxf.address which wouldn't break compliance
Cheers,
Julien
>
>
>> Cheers,
>>
>> David
>>
>>
>
Re: CXF-DOSGi passing the OSGi Remote Services and Remote Service
Admin CT
Posted by Sergey Beryozkin <sb...@gmail.com>.
Well, actually it does break compliance as the spec says that the
> properties should be called:
> <configuration-type>.something
>
> Given that the configuration type is called org.apache.cxf.ws the
> property should be called org.apache.cxf.ws.<something>
>
> Yeah, I understand that. See, I was trying to explore if we could avoid
adding the properties which are not specific to a given type, given that we
are still in an org.apache.cfx space - it's hard to see any practical
negative side-effects...But I'm sorted...
Generally speaking, I agree the compliance has to be a top priority. But
even RI can benefit from adding extensions.
thanks, Sergey
> Cheers,
>
> David
>
Re: CXF-DOSGi passing the OSGi Remote Services and Remote Service
Admin CT
Posted by David Bosschaert <da...@gmail.com>.
On 4 June 2010 12:55, Sergey Beryozkin <sb...@gmail.com> wrote:
>>>
>
>> >Having some properties in the CXF space "org.apache.cxf" seems to be
>> > totally compliant ? Then they can be 'inherited' by cxf.ws, cxf.rs.
>>
>> Not entirely sure what you mean here, but a 'reverse domain' name is
>> used here to avoid overlap between two technologies that are unaware
>> of each other. Just like in Java Package names. So using just 'cxf.ws'
>> is a shorter but not entirely compliant.
>>
>Well, I just was lazy typing 'org.apache'. Basically what I meant was that
> using a property such
> as 'org.apache.cxf.something' when configuring the service (soap/rest) using
> does not seem like breaking the compliance rules
Well, actually it does break compliance as the spec says that the
properties should be called:
<configuration-type>.something
Given that the configuration type is called org.apache.cxf.ws the
property should be called org.apache.cxf.ws.<something>
Cheers,
David
Re: CXF-DOSGi passing the OSGi Remote Services and Remote Service
Admin CT
Posted by Sergey Beryozkin <sb...@gmail.com>.
>>
> >Having some properties in the CXF space "org.apache.cxf" seems to be
> > totally compliant ? Then they can be 'inherited' by cxf.ws, cxf.rs.
>
> Not entirely sure what you mean here, but a 'reverse domain' name is
> used here to avoid overlap between two technologies that are unaware
> of each other. Just like in Java Package names. So using just 'cxf.ws'
> is a shorter but not entirely compliant.
>
> Well, I just was lazy typing 'org.apache'. Basically what I meant was that
using a property such
as 'org.apache.cxf.something' when configuring the service (soap/rest) using
does not seem like breaking the compliance rules
> >> I do agree on matching up the properties where this makes sense across
> >> org.apache.cxf.ws and org.apache.cxf.rs
> >>
> >> So how would you rename a property like "org.apache.cxf.ws.port" ?
>
> org.apache.cxf.rs.port
>
> That was my concern after all.., was hoping we could stop the
duplication... At the same time perhaps it's not a big issue in the end of
the day, as I mentioned, the number of new properties which will have to be
duplicated which can be added in addition to those which we already have is
very limited
Sergey
David
>
Re: CXF-DOSGi passing the OSGi Remote Services and Remote Service
Admin CT
Posted by David Bosschaert <da...@gmail.com>.
On 3 June 2010 23:42, Sergey Beryozkin <sb...@gmail.com> wrote:
>> >> 3. Anything else?
>> Well, the Remote Services Admin spec mandates that the configuration
>> properties follow a certain pattern. If the configuration type is
>> called org.apache.cxf.ws then its specific configuration variables
>> should be called org.apache.cxf.ws.something (see table 122.1 in the
>> OSGi 4.2 Enterprise Spec http://www.osgi.org/Download/Release4V42).
>> This is to avoid name clashes when you want to expose a service using
>> multiple Remote Service implementations that may not be aware of each
>> other. So to be compliant we have to live with parallel properties.
>>
>Having some properties in the CXF space "org.apache.cxf" seems to be
> totally compliant ? Then they can be 'inherited' by cxf.ws, cxf.rs.
Not entirely sure what you mean here, but a 'reverse domain' name is
used here to avoid overlap between two technologies that are unaware
of each other. Just like in Java Package names. So using just 'cxf.ws'
is a shorter but not entirely compliant.
>> I do agree on matching up the properties where this makes sense across
>> org.apache.cxf.ws and org.apache.cxf.rs
>>
>> So how would you rename a property like "org.apache.cxf.ws.port" ?
org.apache.cxf.rs.port
David
Re: CXF-DOSGi passing the OSGi Remote Services and Remote Service
Admin CT
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi David
On Wed, Jun 2, 2010 at 10:17 PM, David Bosschaert <
david.bosschaert@gmail.com> wrote:
> >>
> >>
> > - consolidation of DOSGI RI specific properties. Example, you added a
> useful
> > property called "org.apache.cxf.ws.port" so JAXRS endpoints need to
> 'catch
> > up' with "org.apache.cxf.rs.port".
> > Perhaps we can continue adding such 'parallel' properties, but I'm
> > wondering, can "org.apache.cxf.ws.port"
> > be replaced with "org.apache.cxf.endpoint.port" or
> > "org.apache.cxf.http.port" ? Later on, in post 1.2, we can deprecates
> some
> > of other 'duplicate' properties.
>
> >> 3. Anything else?
> Well, the Remote Services Admin spec mandates that the configuration
> properties follow a certain pattern. If the configuration type is
> called org.apache.cxf.ws then its specific configuration variables
> should be called org.apache.cxf.ws.something (see table 122.1 in the
> OSGi 4.2 Enterprise Spec http://www.osgi.org/Download/Release4V42).
> This is to avoid name clashes when you want to expose a service using
> multiple Remote Service implementations that may not be aware of each
> other. So to be compliant we have to live with parallel properties.
>
> Having some properties in the CXF space "org.apache.cxf" seems to be
totally compliant ? Then they can be 'inherited' by cxf.ws, cxf.rs.
> I do agree on matching up the properties where this makes sense across
> org.apache.cxf.ws and org.apache.cxf.rs
>
> So how would you rename a property like "org.apache.cxf.ws.port" ?
> > - HTTPS support ? May be a discussion on the dev list can be initiated,
> a
> > solution agreed upon and then someone from the community can step forward
> > and work on it ? As a side note, a CXF user has approached me regarding
> > fixing a JAXRS Jettison issue in DOSGI 1.1 (default Jettison provider
> does
> > not work in DOSGi 1.1, needs to be fixed for 1.2 too) so I think there
> are
> > experienced and motivated users who can help...
>
> While I agree that this would be great to have, I'm not sure if we
> should wait for it to be finished. I'm not aware of anyone working on
> this at the moment (please correct me if I'm wrong!). Months of work
> have gone in making CXF-DOSGi compliant with the spec and I don't
> think we should hold releasing this off until a nice piece of
> functionality which hasn't even been started on has been finished.
> There's nothing wrong with releasing often, so if this functionality
> appears we can do a release again, unless someone is already working
> on HTTPS support of course...
>
>
Sure, it's been a big effort indeed. Perhaps HTTPS can even be implemented
'out of band' by users if needed :
http://wiki.ops4j.org/display/paxweb/SSL+Configuration; future DOSGI
releases may support it at the intents level
thanks, Sergey
> Best regards,
>
> David
>