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/05/12 18:40:28 UTC
CXF-DOSGi passing the OSGi Remote Services and Remote Service Admin
CT
Hi all,
Earlier this week the OSGi Alliance has approved the OSGi 4.2
Enterprise Conformance Tests and Reference Implementations. The
CXF-DOSGi project [1] is the Reference Implementation for the
following OSGi 4.2 specs [2]:
* Chapter 13 - Remote Services
This spec describes Distributed OSGi from a user's point of view. It
standardizes the properties that can be put on an OSGi service to make
it available remotely and how a consumer can find out whether it's
dealing with a local service or a remote one.
* Chapter 122 - Remote Services Admin
This spec standardizes the interfaces between internal components
Remote Services implementations typically have. A Distribution
Provider, Topology Manager and Discovery System. This makes it
possible to mix&match these components from various implementations.
For more information see slides 6-8 at [3].
Many kudos to Marc Schaaf as he did a lot of the recent RI work.
Also many kudos to Tim Diekmann from TIBCO who wrote the actual CT
tests despite his busy schedule.
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?
Best regards,
David
[1] http://cxf.apache.org/distributed-osgi.html
[2] http://www.osgi.org/Download/Release4V42
[3] http://www.slideshare.net/bosschaert/whats-newinos-gi42enterprise
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
>
Re: CXF-DOSGi passing the OSGi Remote Services and Remote Service
Admin CT
Posted by David Bosschaert <da...@gmail.com>.
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 David Bosschaert <da...@gmail.com>.
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 Sergey Beryozkin <sb...@gmail.com>.
Hi
On Wed, May 12, 2010 at 5:40 PM, David Bosschaert <
david.bosschaert@gmail.com> wrote:
> Hi all,
>
> Earlier this week the OSGi Alliance has approved the OSGi 4.2
> Enterprise Conformance Tests and Reference Implementations. The
> CXF-DOSGi project [1] is the Reference Implementation for the
> following OSGi 4.2 specs [2]:
>
> * Chapter 13 - Remote Services
> This spec describes Distributed OSGi from a user's point of view. It
> standardizes the properties that can be put on an OSGi service to make
> it available remotely and how a consumer can find out whether it's
> dealing with a local service or a remote one.
>
> * Chapter 122 - Remote Services Admin
> This spec standardizes the interfaces between internal components
> Remote Services implementations typically have. A Distribution
> Provider, Topology Manager and Discovery System. This makes it
> possible to mix&match these components from various implementations.
> For more information see slides 6-8 at [3].
>
> Many kudos to Marc Schaaf as he did a lot of the recent RI work.
> Also many kudos to Tim Diekmann from TIBCO who wrote the actual CT
> tests despite his busy schedule.
>
> congrats to you all
> 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.
- 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...
cheers, Sergey
> Best regards,
>
> David
>
> [1] http://cxf.apache.org/distributed-osgi.html
> [2] http://www.osgi.org/Download/Release4V42
> [3] http://www.slideshare.net/bosschaert/whats-newinos-gi42enterprise
>
Re: CXF-DOSGi passing the OSGi Remote Services and Remote Service
Admin CT
Posted by David Bosschaert <da...@gmail.com>.
On 11 June 2010 16:53, David Bosschaert <da...@gmail.com> wrote:
> * Make sure all the demos work (and update the docs) - this is
> something I would be happy to help out with.
I went through all the demos this morning and made a few small updates
so that they all work again. I also updated the demo documentation
alongside and updated the installation instructions in the docs to use
Felix 3.0.1 and Equinox 3.6.
I'm not completely finished with all the docs as the URLs need to be
updated to point to the 1.2 release once its out.
I also applied Juliens patch for DOSGI-62.
I didn't apply DOSGI-72 yet as it was missing unit tests. Hopefully
Julien can provide some coverage :)
Best regards,
David
Re: CXF-DOSGi passing the OSGi Remote Services and Remote Service
Admin CT
Posted by David Bosschaert <da...@gmail.com>.
Hi Julien,
I will have a look at your patches.
David
On 25 June 2010 13:58, Julien Vey <Ju...@bull.net> wrote:
>
>>> Tasks left would be:
>>> * When the above is done, cut the actual release candidate(s).
>>>
>>
>> I can help cutting the release when you're ready to go.
>>
>
> Is it possible to review and apply (if they are acceptable) DOSGI-62 and
> DOSGI-72 patches before the next release ?
>
> Cheers,
>
> Julien
>>
>> Cheers,
>> Eoghan
>>
>>
>> On 11 June 2010 16:53, David Bosschaert<da...@gmail.com>
>> wrote:
>>
>>
>>>
>>> Great, thanks Marc!
>>>
>>> I think we're getting close to something that is releasable.
>>>
>>> Tasks left would be:
>>> * Add a configuration item org.apache.cxf.rs.port. Sergey is this
>>> something that you might have time for? Or maybe we can do this
>>> together?
>>> * Make sure all the demos work (and update the docs) - this is
>>> something I would be happy to help out with.
>>> * When the above is done, cut the actual release candidate(s).
>>>
>>> Cheers,
>>>
>>> David
>>>
>>> On 11 June 2010 15:32, Marc Schaaf<ma...@marc-schaaf.de> wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> I just committed some changes which remove the "severe" messages that
>>>> where produced during the normal operation of the Topology Manager. Two
>>>> of them where obsolete by now and one concerned some missing
>>>> functionality of the Topology Manager that I've now added. This
>>>> concerned in particular the behaviour of the Topology Manager regarding
>>>> the import of services when the DSW is detected/added after the service
>>>> to be imported was found which is supported now.
>>>>
>>>> Cheers,
>>>> Marc
>>>>
>>>> On 05/12/2010 06:40 PM, David Bosschaert wrote:
>>>>
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Earlier this week the OSGi Alliance has approved the OSGi 4.2
>>>>> Enterprise Conformance Tests and Reference Implementations. The
>>>>> CXF-DOSGi project [1] is the Reference Implementation for the
>>>>> following OSGi 4.2 specs [2]:
>>>>>
>>>>> * Chapter 13 - Remote Services
>>>>> This spec describes Distributed OSGi from a user's point of view. It
>>>>> standardizes the properties that can be put on an OSGi service to make
>>>>> it available remotely and how a consumer can find out whether it's
>>>>> dealing with a local service or a remote one.
>>>>>
>>>>> * Chapter 122 - Remote Services Admin
>>>>> This spec standardizes the interfaces between internal components
>>>>> Remote Services implementations typically have. A Distribution
>>>>> Provider, Topology Manager and Discovery System. This makes it
>>>>> possible to mix&match these components from various implementations.
>>>>> For more information see slides 6-8 at [3].
>>>>>
>>>>> Many kudos to Marc Schaaf as he did a lot of the recent RI work.
>>>>> Also many kudos to Tim Diekmann from TIBCO who wrote the actual CT
>>>>> tests despite his busy schedule.
>>>>>
>>>>> 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?
>>>>>
>>>>> Best regards,
>>>>>
>>>>> David
>>>>>
>>>>> [1] http://cxf.apache.org/distributed-osgi.html
>>>>> [2] http://www.osgi.org/Download/Release4V42
>>>>> [3] http://www.slideshare.net/bosschaert/whats-newinos-gi42enterprise
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: CXF-DOSGi passing the OSGi Remote Services and Remote Service
Admin CT
Posted by Julien Vey <Ju...@bull.net>.
>> Tasks left would be:
>> * When the above is done, cut the actual release candidate(s).
>>
> I can help cutting the release when you're ready to go.
>
Is it possible to review and apply (if they are acceptable) DOSGI-62 and
DOSGI-72 patches before the next release ?
Cheers,
Julien
> Cheers,
> Eoghan
>
>
> On 11 June 2010 16:53, David Bosschaert<da...@gmail.com> wrote:
>
>
>> Great, thanks Marc!
>>
>> I think we're getting close to something that is releasable.
>>
>> Tasks left would be:
>> * Add a configuration item org.apache.cxf.rs.port. Sergey is this
>> something that you might have time for? Or maybe we can do this
>> together?
>> * Make sure all the demos work (and update the docs) - this is
>> something I would be happy to help out with.
>> * When the above is done, cut the actual release candidate(s).
>>
>> Cheers,
>>
>> David
>>
>> On 11 June 2010 15:32, Marc Schaaf<ma...@marc-schaaf.de> wrote:
>>
>>> Hi,
>>>
>>> I just committed some changes which remove the "severe" messages that
>>> where produced during the normal operation of the Topology Manager. Two
>>> of them where obsolete by now and one concerned some missing
>>> functionality of the Topology Manager that I've now added. This
>>> concerned in particular the behaviour of the Topology Manager regarding
>>> the import of services when the DSW is detected/added after the service
>>> to be imported was found which is supported now.
>>>
>>> Cheers,
>>> Marc
>>>
>>> On 05/12/2010 06:40 PM, David Bosschaert wrote:
>>>
>>>> Hi all,
>>>>
>>>> Earlier this week the OSGi Alliance has approved the OSGi 4.2
>>>> Enterprise Conformance Tests and Reference Implementations. The
>>>> CXF-DOSGi project [1] is the Reference Implementation for the
>>>> following OSGi 4.2 specs [2]:
>>>>
>>>> * Chapter 13 - Remote Services
>>>> This spec describes Distributed OSGi from a user's point of view. It
>>>> standardizes the properties that can be put on an OSGi service to make
>>>> it available remotely and how a consumer can find out whether it's
>>>> dealing with a local service or a remote one.
>>>>
>>>> * Chapter 122 - Remote Services Admin
>>>> This spec standardizes the interfaces between internal components
>>>> Remote Services implementations typically have. A Distribution
>>>> Provider, Topology Manager and Discovery System. This makes it
>>>> possible to mix&match these components from various implementations.
>>>> For more information see slides 6-8 at [3].
>>>>
>>>> Many kudos to Marc Schaaf as he did a lot of the recent RI work.
>>>> Also many kudos to Tim Diekmann from TIBCO who wrote the actual CT
>>>> tests despite his busy schedule.
>>>>
>>>> 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?
>>>>
>>>> Best regards,
>>>>
>>>> David
>>>>
>>>> [1] http://cxf.apache.org/distributed-osgi.html
>>>> [2] http://www.osgi.org/Download/Release4V42
>>>> [3] http://www.slideshare.net/bosschaert/whats-newinos-gi42enterprise
>>>>
>>>>
>>>
>>>
>>
>
Re: CXF-DOSGi passing the OSGi Remote Services and Remote Service
Admin CT
Posted by Eoghan Glynn <eo...@gmail.com>.
> Tasks left would be:
> * When the above is done, cut the actual release candidate(s).
I can help cutting the release when you're ready to go.
Cheers,
Eoghan
On 11 June 2010 16:53, David Bosschaert <da...@gmail.com> wrote:
> Great, thanks Marc!
>
> I think we're getting close to something that is releasable.
>
> Tasks left would be:
> * Add a configuration item org.apache.cxf.rs.port. Sergey is this
> something that you might have time for? Or maybe we can do this
> together?
> * Make sure all the demos work (and update the docs) - this is
> something I would be happy to help out with.
> * When the above is done, cut the actual release candidate(s).
>
> Cheers,
>
> David
>
> On 11 June 2010 15:32, Marc Schaaf <ma...@marc-schaaf.de> wrote:
> > Hi,
> >
> > I just committed some changes which remove the "severe" messages that
> > where produced during the normal operation of the Topology Manager. Two
> > of them where obsolete by now and one concerned some missing
> > functionality of the Topology Manager that I've now added. This
> > concerned in particular the behaviour of the Topology Manager regarding
> > the import of services when the DSW is detected/added after the service
> > to be imported was found which is supported now.
> >
> > Cheers,
> > Marc
> >
> > On 05/12/2010 06:40 PM, David Bosschaert wrote:
> >> Hi all,
> >>
> >> Earlier this week the OSGi Alliance has approved the OSGi 4.2
> >> Enterprise Conformance Tests and Reference Implementations. The
> >> CXF-DOSGi project [1] is the Reference Implementation for the
> >> following OSGi 4.2 specs [2]:
> >>
> >> * Chapter 13 - Remote Services
> >> This spec describes Distributed OSGi from a user's point of view. It
> >> standardizes the properties that can be put on an OSGi service to make
> >> it available remotely and how a consumer can find out whether it's
> >> dealing with a local service or a remote one.
> >>
> >> * Chapter 122 - Remote Services Admin
> >> This spec standardizes the interfaces between internal components
> >> Remote Services implementations typically have. A Distribution
> >> Provider, Topology Manager and Discovery System. This makes it
> >> possible to mix&match these components from various implementations.
> >> For more information see slides 6-8 at [3].
> >>
> >> Many kudos to Marc Schaaf as he did a lot of the recent RI work.
> >> Also many kudos to Tim Diekmann from TIBCO who wrote the actual CT
> >> tests despite his busy schedule.
> >>
> >> 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?
> >>
> >> Best regards,
> >>
> >> David
> >>
> >> [1] http://cxf.apache.org/distributed-osgi.html
> >> [2] http://www.osgi.org/Download/Release4V42
> >> [3] http://www.slideshare.net/bosschaert/whats-newinos-gi42enterprise
> >>
> >
> >
>
Re: CXF-DOSGi passing the OSGi Remote Services and Remote Service
Admin CT
Posted by Marc Schaaf <ma...@marc-schaaf.de>.
Hi Fabio,
I have removed the irritating log message from this method so it is
fixed ;-)
Cheers
Marc
On 06/12/2010 12:17 AM, Fabio souza wrote:
> Hi Marc and David,
>
> First of all, congratulations!!! Recently, I have decided to study cxf dosgi
> and I have downloaded v1.2 of the source code and built it. While testing, I
> saw one of those SEVERE messages in the screen. That happened when I
> unregistered a service that was exported. I saw that the problem was in
> method removeExportReference of the TopologyManager, and I made some small
> modifications to make it work. Could you tell me if this method was fixed?
> Thank you very much!
>
> Best regards,
>
> Fabio
>
> On Fri, Jun 11, 2010 at 12:53 PM, David Bosschaert <
> david.bosschaert@gmail.com> wrote:
>
>
>> Great, thanks Marc!
>>
>> I think we're getting close to something that is releasable.
>>
>> Tasks left would be:
>> * Add a configuration item org.apache.cxf.rs.port. Sergey is this
>> something that you might have time for? Or maybe we can do this
>> together?
>> * Make sure all the demos work (and update the docs) - this is
>> something I would be happy to help out with.
>> * When the above is done, cut the actual release candidate(s).
>>
>> Cheers,
>>
>> David
>>
>> On 11 June 2010 15:32, Marc Schaaf <ma...@marc-schaaf.de> wrote:
>>
>>> Hi,
>>>
>>> I just committed some changes which remove the "severe" messages that
>>> where produced during the normal operation of the Topology Manager. Two
>>> of them where obsolete by now and one concerned some missing
>>> functionality of the Topology Manager that I've now added. This
>>> concerned in particular the behaviour of the Topology Manager regarding
>>> the import of services when the DSW is detected/added after the service
>>> to be imported was found which is supported now.
>>>
>>> Cheers,
>>> Marc
>>>
>>> On 05/12/2010 06:40 PM, David Bosschaert wrote:
>>>
>>>> Hi all,
>>>>
>>>> Earlier this week the OSGi Alliance has approved the OSGi 4.2
>>>> Enterprise Conformance Tests and Reference Implementations. The
>>>> CXF-DOSGi project [1] is the Reference Implementation for the
>>>> following OSGi 4.2 specs [2]:
>>>>
>>>> * Chapter 13 - Remote Services
>>>> This spec describes Distributed OSGi from a user's point of view. It
>>>> standardizes the properties that can be put on an OSGi service to make
>>>> it available remotely and how a consumer can find out whether it's
>>>> dealing with a local service or a remote one.
>>>>
>>>> * Chapter 122 - Remote Services Admin
>>>> This spec standardizes the interfaces between internal components
>>>> Remote Services implementations typically have. A Distribution
>>>> Provider, Topology Manager and Discovery System. This makes it
>>>> possible to mix&match these components from various implementations.
>>>> For more information see slides 6-8 at [3].
>>>>
>>>> Many kudos to Marc Schaaf as he did a lot of the recent RI work.
>>>> Also many kudos to Tim Diekmann from TIBCO who wrote the actual CT
>>>> tests despite his busy schedule.
>>>>
>>>> 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?
>>>>
>>>> Best regards,
>>>>
>>>> David
>>>>
>>>> [1] http://cxf.apache.org/distributed-osgi.html
>>>> [2] http://www.osgi.org/Download/Release4V42
>>>> [3] http://www.slideshare.net/bosschaert/whats-newinos-gi42enterprise
>>>>
>>>>
>>>
>>>
>>
>
>
>
Re: CXF-DOSGi passing the OSGi Remote Services and Remote Service
Admin CT
Posted by Fabio souza <fa...@gmail.com>.
Hi Marc and David,
First of all, congratulations!!! Recently, I have decided to study cxf dosgi
and I have downloaded v1.2 of the source code and built it. While testing, I
saw one of those SEVERE messages in the screen. That happened when I
unregistered a service that was exported. I saw that the problem was in
method removeExportReference of the TopologyManager, and I made some small
modifications to make it work. Could you tell me if this method was fixed?
Thank you very much!
Best regards,
Fabio
On Fri, Jun 11, 2010 at 12:53 PM, David Bosschaert <
david.bosschaert@gmail.com> wrote:
> Great, thanks Marc!
>
> I think we're getting close to something that is releasable.
>
> Tasks left would be:
> * Add a configuration item org.apache.cxf.rs.port. Sergey is this
> something that you might have time for? Or maybe we can do this
> together?
> * Make sure all the demos work (and update the docs) - this is
> something I would be happy to help out with.
> * When the above is done, cut the actual release candidate(s).
>
> Cheers,
>
> David
>
> On 11 June 2010 15:32, Marc Schaaf <ma...@marc-schaaf.de> wrote:
> > Hi,
> >
> > I just committed some changes which remove the "severe" messages that
> > where produced during the normal operation of the Topology Manager. Two
> > of them where obsolete by now and one concerned some missing
> > functionality of the Topology Manager that I've now added. This
> > concerned in particular the behaviour of the Topology Manager regarding
> > the import of services when the DSW is detected/added after the service
> > to be imported was found which is supported now.
> >
> > Cheers,
> > Marc
> >
> > On 05/12/2010 06:40 PM, David Bosschaert wrote:
> >> Hi all,
> >>
> >> Earlier this week the OSGi Alliance has approved the OSGi 4.2
> >> Enterprise Conformance Tests and Reference Implementations. The
> >> CXF-DOSGi project [1] is the Reference Implementation for the
> >> following OSGi 4.2 specs [2]:
> >>
> >> * Chapter 13 - Remote Services
> >> This spec describes Distributed OSGi from a user's point of view. It
> >> standardizes the properties that can be put on an OSGi service to make
> >> it available remotely and how a consumer can find out whether it's
> >> dealing with a local service or a remote one.
> >>
> >> * Chapter 122 - Remote Services Admin
> >> This spec standardizes the interfaces between internal components
> >> Remote Services implementations typically have. A Distribution
> >> Provider, Topology Manager and Discovery System. This makes it
> >> possible to mix&match these components from various implementations.
> >> For more information see slides 6-8 at [3].
> >>
> >> Many kudos to Marc Schaaf as he did a lot of the recent RI work.
> >> Also many kudos to Tim Diekmann from TIBCO who wrote the actual CT
> >> tests despite his busy schedule.
> >>
> >> 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?
> >>
> >> Best regards,
> >>
> >> David
> >>
> >> [1] http://cxf.apache.org/distributed-osgi.html
> >> [2] http://www.osgi.org/Download/Release4V42
> >> [3] http://www.slideshare.net/bosschaert/whats-newinos-gi42enterprise
> >>
> >
> >
>
--
Fábio
Re: CXF-DOSGi passing the OSGi Remote Services and Remote Service
Admin CT
Posted by David Bosschaert <da...@gmail.com>.
Great, thanks Marc!
I think we're getting close to something that is releasable.
Tasks left would be:
* Add a configuration item org.apache.cxf.rs.port. Sergey is this
something that you might have time for? Or maybe we can do this
together?
* Make sure all the demos work (and update the docs) - this is
something I would be happy to help out with.
* When the above is done, cut the actual release candidate(s).
Cheers,
David
On 11 June 2010 15:32, Marc Schaaf <ma...@marc-schaaf.de> wrote:
> Hi,
>
> I just committed some changes which remove the "severe" messages that
> where produced during the normal operation of the Topology Manager. Two
> of them where obsolete by now and one concerned some missing
> functionality of the Topology Manager that I've now added. This
> concerned in particular the behaviour of the Topology Manager regarding
> the import of services when the DSW is detected/added after the service
> to be imported was found which is supported now.
>
> Cheers,
> Marc
>
> On 05/12/2010 06:40 PM, David Bosschaert wrote:
>> Hi all,
>>
>> Earlier this week the OSGi Alliance has approved the OSGi 4.2
>> Enterprise Conformance Tests and Reference Implementations. The
>> CXF-DOSGi project [1] is the Reference Implementation for the
>> following OSGi 4.2 specs [2]:
>>
>> * Chapter 13 - Remote Services
>> This spec describes Distributed OSGi from a user's point of view. It
>> standardizes the properties that can be put on an OSGi service to make
>> it available remotely and how a consumer can find out whether it's
>> dealing with a local service or a remote one.
>>
>> * Chapter 122 - Remote Services Admin
>> This spec standardizes the interfaces between internal components
>> Remote Services implementations typically have. A Distribution
>> Provider, Topology Manager and Discovery System. This makes it
>> possible to mix&match these components from various implementations.
>> For more information see slides 6-8 at [3].
>>
>> Many kudos to Marc Schaaf as he did a lot of the recent RI work.
>> Also many kudos to Tim Diekmann from TIBCO who wrote the actual CT
>> tests despite his busy schedule.
>>
>> 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?
>>
>> Best regards,
>>
>> David
>>
>> [1] http://cxf.apache.org/distributed-osgi.html
>> [2] http://www.osgi.org/Download/Release4V42
>> [3] http://www.slideshare.net/bosschaert/whats-newinos-gi42enterprise
>>
>
>
Re: CXF-DOSGi passing the OSGi Remote Services and Remote Service
Admin CT
Posted by Marc Schaaf <ma...@marc-schaaf.de>.
Hi,
I just committed some changes which remove the "severe" messages that
where produced during the normal operation of the Topology Manager. Two
of them where obsolete by now and one concerned some missing
functionality of the Topology Manager that I've now added. This
concerned in particular the behaviour of the Topology Manager regarding
the import of services when the DSW is detected/added after the service
to be imported was found which is supported now.
Cheers,
Marc
On 05/12/2010 06:40 PM, David Bosschaert wrote:
> Hi all,
>
> Earlier this week the OSGi Alliance has approved the OSGi 4.2
> Enterprise Conformance Tests and Reference Implementations. The
> CXF-DOSGi project [1] is the Reference Implementation for the
> following OSGi 4.2 specs [2]:
>
> * Chapter 13 - Remote Services
> This spec describes Distributed OSGi from a user's point of view. It
> standardizes the properties that can be put on an OSGi service to make
> it available remotely and how a consumer can find out whether it's
> dealing with a local service or a remote one.
>
> * Chapter 122 - Remote Services Admin
> This spec standardizes the interfaces between internal components
> Remote Services implementations typically have. A Distribution
> Provider, Topology Manager and Discovery System. This makes it
> possible to mix&match these components from various implementations.
> For more information see slides 6-8 at [3].
>
> Many kudos to Marc Schaaf as he did a lot of the recent RI work.
> Also many kudos to Tim Diekmann from TIBCO who wrote the actual CT
> tests despite his busy schedule.
>
> 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?
>
> Best regards,
>
> David
>
> [1] http://cxf.apache.org/distributed-osgi.html
> [2] http://www.osgi.org/Download/Release4V42
> [3] http://www.slideshare.net/bosschaert/whats-newinos-gi42enterprise
>
Re: CXF-DOSGi passing the OSGi Remote Services and Remote Service
Admin CT
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On Wed, May 12, 2010 at 5:40 PM, David Bosschaert <
david.bosschaert@gmail.com> wrote:
> Hi all,
>
> Earlier this week the OSGi Alliance has approved the OSGi 4.2
> Enterprise Conformance Tests and Reference Implementations. The
> CXF-DOSGi project [1] is the Reference Implementation for the
> following OSGi 4.2 specs [2]:
>
> * Chapter 13 - Remote Services
> This spec describes Distributed OSGi from a user's point of view. It
> standardizes the properties that can be put on an OSGi service to make
> it available remotely and how a consumer can find out whether it's
> dealing with a local service or a remote one.
>
> * Chapter 122 - Remote Services Admin
> This spec standardizes the interfaces between internal components
> Remote Services implementations typically have. A Distribution
> Provider, Topology Manager and Discovery System. This makes it
> possible to mix&match these components from various implementations.
> For more information see slides 6-8 at [3].
>
> Many kudos to Marc Schaaf as he did a lot of the recent RI work.
> Also many kudos to Tim Diekmann from TIBCO who wrote the actual CT
> tests despite his busy schedule.
>
> congrats to you all
> 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.
- 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...
cheers, Sergey
> Best regards,
>
> David
>
> [1] http://cxf.apache.org/distributed-osgi.html
> [2] http://www.osgi.org/Download/Release4V42
> [3] http://www.slideshare.net/bosschaert/whats-newinos-gi42enterprise
>