from:"Eoghan Glynn"

[RESULT][VOTE] Release CXF dOSGi 1.2

2010-07-25 Thread Eoghan Glynn

Folks,

I'm going to declare this vote as passed, with the following votes cast:

+1: Sean O'Callaghan, Sergey Beryozkin, David Bosschaert, Marc Schaaf, Jeff
Genender, Dan Kulp, Eoghan Glynn

I've promoted the artifacts to central and copied the distributions to the
cxf/dosgi/dist directory.

Cheers,
Eoghan

[VOTE] Release CXF dOSGi 1.2 - Take 2

2010-07-20 Thread Eoghan Glynn

Folks,

Now that the release notes are all fixed up, I'm calling a second vote to
release
CXF Distributed OSGi 1.2.

The release notes contain a description of new features and bugs fixed
in this release:


http://svn.apache.org/repos/asf/cxf/dosgi/trunk/distribution/sources/src/main/release/release_notes.txt

The new staging area is:

 https://repository.apache.org/content/repositories/orgapachecxf-025

The various distributions can be downloaded as follows:

  - Source:
https://repository.apache.org/content/repositories/orgapachecxf-025/org/apache/cxf/dosgi/cxf-dosgi-ri-source-distribution/1.2
  - Multi-bundle:
https://repository.apache.org/content/repositories/orgapachecxf-025/org/apache/cxf/dosgi/cxf-dosgi-ri-multibundle-distribution/1.2
  - Single-bundle:
https://repository.apache.org/content/repositories/orgapachecxf-025/org/apache/cxf/dosgi/cxf-dosgi-ri-singlebundle-distribution/1.2

This release is tagged with cxf-dosgi-ri-1.2 at:

 http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.2

The vote will remain open for at least 72 hours.

Please consider this call to vote as my +1.

Cheers,
Eoghan

Re: [VOTE] Release CXF dOSGi 1.2

2010-07-20 Thread Eoghan Glynn

Folks,

I'm pulling this release after noticing that the release notes in the
multi-bundle distro weren't updated for 1.2.

I'll cut a take-two and call another vote later on today.

Cheers,
Eoghan

On 20 July 2010 08:42, Eoghan Glynn  wrote:

>
> Here's the raw text with the link formatting removed:
>
>
>
> Folks,
>
> I'm calling a vote to release CXF Distributed OSGi 1.2.
>
> In addition to providing the Reference Implementation to the OSGi Remote
> Services Specification, the CXF Distributed OSGi 1.2 release now also
> provides the Reference Implementation of the OSGi Remote Service Admin
> Specification version 1.0, Chapter 122 in the OSGi Enterprise
> Specification[1].
>
> The release notes contain a description of new features in this release:
>
>
> http://svn.apache.org/repos/asf/cxf/dosgi/trunk/distribution/sources/src/main/release/release_notes.txt
>
> The staging area is at:
>
>   https://repository.apache.org/content/repositories/orgapachecxf-023
>
> The various distributions can be downloaded as follows:
>
>   -   Source:
> https://repository.apache.org/content/repositories/orgapachecxf-023/org/apache/cxf/dosgi/cxf-dosgi-ri-source-distribution/1.2
>   -   Multi-bundle:
> https://repository.apache.org/content/repositories/orgapachecxf-023/org/apache/cxf/dosgi/cxf-dosgi-ri-multibundle-distribution/1.2
>   -   Single-bundle:
> https://repository.apache.org/content/repositories/orgapachecxf-023/org/apache/cxf/dosgi/cxf-dosgi-ri-singlebundle-distribution/1.2
>
>
> This release is tagged with cxf-dosgi-ri-1.2 at:
>
>   http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.2
>
> The vote will remain open for at least 72 hours.
>
> Please consider this call to vote as my +1.
>
> Cheers,
> Eoghan
>
> [1] http://www.osgi.org/Download/Release4V42
>
>
>
> On 20 July 2010 07:43, David Bosschaert wrote:
>
>> Hi Eoghan,
>>
>> The mail that you sent around contains two links for every artefact,
>> one pointing at orgapachecxf-023 which I presume is the right one and
>> another pointing at orgapachecxf-021 which I don't think is the right
>> one :)
>> Also tags to both 1.1 and 1.2 are in there...
>>
>> Cheers,
>>
>> David
>>
>> On 19 July 2010 23:45, Eoghan Glynn  wrote:
>> > Folks,
>> >
>> > I'm calling a vote to release CXF Distributed OSGi 1.2.
>> >
>> > In addition to providing the Reference Implementation to the OSGi Remote
>> > Services Specification, the CXF Distributed OSGi 1.2 release now also
>> > provides the Reference Implementation of the OSGi Remote Service Admin
>> > Specification version 1.0, Chapter 122 in the OSGi Enterprise
>> > Specification[1].
>> >
>> > The release notes contain a description of new features in this release:
>> >
>> >
>> >
>> http://svn.apache.org/repos/asf/cxf/dosgi/trunk/distribution/sources/src/main/release/release_notes.txt
>> >
>> > The staging area is at:
>> >
>> >  https://repository.apache.org/content/repositories/orgapachecxf-023<
>> https://repository.apache.org/content/repositories/orgapachecxf-021>
>> >
>> > The various distributions can be downloaded as follows:
>> >
>> >   -   *Source:*
>> >
>> https://repository.apache.org/content/repositories/orgapachecxf-023/org/apache/cxf/dosgi/cxf-dosgi-ri-source-distribution/1.2
>> <
>> https://repository.apache.org/content/repositories/orgapachecxf-021/org/apache/cxf/dosgi/cxf-dosgi-ri-source-distribution/1.1
>> >
>> >   -   *Multi-bundle:*
>> >
>> https://repository.apache.org/content/repositories/orgapachecxf-023/org/apache/cxf/dosgi/cxf-dosgi-ri-multibundle-distribution/1.2
>> <
>> https://repository.apache.org/content/repositories/orgapachecxf-021/org/apache/cxf/dosgi/cxf-dosgi-ri-multibundle-distribution/1.1
>> >
>> >   -   *Single-bundle:*
>> >
>> https://repository.apache.org/content/repositories/orgapachecxf-023/org/apache/cxf/dosgi/cxf-dosgi-ri-singlebundle-distribution/1.2
>> <
>> https://repository.apache.org/content/repositories/orgapachecxf-021/org/apache/cxf/dosgi/cxf-dosgi-ri-singlebundle-distribution/1.1
>> >
>> >
>> > This release is tagged with cxf-dosgi-ri-1.2 at:
>> >
>> >  http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.2<
>> http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.1>
>> >
>> > The vote will remain open for at least 72 hours.
>> >
>> > Please consider this call to vote as my +1.
>> >
>> > Cheers,
>> > Eoghan
>> >
>> > [1] http://www.osgi.org/Download/Release4V42
>> >
>>
>
>

Re: [VOTE] Release CXF dOSGi 1.2

2010-07-20 Thread Eoghan Glynn

Hi Sergey,

Do you want that info added to the release notes?

Cheers,
Eoghan

On 20 July 2010 10:09, Sergey Beryozkin  wrote:

> +1
>
> Josh Holtzman has also contributed the code for supporting the (security)
> filters; CXF 2.2.9 also gives the DOSGI users the uniform support for
> @In/OutInterceptors and @Feature annotations
>
> thanks, Sergey
>
> On Tue, Jul 20, 2010 at 9:16 AM, David Bosschaert <
> david.bosscha...@gmail.com> wrote:
>
> > Thanks, Eoghan.
> >
> > I've verified the artifacts with the greeter and discovery demos and
> > it works fine.
> >
> > Here's my +1
> >
> > David
> >
> > On 20 July 2010 08:42, Eoghan Glynn  wrote:
> > > Here's the raw text with the link formatting removed:
> > >
> > >
> > > Folks,
> > >
> > > I'm calling a vote to release CXF Distributed OSGi 1.2.
> > >
> > > In addition to providing the Reference Implementation to the OSGi
> Remote
> > > Services Specification, the CXF Distributed OSGi 1.2 release now also
> > > provides the Reference Implementation of the OSGi Remote Service Admin
> > > Specification version 1.0, Chapter 122 in the OSGi Enterprise
> > > Specification[1].
> > >
> > > The release notes contain a description of new features in this
> release:
> > >
> > >
> > >
> >
> http://svn.apache.org/repos/asf/cxf/dosgi/trunk/distribution/sources/src/main/release/release_notes.txt
> > >
> > > The staging area is at:
> > >
> > >  https://repository.apache.org/content/repositories/orgapachecxf-023
> > >
> > > The various distributions can be downloaded as follows:
> > >
> > >  -   Source:
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecxf-023/org/apache/cxf/dosgi/cxf-dosgi-ri-source-distribution/1.2
> > >  -   Multi-bundle:
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecxf-023/org/apache/cxf/dosgi/cxf-dosgi-ri-multibundle-distribution/1.2
> > >  -   Single-bundle:
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecxf-023/org/apache/cxf/dosgi/cxf-dosgi-ri-singlebundle-distribution/1.2
> > >
> > > This release is tagged with cxf-dosgi-ri-1.2 at:
> > >
> > >  http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.2
> > >
> > > The vote will remain open for at least 72 hours.
> > >
> > > Please consider this call to vote as my +1.
> > >
> > > Cheers,
> > > Eoghan
> > >
> > > [1] http://www.osgi.org/Download/Release4V42
> > >
> > >
> > >
> > > On 20 July 2010 07:43, David Bosschaert 
> > wrote:
> > >
> > >> Hi Eoghan,
> > >>
> > >> The mail that you sent around contains two links for every artefact,
> > >> one pointing at orgapachecxf-023 which I presume is the right one and
> > >> another pointing at orgapachecxf-021 which I don't think is the right
> > >> one :)
> > >> Also tags to both 1.1 and 1.2 are in there...
> > >>
> > >> Cheers,
> > >>
> > >> David
> > >>
> > >> On 19 July 2010 23:45, Eoghan Glynn  wrote:
> > >> > Folks,
> > >> >
> > >> > I'm calling a vote to release CXF Distributed OSGi 1.2.
> > >> >
> > >> > In addition to providing the Reference Implementation to the OSGi
> > Remote
> > >> > Services Specification, the CXF Distributed OSGi 1.2 release now
> also
> > >> > provides the Reference Implementation of the OSGi Remote Service
> Admin
> > >> > Specification version 1.0, Chapter 122 in the OSGi Enterprise
> > >> > Specification[1].
> > >> >
> > >> > The release notes contain a description of new features in this
> > release:
> > >> >
> > >> >
> > >> >
> > >>
> >
> http://svn.apache.org/repos/asf/cxf/dosgi/trunk/distribution/sources/src/main/release/release_notes.txt
> > >> >
> > >> > The staging area is at:
> > >> >
> > >> >
> https://repository.apache.org/content/repositories/orgapachecxf-023<
> > >> https://repository.apache.org/content/repositories/orgapachecxf-021>
> > >> >
> > >> > The various distributions can be downloaded as follows:
> > >> >

Re: [VOTE] Release CXF dOSGi 1.2

2010-07-20 Thread Eoghan Glynn

Here's the raw text with the link formatting removed:


Folks,

I'm calling a vote to release CXF Distributed OSGi 1.2.

In addition to providing the Reference Implementation to the OSGi Remote
Services Specification, the CXF Distributed OSGi 1.2 release now also
provides the Reference Implementation of the OSGi Remote Service Admin
Specification version 1.0, Chapter 122 in the OSGi Enterprise
Specification[1].

The release notes contain a description of new features in this release:


http://svn.apache.org/repos/asf/cxf/dosgi/trunk/distribution/sources/src/main/release/release_notes.txt

The staging area is at:

  https://repository.apache.org/content/repositories/orgapachecxf-023

The various distributions can be downloaded as follows:

  -   Source:
https://repository.apache.org/content/repositories/orgapachecxf-023/org/apache/cxf/dosgi/cxf-dosgi-ri-source-distribution/1.2
  -   Multi-bundle:
https://repository.apache.org/content/repositories/orgapachecxf-023/org/apache/cxf/dosgi/cxf-dosgi-ri-multibundle-distribution/1.2
  -   Single-bundle:
https://repository.apache.org/content/repositories/orgapachecxf-023/org/apache/cxf/dosgi/cxf-dosgi-ri-singlebundle-distribution/1.2

This release is tagged with cxf-dosgi-ri-1.2 at:

  http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.2

The vote will remain open for at least 72 hours.

Please consider this call to vote as my +1.

Cheers,
Eoghan

[1] http://www.osgi.org/Download/Release4V42



On 20 July 2010 07:43, David Bosschaert  wrote:

> Hi Eoghan,
>
> The mail that you sent around contains two links for every artefact,
> one pointing at orgapachecxf-023 which I presume is the right one and
> another pointing at orgapachecxf-021 which I don't think is the right
> one :)
> Also tags to both 1.1 and 1.2 are in there...
>
> Cheers,
>
> David
>
> On 19 July 2010 23:45, Eoghan Glynn  wrote:
> > Folks,
> >
> > I'm calling a vote to release CXF Distributed OSGi 1.2.
> >
> > In addition to providing the Reference Implementation to the OSGi Remote
> > Services Specification, the CXF Distributed OSGi 1.2 release now also
> > provides the Reference Implementation of the OSGi Remote Service Admin
> > Specification version 1.0, Chapter 122 in the OSGi Enterprise
> > Specification[1].
> >
> > The release notes contain a description of new features in this release:
> >
> >
> >
> http://svn.apache.org/repos/asf/cxf/dosgi/trunk/distribution/sources/src/main/release/release_notes.txt
> >
> > The staging area is at:
> >
> >  https://repository.apache.org/content/repositories/orgapachecxf-023<
> https://repository.apache.org/content/repositories/orgapachecxf-021>
> >
> > The various distributions can be downloaded as follows:
> >
> >   -   *Source:*
> >
> https://repository.apache.org/content/repositories/orgapachecxf-023/org/apache/cxf/dosgi/cxf-dosgi-ri-source-distribution/1.2
> <
> https://repository.apache.org/content/repositories/orgapachecxf-021/org/apache/cxf/dosgi/cxf-dosgi-ri-source-distribution/1.1
> >
> >   -   *Multi-bundle:*
> >
> https://repository.apache.org/content/repositories/orgapachecxf-023/org/apache/cxf/dosgi/cxf-dosgi-ri-multibundle-distribution/1.2
> <
> https://repository.apache.org/content/repositories/orgapachecxf-021/org/apache/cxf/dosgi/cxf-dosgi-ri-multibundle-distribution/1.1
> >
> >   -   *Single-bundle:*
> >
> https://repository.apache.org/content/repositories/orgapachecxf-023/org/apache/cxf/dosgi/cxf-dosgi-ri-singlebundle-distribution/1.2
> <
> https://repository.apache.org/content/repositories/orgapachecxf-021/org/apache/cxf/dosgi/cxf-dosgi-ri-singlebundle-distribution/1.1
> >
> >
> > This release is tagged with cxf-dosgi-ri-1.2 at:
> >
> >  http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.2<
> http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.1>
> >
> > The vote will remain open for at least 72 hours.
> >
> > Please consider this call to vote as my +1.
> >
> > Cheers,
> > Eoghan
> >
> > [1] http://www.osgi.org/Download/Release4V42
> >
>

[VOTE] Release CXF dOSGi 1.2

2010-07-19 Thread Eoghan Glynn

Folks,

I'm calling a vote to release CXF Distributed OSGi 1.2.

In addition to providing the Reference Implementation to the OSGi Remote
Services Specification, the CXF Distributed OSGi 1.2 release now also
provides the Reference Implementation of the OSGi Remote Service Admin
Specification version 1.0, Chapter 122 in the OSGi Enterprise
Specification[1].

The release notes contain a description of new features in this release:


http://svn.apache.org/repos/asf/cxf/dosgi/trunk/distribution/sources/src/main/release/release_notes.txt

The staging area is at:

  
https://repository.apache.org/content/repositories/orgapachecxf-023

The various distributions can be downloaded as follows:

   -   *Source:*
   
https://repository.apache.org/content/repositories/orgapachecxf-023/org/apache/cxf/dosgi/cxf-dosgi-ri-source-distribution/1.2
   -   *Multi-bundle:*
   
https://repository.apache.org/content/repositories/orgapachecxf-023/org/apache/cxf/dosgi/cxf-dosgi-ri-multibundle-distribution/1.2
   -   *Single-bundle:*
   
https://repository.apache.org/content/repositories/orgapachecxf-023/org/apache/cxf/dosgi/cxf-dosgi-ri-singlebundle-distribution/1.2

This release is tagged with cxf-dosgi-ri-1.2 at:

  
http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.2

The vote will remain open for at least 72 hours.

Please consider this call to vote as my +1.

Cheers,
Eoghan

[1] http://www.osgi.org/Download/Release4V42

Re: DOSGI: Update to CXF 2.2.9

2010-07-19 Thread Eoghan Glynn

OK, fair enough.

One other small issue with the attach-sources in cxf-dosgi-remote-service-
admin-interfaces being in the wrong phase (leaving the sources jar
unsigned).

Now fixed, so we should be good to go with this.

I'll go ahead and call the release vote ...

/Eoghan


On 19 July 2010 17:33,  wrote:

> Hi Eoghan,
>
> All I can say is that the system tests always work fine on my machine
> and that they also work fine on Hudson...
> http://hudson.zones.apache.org/hudson/view/CXF/job/CXF-DOSGi/
>
> Having said that, it's always a little tricky to get system tests
> right for all machines as there are so many things at play. Port
> numbers, timing, processor architecture, platform, they can all have
> an impact.
> I'm pretty sure the functionality tested by the system tests works,
> although the tests themselves might need a little tweaking to run on
> all machines (including yours - if you have any tips I would love to
> hear them :)
>
> Cheers,
>
> David
>
> On 19 July 2010 12:35, Eoghan Glynn  wrote:
> >
> > Hi David,
> >
> >> This exception happens when the remote service doesn't appear within
> >> the timeout... Any chance of running it again and see if it still
> >> fails?
> >
> > OK, I ran the build a few more times and didn't see the same failure, so
> > lets put that one down to a once-off aberration.
> >
> > However, when cutting the release I'm seeing an apparent hang in
> > org.apache.cxf.dosgi.systests2.single.TestImportService. I've attached
> the
> > tail of the console output so you can see if anything rings a bell there.
> >
> > For the moment the release is in limbo, i.e. the poms are updated, the
> tag
> > is laid down and the artifacts partially uploaded to the staging area in
> > Nexus. The upload doesn't look like its going to complete, seeing as the
> > test has been hung for the last half hour, so either way I'll be killing
> > that. However if you need to get any further fixes in, let me know and
> I'll
> > also roll back the changes in SVN and start from scratch next time.
> >
> > If on the other hand you're confident about the integrity of the tests, I
> > could potentially re-run the release with
> -Darguments=-Dmaven.test.skip=true
> > but I'm leery about doing so unless we're fairly happy that I'm seeing a
> > phantom issue here.
> >
> > Cheers,
> > Eoghan
> >
> >
> > On 19 July 2010 10:30,  wrote:
> >>
> >> Hi Eoghan,
> >>
> >> On 17 July 2010 12:59, Eoghan Glynn  wrote:
> >> >> Eoghan would you have some cycles?
> >> >
> >> > Yeah.
> >>
> >> Excellent!
> >>
> >> > A couple of things before I go ahead and cut the release:
> >> >
> >> > - can you update the release notes[1] with a summary of what's new in
> >> > this
> >> > release?
> >>
> >> Done.
> >>
> >> > - does this TimeoutException[2] in
> >> > TestExportService.testAccessEndpoint()
> >> > ring any bells?
> >>
> >> Not really, to be honest... It always passes for me :) It also passed
> >> on the last hudson run:
> >>
> >>
> http://hudson.zones.apache.org/hudson/view/CXF/job/CXF-DOSGi/org.apache.cxf.dosgi.systests$cxf-dosgi-ri-systests2-singlebundle/180/testReport/org.apache.cxf.dosgi.systests2.single/TestExportService/
> >>
> >> This exception happens when the remote service doesn't appear within
> >> the timeout... Any chance of running it again and see if it still
> >> fails?
> >>
> >> Best regards,
> >>
> >> David
> >
> >
>

Re: DOSGI: Update to CXF 2.2.9

2010-07-19 Thread Eoghan Glynn

Hi David,

> This exception happens when the remote service doesn't appear within
> the timeout... Any chance of running it again and see if it still
> fails?

OK, I ran the build a few more times and didn't see the same failure, so
lets put that one down to a once-off aberration.

However, when cutting the release I'm seeing an apparent hang in
org.apache.cxf.dosgi.systests2.single.TestImportService. I've attached the
tail of the console output so you can see if anything rings a bell there.

For the moment the release is in limbo, i.e. the poms are updated, the tag
is laid down and the artifacts partially uploaded to the staging area in
Nexus. The upload doesn't look like its going to complete, seeing as the
test has been hung for the last half hour, so either way I'll be killing
that. However if you need to get any further fixes in, let me know and I'll
also roll back the changes in SVN and start from scratch next time.

If on the other hand you're confident about the integrity of the tests, I
could potentially re-run the release with -Darguments=-Dmaven.test.skip=true
but I'm leery about doing so unless we're fairly happy that I'm seeing a
phantom issue here.

Cheers,
Eoghan

On 19 July 2010 10:30,  wrote:

> Hi Eoghan,
>
> On 17 July 2010 12:59, Eoghan Glynn  wrote:
> >> Eoghan would you have some cycles?
> >
> > Yeah.
>
> Excellent!
>
> > A couple of things before I go ahead and cut the release:
> >
> > - can you update the release notes[1] with a summary of what's new in
> this
> > release?
>
> Done.
>
> > - does this TimeoutException[2] in TestExportService.testAccessEndpoint()
> > ring any bells?
>
> Not really, to be honest... It always passes for me :) It also passed
> on the last hudson run:
>
> http://hudson.zones.apache.org/hudson/view/CXF/job/CXF-DOSGi/org.apache.cxf.dosgi.systests$cxf-dosgi-ri-systests2-singlebundle/180/testReport/org.apache.cxf.dosgi.systests2.single/TestExportService/
>
> This exception happens when the remote service doesn't appear within
> the timeout... Any chance of running it again and see if it still
> fails?
>
> Best regards,
>
> David
>

Re: DOSGI: Update to CXF 2.2.9

2010-07-17 Thread Eoghan Glynn

> I think we're ready for a release!

Great!

> Eoghan would you have some cycles?

Yeah.

A couple of things before I go ahead and cut the release:

- can you update the release notes[1] with a summary of what's new in this
release?

- does this TimeoutException[2] in TestExportService.testAccessEndpoint()
ring any bells?

Cheers,
Eoghan


[1] distribution/sources/src/main/release/release_notes.txt

[2]

---
Test set: org.apache.cxf.dosgi.systests2.single.TestExportService
---
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 123.83
sec <<< FAILURE!
testAccessEndpoint
[felix](org.apache.cxf.dosgi.systests2.single.TestExportService)  Time
elapsed: 123.427 sec  <<< ERROR!
java.util.concurrent.TimeoutException
at 
org.apache.cxf.dosgi.systests2.common.AbstractTestExportService.waitPort(AbstractTestExportService.java:129)
at 
org.apache.cxf.dosgi.systests2.common.AbstractTestExportService.baseTestAccessEndpoint(AbstractTestExportService.java:45)
at 
org.apache.cxf.dosgi.systests2.single.TestExportService.testAccessEndpoint(TestExportService.java:58)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:134)
at 
org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at 
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)


On 16 July 2010 13:53, David Bosschaert  wrote:

> I spent a little while debugging this today and found that the issue
> was that the bundles internally used by the system tests didn't have
> the proper startlevel set which meant that they would get assigned
> level 5 and be started way before any of the other bundles, nailing
> the jaxws package to the one from the JRE again (0.0.0).
> I've changed the start level of these bundles and now everything is
> working correctly.
>
> I've committed this in r964787.
>
> I think we're ready for a release! Eoghan would you have some cycles?
>
> Cheers,
>
> David
>
> On 30 June 2010 18:16, Daniel Kulp  wrote:
> > On Tuesday 29 June 2010 3:24:55 am David Bosschaert wrote:
> >> It troubles me that if people want to use CXF-DOSGi they would have to
> >> fiddle with the org.osgi.framework.system.packages. This is a major
> >> usability drawback from where we were before.
> >>
> >> > A more long-term option might to ship an entire distro of karaf with
> >> > dOSGi,
> >>
> >> I'm also opposed to turning the CXF-DOSGi distribution into a Karaf
> >> distro as OSGi is all about reusable components that can be used in
> >> any compliant OSGi Framework. We shouldn't have to ship a tweaked
> >> runtime for people to be able to use it.
> >>
> >> >> I'm just curious, why was the CXF import updated to include 0.0.0 ?
> >> >
> >> > So it works with an "out of the box" setup of Equinox without
> requiring
> >> > the user to update funky setup things like the system.packages thing.
> >>
> >> Depending on version 0.0.0 is potentially dangerous because you have
> >> no idea

Re: DOSGI: Update to CXF 2.2.9

2010-06-29 Thread Eoghan Glynn

> A more long-term option might to ship an entire distro of karaf with
dOSGi,
> I'm also opposed to turning the CXF-DOSGi distribution into a Karaf
> distro as OSGi is all about reusable components that can be used in
> any compliant OSGi Framework. We shouldn't have to ship a tweaked
> runtime for people to be able to use it.

Well it could be a convenience *option*, just to get folks started out of
the box.

Agreed we would have to continue with the multi-bundle style option that
could be plonked into an existing runtime and be expected to work (without
too much bother).

> Depending on version 0.0.0 is potentially dangerous because you have
> no idea what version you will get. In OSGi this dependency means: take
> any version available!

Yeah.

But the way I'd see it is that CXF has kinda been backed into a corner by
what is fundamentally a framework bug. Exposing all the system packages as
0.0.0.0 makes absolutely no sense IMO, when many of these packages have a
clearly versioned provenance and it's likely that dependent bundles will
pull them in via version-constrained imports. The framework's 0.0.0.0 might
have been workable back in the day when only java.lang.String etc. were
being pulled in from the system package, but as more and more javax.* stuff
is being piled into the JRE, this isn't really feasible any more.

That said however, if there's a smarter fix/workaround that could be applied
to CXF instead, then great!

> We could also reorder the bundles in the multibundle distro definition
> file (distro_bundles.xml).

Just a ceveat, re-ordering bundles can be very fragile. SMX hit some nasty
issues whereby the ordering was subtly changed when the bundles were being
pulled in from a slowish NAS.

Cheers,
Eoghan

On 29 June 2010 08:24, David Bosschaert  wrote:

> It troubles me that if people want to use CXF-DOSGi they would have to
> fiddle with the org.osgi.framework.system.packages. This is a major
> usability drawback from where we were before.
>
> > A more long-term option might to ship an entire distro of karaf with
> dOSGi,
> I'm also opposed to turning the CXF-DOSGi distribution into a Karaf
> distro as OSGi is all about reusable components that can be used in
> any compliant OSGi Framework. We shouldn't have to ship a tweaked
> runtime for people to be able to use it.
>
> >> I'm just curious, why was the CXF import updated to include 0.0.0 ?
> > So it works with an "out of the box" setup of Equinox without requiring
> the
> > user to update funky setup things like the system.packages thing.
>
> Depending on version 0.0.0 is potentially dangerous because you have
> no idea what version you will get. In OSGi this dependency means: take
> any version available!
>
> For CXF-DOSGi, as a temporary workaround, we *could* is *fix* the CXF
> jar that's part of our multibundle distro (during the build) and
> change the starting version back to what it was before.
>
> We could also reorder the bundles in the multibundle distro definition
> file (distro_bundles.xml). I managed to get things working in the
> standalone case by putting the cxf bundle below the jaxws/jaxrs
> bundles, however for some reason it still hangs in the system tests...
>
> Cheers,
>
> David
>

Re: DOSGI: Update to CXF 2.2.9

2010-06-28 Thread Eoghan Glynn

Dunno about older versions of felix, but 3.0.1 doesn't have the
org.osgi.framework.system.packages already listed out in the
config.properties. So it wouldn't just be a case of commenting out a few
pre-existing lines of config. Instead the user would have to copy a valid
org.osgi.framework.system.packages setting from somewhere else (e.g. the SMX
version).

Cheers,
Eoghan

On 28 June 2010 20:25, Sergey Beryozkin  wrote:

> I'd probably prefer updating the documentation and asking users to remove
> the jaxws related entry in their own 1.6-related part of the config. They
> will be appending the DOSGI fragment anyway and asking them to replace the
> 1.6 related part (which already exists in their config) with what DOSGI RI
> ships might be an extra hassle IMHO...
>
> cheers, Sergey
>
>
> >
> > A more long-term option might to ship an entire distro of karaf with
> dOSGi,
> > customized with some extra features in the internal system repo (that's
> the
> > approach I'm taking on another project that builds a CLI atop karaf,
> works
> > quite neatly with the features-maven-plugin to populate the internal
> repo).
> > The nice thing is that this is guaranteed to work out of the box, with
> all
> > external dependencies already resolved and all the versions lined up.
> Makes
> > the distro just a tad bigger tho' ;)
> >
> > Cheers,
> > Eoghan
> >
> > On 28 June 2010 18:19, Sergey Beryozkin  wrote:
> >
> > > Hi Eoghan
> > >
> > > ServiceMix is shipping the config.properties and they may be specific
> to
> > a
> > > specific Felix version ? Similarly for Equinox (even though most of the
> > > config.properties are probably reusable across diff versions)
> > > DOSGI RI does only ship the fragments of config properties which are
> > built
> > > during the multi-bundle build...
> > >
> > > I'm just curious, why was the CXF import updated to include 0.0.0 ?
> > >
> > > cheers, Sergey
> > >
> > >
> > > On Mon, Jun 28, 2010 at 5:55 PM, Eoghan Glynn 
> wrote:
> > >
> > > > Have you tried overriding the org.osgi.framework.system.packages
> > property
> > > > in
> > > > felix/conf/config.properties, with a list of packages specifically
> > > > excluding
> > > > javax.xml.ws.*?
> > > >
> > > > This is the approach taken by SMX to get around these sort of issues.
> > See
> > > > for ex:
> > > >
> > > > wget
> > > >
> > > >
> > >
> >
> https://www.apache.org/dist/servicemix/servicemix-4/4.2.0/apache-servicemix-4.2.0.tar.gz
> > > > tar -xvzf apache-servicemix-4.2.0.tar.gz
> > > > less apache-servicemix-4.2.0/etc/config.properties
> > > >
> > > > Note the packages in the jre-1.6 list that are specifically commented
> > to
> > > > avoid a 0.0.0.0 version dragged in from the system bundle upsetting
> > > > version-constrained imports.
> > > >
> > > > Cheers,
> > > > Eoghan
> > > >
> > > > On 28 June 2010 10:34, David Bosschaert 
> > > > wrote:
> > > >
> > > > > Hi Sergey,
> > > > >
> > > > > I tried your patch on my machine and can confirm that it seems to
> > > > > consistently hang in the multibundle system test. This wasn't the
> > case
> > > > > before.
> > > > >
> > > > > The good news is that it's hanging because the multi-bundle distro
> is
> > > > > actually broken - it's so good to have tests :)
> > > > >
> > > > > I just tried it manually with Felix 3.0.1 and it tells me this
> > > > > org.apache.felix.framework.resolver.ResolveException: Constraint
> > > > > violation for package 'javax.xml.ws' when resolving module 7.0
> > between
> > > > > existing import 13.0.javax.xml.ws BLAMED ON [[7.0] package;
> > > > > (&(package=javax.xml.ws)(version>=2.1.0))] and uses constraint
> > > > > 0.javax.xml.ws BLAMED ON [[7.0] package;
> > > > > (&(package=org.apache.cxf.jaxrs.provider)(version>=2.2.0)), [17.0]
> > > > > package; (&(package=javax.xml.ws
> > )(version>=0.0.0)(!(version>=3.0.0)))]
> > > > >
> > > > > Cheers,
> > > > >
> > > > > David
> > > > >
> > > > > g! lb
>

Re: DOSGI: Update to CXF 2.2.9

2010-06-28 Thread Eoghan Glynn

On 28 June 2010 18:19, Sergey Beryozkin  wrote:

> ServiceMix is shipping the config.properties and they may be specific to a
> specific Felix version

Well part of the config.props is version-specific (i.e. the exact version of
equinox/felix framework to use), but not so much the bit defining the
jre-1.5 and jre-1.6 specific packages.

So you could conceivably just ship a fragment to append to the user's
conf/config.properties (seeing as we already ship a
felix.config.properties.append file with a big long list of bundles to load
on startup).

A more long-term option might to ship an entire distro of karaf with dOSGi,
customized with some extra features in the internal system repo (that's the
approach I'm taking on another project that builds a CLI atop karaf, works
quite neatly with the features-maven-plugin to populate the internal repo).
The nice thing is that this is guaranteed to work out of the box, with all
external dependencies already resolved and all the versions lined up. Makes
the distro just a tad bigger tho' ;)

Cheers,
Eoghan

On 28 June 2010 18:19, Sergey Beryozkin  wrote:

> Hi Eoghan
>
> ServiceMix is shipping the config.properties and they may be specific to a
> specific Felix version ? Similarly for Equinox (even though most of the
> config.properties are probably reusable across diff versions)
> DOSGI RI does only ship the fragments of config properties which are built
> during the multi-bundle build...
>
> I'm just curious, why was the CXF import updated to include 0.0.0 ?
>
> cheers, Sergey
>
>
> On Mon, Jun 28, 2010 at 5:55 PM, Eoghan Glynn  wrote:
>
> > Have you tried overriding the org.osgi.framework.system.packages property
> > in
> > felix/conf/config.properties, with a list of packages specifically
> > excluding
> > javax.xml.ws.*?
> >
> > This is the approach taken by SMX to get around these sort of issues. See
> > for ex:
> >
> > wget
> >
> >
> https://www.apache.org/dist/servicemix/servicemix-4/4.2.0/apache-servicemix-4.2.0.tar.gz
> > tar -xvzf apache-servicemix-4.2.0.tar.gz
> > less apache-servicemix-4.2.0/etc/config.properties
> >
> > Note the packages in the jre-1.6 list that are specifically commented to
> > avoid a 0.0.0.0 version dragged in from the system bundle upsetting
> > version-constrained imports.
> >
> > Cheers,
> > Eoghan
> >
> > On 28 June 2010 10:34, David Bosschaert 
> > wrote:
> >
> > > Hi Sergey,
> > >
> > > I tried your patch on my machine and can confirm that it seems to
> > > consistently hang in the multibundle system test. This wasn't the case
> > > before.
> > >
> > > The good news is that it's hanging because the multi-bundle distro is
> > > actually broken - it's so good to have tests :)
> > >
> > > I just tried it manually with Felix 3.0.1 and it tells me this
> > > org.apache.felix.framework.resolver.ResolveException: Constraint
> > > violation for package 'javax.xml.ws' when resolving module 7.0 between
> > > existing import 13.0.javax.xml.ws BLAMED ON [[7.0] package;
> > > (&(package=javax.xml.ws)(version>=2.1.0))] and uses constraint
> > > 0.javax.xml.ws BLAMED ON [[7.0] package;
> > > (&(package=org.apache.cxf.jaxrs.provider)(version>=2.2.0)), [17.0]
> > > package; (&(package=javax.xml.ws)(version>=0.0.0)(!(version>=3.0.0)))]
> > >
> > > Cheers,
> > >
> > > David
> > >
> > > g! lb
> > > START LEVEL 85
> > >   ID|State  |Level|Name
> > >0|Active |0|System Bundle (3.0.1)
> > >1|Active |1|Apache Felix Bundle Repository (1.6.2)
> > >2|Active |1|Apache Felix Gogo Command (0.6.0)
> > >3|Active |1|Apache Felix Gogo Runtime (0.6.0)
> > >4|Active |1|Apache Felix Gogo Shell (0.6.0)
> > >5|Active |   85|CXF dOSGi Topology Manager (1.2.0.SNAPSHOT)
> > >6|Active |   53|geronimo-javamail_1.4_spec (1.2.0)
> > >7|Installed  |   84|CXF dOSGi Remote Service Admin Implementation
> > > (1.2.0.SNA
> > > PSHOT)
> > >8|Active |   52|geronimo-activation_1.1_spec (1.0.2)
> > >9|Active |   83|CXF Local Discovery Service Bundle
> > (1.2.0.SNAPSHOT)
> > >   10|Active |   51|geronimo-annotation_1.0_spec (1.1.1)
> > >   11|Active |   82|Apache ServiceMix Specs :: JSR311 API 1.0
> (1.3.0)
> > >   12|Active |   50|osgi.compendium (4.1.0.build-200702212030)
> > >   13|Active |   81|Apache ServiceMix Specs :: JAXWS

Re: DOSGI: Update to CXF 2.2.9

2010-06-28 Thread Eoghan Glynn

Have you tried overriding the org.osgi.framework.system.packages property in
felix/conf/config.properties, with a list of packages specifically excluding
javax.xml.ws.*?

This is the approach taken by SMX to get around these sort of issues. See
for ex:

wget
https://www.apache.org/dist/servicemix/servicemix-4/4.2.0/apache-servicemix-4.2.0.tar.gz
tar -xvzf apache-servicemix-4.2.0.tar.gz
less apache-servicemix-4.2.0/etc/config.properties

Note the packages in the jre-1.6 list that are specifically commented to
avoid a 0.0.0.0 version dragged in from the system bundle upsetting
version-constrained imports.

Cheers,
Eoghan

On 28 June 2010 10:34, David Bosschaert  wrote:

> Hi Sergey,
>
> I tried your patch on my machine and can confirm that it seems to
> consistently hang in the multibundle system test. This wasn't the case
> before.
>
> The good news is that it's hanging because the multi-bundle distro is
> actually broken - it's so good to have tests :)
>
> I just tried it manually with Felix 3.0.1 and it tells me this
> org.apache.felix.framework.resolver.ResolveException: Constraint
> violation for package 'javax.xml.ws' when resolving module 7.0 between
> existing import 13.0.javax.xml.ws BLAMED ON [[7.0] package;
> (&(package=javax.xml.ws)(version>=2.1.0))] and uses constraint
> 0.javax.xml.ws BLAMED ON [[7.0] package;
> (&(package=org.apache.cxf.jaxrs.provider)(version>=2.2.0)), [17.0]
> package; (&(package=javax.xml.ws)(version>=0.0.0)(!(version>=3.0.0)))]
>
> Cheers,
>
> David
>
> g! lb
> START LEVEL 85
>   ID|State  |Level|Name
>0|Active |0|System Bundle (3.0.1)
>1|Active |1|Apache Felix Bundle Repository (1.6.2)
>2|Active |1|Apache Felix Gogo Command (0.6.0)
>3|Active |1|Apache Felix Gogo Runtime (0.6.0)
>4|Active |1|Apache Felix Gogo Shell (0.6.0)
>5|Active |   85|CXF dOSGi Topology Manager (1.2.0.SNAPSHOT)
>6|Active |   53|geronimo-javamail_1.4_spec (1.2.0)
>7|Installed  |   84|CXF dOSGi Remote Service Admin Implementation
> (1.2.0.SNA
> PSHOT)
>8|Active |   52|geronimo-activation_1.1_spec (1.0.2)
>9|Active |   83|CXF Local Discovery Service Bundle (1.2.0.SNAPSHOT)
>   10|Active |   51|geronimo-annotation_1.0_spec (1.1.1)
>   11|Active |   82|Apache ServiceMix Specs :: JSR311 API 1.0 (1.3.0)
>   12|Active |   50|osgi.compendium (4.1.0.build-200702212030)
>   13|Active |   81|Apache ServiceMix Specs :: JAXWS API 2.1 (1.3.0)
>   14|Active |   80|Apache ServiceMix Specs :: JAXB API 2.1 (1.3.0)
>   15|Active |   79|Apache ServiceMix Specs :: STAX API 1.0 (1.3.0)
>   16|Active |   78|Apache ServiceMix Specs :: SAAJ API 1.3 (1.3.0)
>   17|Active |   77|Apache CXF Minimal Bundle Jar (2.2.9)
>   18|Active |   76|Apache ServiceMix Bundles: commons-pool-1.5.4
> (1.5.4.1)
>   19|Active |   75|Apache ServiceMix Bundles: woodstox-3.2.7 (3.2.7.1)
>   20|Active |   74|Apache ServiceMix Bundles: neethi-2.0.4 (2.0.4.1)
>   21|Active |   73|Apache ServiceMix Bundles: xmlresolver-1.2 (1.2.0.1)
>   22|Active |   72|Apache ServiceMix Bundles: asm-2.2.3 (2.2.3.1)
>   23|Active |   71|Apache ServiceMix Bundles: xmlschema-1.4.3 (1.4.3.1)
>   24|Active |   70|Apache ServiceMix Bundles: xmlsec-1.3.0 (1.3.0.1)
>   25|Active |   69|Apache ServiceMix Bundles: wsdl4j-1.6.1 (1.6.1.1)
>   26|Active |   68|Apache ServiceMix Bundles: jaxb-impl-2.1.6 (2.1.6.1)
>   27|Active |   67|OPS4J Pax Web - Service (0.5.1)
>   28|Active |   66|spring-osgi-extender (1.2.0)
>   29|Active |   65|spring-osgi-core (1.2.0)
>   30|Active |   64|spring-osgi-io (1.2.0)
>   31|Active |   63|Spring AOP (2.5.6)
>   32|Resolved   |   62|SLF4J Jakarta Commons Logging Binding (1.5.10)
>   33|Active |   61|SLF4J API (1.5.10)
>   34|Active |   60|AOP Alliance API (1.0.0)
>   35|Active |   59|Spring Context (2.5.6)
>   36|Active |   58|Spring Beans (2.5.6)
>   37|Active |   57|Spring Core (2.5.6)
>   38|Active |   56|JDOM DOM Processor (1.0.0)
>   39|Active |   55|Apache Commons Logging (1.1.1)
>   40|Active |   54|geronimo-ws-metadata_2.0_spec (1.1.2)
> g! start 7
> RE: org.apache.felix.framework.resolver.ResolveException: Constraint
> violation f
> or package 'javax.xml.ws' when resolving module 7.0 between existing
> import 13.0
> .javax.xml.ws BLAMED ON [[7.0] package; (&(package=javax.xml.ws
> )(version>=2.1.0)
> )] and uses constraint 0.javax.xml.ws BLAMED ON [[7.0] package;
> (&(package=org.a
> pache.cxf.jaxrs.provider)(version>=2.2.0)), [17.0] package;
> (&(package=javax.xml
> .ws)(version>=0.0.0)(!(version>=3.0.0)))]
> org.osgi.framework.BundleException: Constraint violation for package
> 'javax.xml.
> ws' when resolving module 7.0 between existing import 13.0.javax.xml.wsBLAMED 
> O
> N [[7.0] package; (&(package=javax.xml.ws)(version>=2.1.0))] and uses
> constraint
>  0.javax.xml.ws BLAMED ON [[7.0] package;
> (&(package=org.apache.

Re: CXF-DOSGi passing the OSGi Remote Services and Remote Service Admin CT

2010-06-22 Thread Eoghan Glynn

> 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  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  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: [VOTE] Release CXF 2.2.7

2010-03-19 Thread Eoghan Glynn

+1

/Eoghan

On 19 March 2010 01:21, Daniel Kulp  wrote:

>
> Once again, there have been a bunch of bug fixes and enhancements that
> have been done compared to the 2.2.6 release.   Over 55 JIRA issues
> are resolved for 2.2.7.
>
> List of issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12314534&styleName=Html&projectId=12310511&Create=Create
>
> The Maven staging area is at:
> https://repository.apache.org/content/repositories/orgapachecxf-006/
>
> The distributions are in:
>
> https://repository.apache.org/content/repositories/orgapachecxf-006/org/apache/cxf/apache-cxf/2.2.7/
>
> This release is tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.7
>
>
> The vote will be open for 72 hours.
>
> Here is my +1.
>
>
> --
> Daniel Kulp
> dk...@apache.org
> http://dankulp.com/blog
>

Re: JMX enabling in CXF 2.2.6

2010-03-19 Thread Eoghan Glynn

A-ha, my bad, I assumed you were using the remote process option ... so you
just can't see the CXF MBeans when you connect via the jconsole local
process option?

That's easy, just ensure your injected InstrumentationManager bean picks up
the *platform* MBeanServer as opposed to creating a fresh one. Its the
platform MBeanServer that the local process option will go for by default.

Simply modify your config as follows to set the usePlatformMBeanServer
property:


 
 
 
 
 
 

BTW in the remote case, you don't even need to specify the cxf/cxf as remote
user/pass as this is not authenticated (unlike SMX/karaf).

/Eoghan

On 19 March 2010 10:29, Ulhas Bhole  wrote:

> Hi Eoghan,
>
> I did a few tests and it looks like if I try to connect to the process from
> JConsole it doesn't show CXF JMX stats. If I create a new connection using
> JMX URL and username/password (cxf/cxf) I do see the CXF MBean appearing.
>
> Thanks for the help.
>
> Regards,
>
> Ulhas Bhole
>
> I just did a few tests
>
> I just tried it on 2 different machines (Linux and Mac) using JDK 1.5
> On Fri, Mar 19, 2010 at 10:05 AM, Ulhas Bhole 
> wrote:
>
> > Thanks Eoghan for quick reply. I will try to update build.xml target and
> > check. I was putting cxf.xml in $CXF_HOME/samples/wsdl_first_rpclit
> > directory and I think it was picked up because when I ran client it did
> got
> > AddressAlreadyInUse for JMX port and also I could connect to the server
> > using JConsole.
> >
> > I will try your route.
> >
> > Regards,
> >
> > Ulhas Bhole
> >
> >
> > On Thu, Mar 18, 2010 at 10:05 PM, Eoghan Glynn 
> wrote:
> >
> >> Ulhas,
> >>
> >> How are you picking up the config file?
> >>
> >> For example, if you're running the server via ant, you'd need to change
> >> the
> >> server target defined in $CXF_HOME/samples/wsdl_first_rpclit/build.xml
> >> from:
> >>
> >>
> >> >>param1="${basedir}/wsdl/hello_world_RPCLit.wsdl"/>
> >>
> >>
> >> to:
> >>
> >>
> >> >>jvmarg1="-Dcxf.config.file=cxf.xml"
> >>param1="${basedir}/wsdl/hello_world_RPCLit.wsdl"/>
> >>
> >>
> >> Alternatively, you could change the
> >> $CXF_HOME/samples/wsdl_first_rpclit/src/demo/hwRPCLit/server/Server.java
> >> to
> >> use the SpringBusFactory to explicit identify the config file when
> >> creating
> >> the Bus.
> >>
> >> But obviously you must make the connection to the config in *some* way,
> >> otherwise the intrumentation config will have no effect. BTW I just
> >> confirmed that the CXF MBeans appear as expected with this demo using
> your
> >> config file and the first approach described.
> >>
> >> Cheers,
> >> Eoghan
> >>
> >>
> >> On 18 March 2010 17:24, Ulhas Bhole  wrote:
> >>
> >> > Hi,
> >> > I am trying to enable JMX instrumentation in CXF 2.2.6 sample
> >> > (wsdl_first_rpclit) but when I try to connect to server using JConsole
> I
> >> > don't see any CXF MBeans. Do I need to do anything in addition to
> >> > configuring Instrumentation manager?
> >> >
> >> > Here is my cxf.xml that I am using to enable instrumentation. I am not
> >> > updating any implementation to collect endpoint statistics just want
> to
> >> see
> >> > cxf stats first like Bus.
> >> >
> >> > http://www.springframework.org/schema/beans";
> >> >  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> >> >  xmlns:jaxws="http://cxf.apache.org/jaxws";
> >> >  xmlns:cxf="http://cxf.apache.org/core";
> >> >
> >> >  xsi:schemaLocation="
> >> > http://www.springframework.org/schema/beans
> >> > http://www.springframework.org/schema/beans/spring-beans.xsd
> >> > http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
> >> > http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd";>
> >> >
> >> >
> >> >  >> >  class="org.apache.cxf.management.jmx.InstrumentationManagerImpl">
> >> >  
> >> >  
> >> >  
> >> >  
> >> >   >> > value="service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi" />
> >> >
> >> > 
> >> >
> >> > 
> >> > >> > class="org.apache.cxf.management.counters.CounterRepository">
> >> >
> >> >
> >> > 
> >> >
> >> >
> >> > Regards,
> >> >
> >> > Ulhas Bhole
> >> >
> >>
> >
> >
>

Re: JMX enabling in CXF 2.2.6

2010-03-18 Thread Eoghan Glynn

Ulhas,

How are you picking up the config file?

For example, if you're running the server via ant, you'd need to change the
server target defined in $CXF_HOME/samples/wsdl_first_rpclit/build.xml from:

to:

Alternatively, you could change the
$CXF_HOME/samples/wsdl_first_rpclit/src/demo/hwRPCLit/server/Server.java to
use the SpringBusFactory to explicit identify the config file when creating
the Bus.

But obviously you must make the connection to the config in *some* way,
otherwise the intrumentation config will have no effect. BTW I just
confirmed that the CXF MBeans appear as expected with this demo using your
config file and the first approach described.

Cheers,
Eoghan

On 18 March 2010 17:24, Ulhas Bhole  wrote:

> Hi,
> I am trying to enable JMX instrumentation in CXF 2.2.6 sample
> (wsdl_first_rpclit) but when I try to connect to server using JConsole I
> don't see any CXF MBeans. Do I need to do anything in addition to
> configuring Instrumentation manager?
>
> Here is my cxf.xml that I am using to enable instrumentation. I am not
> updating any implementation to collect endpoint statistics just want to see
> cxf stats first like Bus.
>
> http://www.springframework.org/schema/beans";
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>  xmlns:jaxws="http://cxf.apache.org/jaxws";
>  xmlns:cxf="http://cxf.apache.org/core";
>
>  xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd
> http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
> http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd";>
>
>
>   class="org.apache.cxf.management.jmx.InstrumentationManagerImpl">
>  
>  
>  
>  
>   value="service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi" />
>
> 
>
> 
> class="org.apache.cxf.management.counters.CounterRepository">
>
>
> 
>
>
> Regards,
>
> Ulhas Bhole
>

Re: [VOTE] David Valeri for committer

2010-03-10 Thread Eoghan Glynn

+1

/Eoghan

On 10 March 2010 14:29, Daniel Kulp  wrote:

>
> David's been doing a good job lately of answering questions on the
> mailing lists and getting involved there.   He's also submitted several
> high
> quality patches for the ws-security and security-policy stuff.  The patches
> are all very complete with excellent unit tests and such.The
> WS-Security
> stuff is a very complex area of code and he's doing a great job picking it
> up
> and fixing issues in it.
>
> Here's my +1.   Vote will be open for at least 72 hours.
>
>
> --
> Daniel Kulp
> dk...@apache.org
> http://dankulp.com/blog
>

Re: [VOTE] Marc Schaaf for committer

2010-03-09 Thread Eoghan Glynn

+1

Cheers,
Eoghan

On 9 March 2010 16:09, David Bosschaert  wrote:

> Hi all,
>
> I would like to propose Marc Schaaf as a committer for CXF. Marc has
> written a tremendous amount of code for CXF-DOSGi (which he provided
> as patches to JIRA), making it compliant with the OSGi 4.2 Remote
> Service Admin specification. This effort is nearly complete now, we're
> mainly waiting for the last few OSGi CT test cases to pass. Marc has
> produced excellent work and I think that he very much earned a CXF
> committership.
>
> Here's my +1.
>
> The vote will remain open for at least 72 hours.
>
> Best regards,
>
> David
>

Re: Apache Licensed JAX-RS Spec API JAR

2010-02-11 Thread Eoghan Glynn

Have you considered just using the ServiceMix versions of the JSR-311 spec?

Code here:
http://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/jsr311-api-1.0/
http://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/jsr311-api-1.1/

Artefacts here:
http://repo2.maven.org/maven2/org/apache/servicemix/specs/org.apache.servicemix.specs.jsr311-api-1.0/
http://repo2.maven.org/maven2/org/apache/servicemix/specs/org.apache.servicemix.specs.jsr311-api-1.1/

These are Apache licensed.

Cheers,
Eoghan

On 11 February 2010 10:42, Rick McGuire  wrote:

> On 2/10/2010 4:07 PM, Bryant Luk wrote:
>
>> Hi,
>>
>> We (some followers to Wink dev mailing list) were wondering if the CXF
>> dev community would be interested in helping to contribute/consume a
>> JAX-RS 1.0/1.1 API JAR for Geronimo's spec jars that were Apache
>> licensed.  I couldn't find an Apache licensed version of the JSR-311
>> spec.  I see other communities that have implemented JSR specs are
>> using Apache licensed of their specs.  I don't know the exact
>> procedure to contribute a spec api jar to Geronimo, but I don't think
>> this would take too much effort considering that most of the JAX-RS
>> spec is annotation/interface based with very few actual classes.
>>
>>
>
> Creating a JAX-RS spec jar is definitely in our plans, but it just hasn't
> happened yet because we haven't started looking at integrating this support
> yet.  We even have a Jira open for this particular task:
>
> http://issues.apache.org/jira/browse/GERONIMO-5095
>
> If you'd like to contribute code for this, the easiest way would be to
> attach a patch to that Jira issue.
>
> Rick
>
>
>  On Wed, Feb 10, 2010 at 2:50 PM, Davanum Srinivas
>>  wrote:
>>
>>
>>> Got it. i mis-remembered seeing a jax-rs api jar from geronimo. Looks
>>> like CXF uses the CDDL jar as well. May be we should ping them to see
>>> if they would be interested.
>>>
>>> +1 from me.
>>>
>>> -- dims
>>>
>>> On Wed, Feb 10, 2010 at 3:44 PM, Nicholas L Gallardo
>>>   wrote:
>>>
>>>
 +1 from me Bryant.

 There isn't a JSR spec for JAX-RS available in Geronimo as of yet. I
 don't know where they've come from in the past, but I'm assuming they've
 been contributed by the relevant technical teams/communities.

 The API jar currently in the maven repo is CDDL licensed.

 -Nick



 Davanum Srinivas ---02/10/2010 02:40:56 PM---Why can't we use the JSR
 spec from geronimo? :)

 Davanum Srinivas

 02/10/2010 02:40 PM

 Please respond to
 wink-...@incubator.apache.org

 To
 wink-...@incubator.apache.org
 cc

 Subject
 Re: Apache Licensed JAX-RS Spec API JAR
 Why can't we use the JSR spec from geronimo? :)

 -- dims

 On Wed, Feb 10, 2010 at 3:32 PM, Bryant Luk
  wrote:


> Hi,
>
> I see that several Apache projects based on JSR specs have geronimo
> (Apache licensed) versions of the spec.  Should we also consider
> contributing one for JAX-RS 1.0 and 1.1?  I don't see one in the Maven
> repository that's Apache licensed.
>
> Thanks.
>
>
>


 --
 Davanum Srinivas :: http://davanum.wordpress.com



>>>
>>>
>>> --
>>> Davanum Srinivas :: http://davanum.wordpress.com
>>>
>>>
>>>
>>
>>
>
>

Re: [DOSGi] Reworking the system tests

2010-01-22 Thread Eoghan Glynn

Yep, now that you mention it, tiny bundles were what Toni Menzel of the PAX
team suggested using when we tripped over a similar issue with the SMX
integration tests during the Karaf switch-over.

Cheers,
Eoghan

2010/1/22 

> Thanks for the heads up Eoghan.
>
> I understood that the recent tiny bundles integration could take care
> of this. Have a look at the bottom example in
> http://wiki.ops4j.org/display/paxexam/ExamAndTinybundles. Do you think
> that will do it?
>
> Cheers,
>
> David
>
> 2010/1/22 Eoghan Glynn :
> >
> > David,
> >
> > One thing to note about pax-exam is that its doesn't AFAIK have a feature
> > analogous to the spring-osgi-test support for accessing and adding to the
> > manifest for the on-the-fly bundle.
> >
> > Now I don't know whether we could possibly live without this
> > manifest-mangling as currently done by the dOSGi systests, specifically
> > setting the DynamicImport-Package header to "*".
> >
> > If we can live without this setting, no worries. If not, its something to
> > consider about adopting pax-exam.
> >
> > Cheers,
> > Eoghan
> >
> >
> > 2010/1/22 
> >>
> >> Hi all,
> >>
> >> One of the things to-do for the DOSGi refactoring work that's
> >> currently happening on trunk is to re-enable the system tests.
> >> Now both Sergey and I have been fighting with the spring-osgi based
> >> testing system that's there before and I can tell you it's generally
> >> no fun at all. The biggest problem that I've encountered with it is
> >> the interference of the test framework with the CXF-DOSGi code as they
> >> both use Spring-DM but sometimes have conflicting requirements.
> >>
> >> So I'd like to spend a little bit of time refactoring the system tests
> >> to use Pax-Exam. I haven't used it in anger yet but I've heard good
> >> things about it and it should not suffer from the interference
> >> problem.
> >>
> >> Thoughts anyone?
> >>
> >> David
> >
> >
>

Re: [DOSGi] Reworking the system tests

2010-01-22 Thread Eoghan Glynn

David,

One thing to note about pax-exam is that its doesn't AFAIK have a feature
analogous to the spring-osgi-test support for accessing and adding to the
manifest for the on-the-fly bundle.

Now I don't know whether we could possibly live without this
manifest-mangling as currently done by the dOSGi systests, specifically
setting the DynamicImport-Package header to "*".

If we can live without this setting, no worries. If not, its something to
consider about adopting pax-exam.

Cheers,
Eoghan


2010/1/22 

> Hi all,
>
> One of the things to-do for the DOSGi refactoring work that's
> currently happening on trunk is to re-enable the system tests.
> Now both Sergey and I have been fighting with the spring-osgi based
> testing system that's there before and I can tell you it's generally
> no fun at all. The biggest problem that I've encountered with it is
> the interference of the test framework with the CXF-DOSGi code as they
> both use Spring-DM but sometimes have conflicting requirements.
>
> So I'd like to spend a little bit of time refactoring the system tests
> to use Pax-Exam. I haven't used it in anger yet but I've heard good
> things about it and it should not suffer from the interference
> problem.
>
> Thoughts anyone?
>
> David
>

Re: [VOTE] Release CXF 2.1.9

2010-01-20 Thread Eoghan Glynn

+1

Cheers,
Eoghan

2010/1/20 Daniel Kulp 

>
> This is a vote to release CXF 2.1.9
>
> Once again, there have been a bunch of bug fixes and enhancements that
> have been done compared to the 2.1.8 release.   Over 43 JIRA issues
> are resolved for 2.1.9
>
> *Note:* as announced earlier this will be the last 2.1.x release of Apache
> CXF.   Users are encouraged to start migrating to 2.2.x.
>
>
> List of issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12314380&styleName=Html&projectId=12310511&Create=Create
>
> The Maven staging area is at:
> https://repository.apache.org/content/repositories/orgapachecxf-056/
>
> The distributions are in:
>
> https://repository.apache.org/content/repositories/orgapachecxf-056/org/apache/cxf/apache-cxf/2.1.9
>
> This release is tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.1.9
>
>
> The vote will be open for 72 hours.
>
> Here is my +1.
>
> --
> Daniel Kulp
> dk...@apache.org
> http://www.dankulp.com/blog
>

Re: [VOTE] Release CXF 2.2.6

2010-01-20 Thread Eoghan Glynn

+1

Cheers,
Eoghan

2010/1/20 Freeman Fang 

> +1
>
> Freeman
>
> On 2010-1-20, at 上午9:44, Daniel Kulp wrote:
>
>
>> This is a vote to release CXF 2.2.6
>>
>> Once again, there have been a bunch of bug fixes and enhancements that
>> have been done compared to the 2.2.5 release.   Over 78 JIRA issues
>> are resolved for 2.2.6.
>>
>> List of issues:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12314381&styleName=Html&projectId=12310511&Create=Create
>>
>> The Maven staging area is at:
>> https://repository.apache.org/content/repositories/orgapachecxf-057/
>>
>> The distributions are in:
>>
>> https://repository.apache.org/content/repositories/orgapachecxf-057/org/apache/cxf/apache-cxf/2.2.6
>>
>> This release is tagged at:
>> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.6
>>
>>
>> The vote will be open for 72 hours.
>>
>> Here is my +1.
>>
>>
>> --
>> Daniel Kulp
>> dk...@apache.org
>> http://www.dankulp.com/blog
>>
>
>
> --
> Freeman Fang
> 
> Open Source SOA: http://fusesource.com
>
>

Re: DOSGi deploy failing on Hudson

2009-12-18 Thread Eoghan Glynn

Hmmm ... smells like a Nexus issue.

If I follow that link, I'm redirected to:

https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/cxf/dosgi/cxf-dosgi-remote-service-admin-interfaces/1.0.0/cxf-dosgi-remote-service-admin-interfaces-1.0.0.jar

with the message:
Item not found on path
"/org/apache/cxf/dosgi/cxf-dosgi-remote-service-admin-interfaces/1.0.0/cxf-dosgi-remote-service-admin-interfaces-1.0.0.jar"
in repository "orgapachecxf-001"!This looks a reference to a temporary
staging area created by Nexus, for use for example while a release vote is
in motion (so for the recent dOSGi 1.1 release that I cut, the staging area
was assigned orgapachecxf-021).

Normally when the vote is declared, the staging area would be closed as the
artifacts are promoted. I'd expect the backing storage is discarded by
Nexus.

I don't know why its pointing back to the first CXF staging area ever
created in this case (i.e. the "-001" suffix) but that would have long since
ceased to exist.

Maybe report the issue to the infrastructure folks, or whomever has admin
access to Nexus.

Cheers,
Eoghan


2009/12/18 

> Hi all,
>
> The DOSGi deploy build on Hudson is failing with the following:
>
> [INFO] Error deploying artifact: Authorization failed: Access denied
> to:
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/cxf/dosgi/cxf-dosgi-remote-service-admin-interfaces/1.0.0/cxf-dosgi-remote-service-admin-interfaces-1.0.0.jar
>
> See [1]. Anyone an idea what might be causing this or how to resolve it?
>
> Thanks!
>
> David
>
> [1]
> http://hudson.zones.apache.org/hudson/view/CXF/job/CXF-DOSGi-deploy/81/org.apache.cxf.dosgi$cxf-dosgi-remote-service-admin-interfaces/console
>

Re: Migrating CXF-DOSGi to be complaint with the new OSGi Remote Service Admin spec

2009-12-07 Thread Eoghan Glynn

> Hope everyone is ok with this.

Go for it!

And welcome to the project, Marc.

Cheers,
Eoghan

Re: [VOTE] Cyrille Le Clerc for committer....

2009-12-04 Thread Eoghan Glynn

+1

Cheers,
Eoghan

2009/12/3 Daniel Kulp 

>
>
> Cyrille has submitted several patches to various management and logging
> related things for CXF starting way back in February.   I think he's up to
> 7
> or 8 submitted patches.He's also been hanging around the user list for
> almost a year answering some questions.Thus, I think he's a bit over
> due
> to become a committer.
>
> Here is my +1.
>
> Vote will be open for at least 72 hours.
>
> --
> Daniel Kulp
> dk...@apache.org
> http://www.dankulp.com/blog
>

[RESULT][VOTE] Release CXF dOSGi 1.1

2009-12-01 Thread Eoghan Glynn

Folks,

I'm going to declare this vote as passed, with the following votes cast:

+1 (binding): Sergey Beryozkin, David Bosschaert, Sean O'Callaghan, Ulhas
Bhole, Eoghan Glynn
+1 (non binding): Andres Olarte

I've promoted the artifacts to central and will copy the distributions to
the cxf/dosgi/dist directory.

Cheers,
Eoghan

[VOTE] Release CXF dOSGi 1.1

2009-11-25 Thread Eoghan Glynn

Folks,

I'm calling a vote to release CXF Distributed OSGi 1.1.

The dOSGi subproject of CXF provides the Reference Implementation of the
Remote Services Specification version 1.0, Chapter 13 in the OSGi Compendium
Specification [1].

The release notes contain a description of new features and issues fixed in
this release:


http://svn.apache.org/repos/asf/cxf/dosgi/trunk/distribution/multi-bundle/src/main/release/release_notes.txt

The staging area is at:

  https://repository.apache.org/content/repositories/orgapachecxf-021

The various distributions can be downloaded as follows:

   -   *Source:*
   
https://repository.apache.org/content/repositories/orgapachecxf-021/org/apache/cxf/dosgi/cxf-dosgi-ri-source-distribution/1.1
   -   *Multi-bundle:*
   
https://repository.apache.org/content/repositories/orgapachecxf-021/org/apache/cxf/dosgi/cxf-dosgi-ri-multibundle-distribution/1.1
   -   *Single-bundle:*
   
https://repository.apache.org/content/repositories/orgapachecxf-021/org/apache/cxf/dosgi/cxf-dosgi-ri-singlebundle-distribution/1.1

This release is tagged with cxf-dosgi-ri-1.1 at:

  http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.1

The vote will remain open for at least 72 hours.

Please consider this call to vote as my +1.

Cheers,
Eoghan

[1] http://www.osgi.org/Download/Release4V42

Re: [VOTE] Release CXF 2.1.8 (take 2)

2009-11-17 Thread Eoghan Glynn

+1

/Eoghan

2009/11/15 Daniel Kulp 

>
> This is a vote to release CXF 2.1.8
>
> Once again, there have been a bunch of bug fixes and enhancements that
> have been done compared to the 2.1.7 release.   Over 25 JIRA issues
> are resolved for 2.1.8
>
>
> List of issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12314302&styleName=Html&Create=Create
>
> The Maven staging area is at:
> https://repository.apache.org/content/repositories/orgapachecxf-009/
>
> The distributions are in:
>
> https://repository.apache.org/content/repositories/orgapachecxf-009/org/apache/cxf/apache-cxf/2.1.8
>
> This release is tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.1.8
>
> The vote will be open for 72 hours.
>
> Here is my +1.
>
> --
> Daniel Kulp
> dk...@apache.org
> http://www.dankulp.com/blog
>

Re: [VOTE] Release CXF 2.2.5

2009-11-17 Thread Eoghan Glynn

+1

2009/11/15 Daniel Kulp 

>
> This is a vote to release CXF 2.2.5
>
> Once again, there have been a bunch of bug fixes and enhancements that
> have been done compared to the 2.2.4 release.   Over 90 JIRA issues
> are resolved for 2.2.5
>
>
> List of issues:
>
> The Maven staging area is at:
> https://repository.apache.org/content/repositories/orgapachecxf-008/
>
> The distributions are in:
>
> https://repository.apache.org/content/repositories/orgapachecxf-008/org/apache/cxf/apache-cxf/2.2.5
>
> This release is tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.5
>
> The vote will be open for 72 hours.
>
> I haven't had time to run the TCK on it yet, so I'll vote later, but I
> wanted to get the vote started.
>
> --
> Daniel Kulp
> dk...@apache.org
> http://www.dankulp.com/blog
>

Re: [VOTE] Release CXF 2.1.7

2009-10-09 Thread Eoghan Glynn

+1

/Eoghan

2009/10/8 Daniel Kulp 

>
> This is a vote to release CXF 2.1.7
>
> Once again, there have been a bunch of bug fixes and enhancements that
> have been done compared to the 2.1.6 release.   Over 25 JIRA issues
> are resolved for 2.1.7
>
>
> List of issues:
>
> The Maven staging area is at:
> https://repository.apache.org/content/repositories/cxf-staging-006/
>
> The distributions are in:
>
> https://repository.apache.org/content/repositories/cxf-staging-006/org/apache/cxf/apache-cxf/2.1.7/
>
> This release is tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.1.7
>
>
> Here is my +1.   The vote will be open here for at least 72 hours.
>
>
> --
> Daniel Kulp
> dk...@apache.org
> http://www.dankulp.com/blog
>

Re: [VOTE] Release CXF 2.2.4

2009-10-09 Thread Eoghan Glynn

+1

/Eoghan

2009/10/8 Daniel Kulp 

>
> This is a vote to release CXF 2.2.4
>
> Once again, there have been a bunch of bug fixes and enhancements that
> have been done compared to the 2.2.3 release.   Over 59 JIRA issues
> are resolved for 2.2.4.
>
>
> List of issues:
> https://issues.apache.org/jira/browse/CXF/fixforversion/12314136
>
> The Maven staging area is at:
> https://repository.apache.org/content/repositories/cxf-staging-009/
>
> The distributions are in:
>
> https://repository.apache.org/content/repositories/cxf-staging-009/org/apache/cxf/apache-cxf/2.2.4
>
> This release is tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.4
>
>
> Here is my +1.   The vote will be open here for at least 72 hours.
>
>
> --
> Daniel Kulp
> dk...@apache.org
> http://www.dankulp.com/blog
>

Re: Reliable messaging: Connecting to Oracle

2009-08-31 Thread Eoghan Glynn

Thanks for the patch, Dan. Your efforts are much appreciated.

I've committed the fix just now in r809738.

Cheers,
Eoghan

2009/8/27 Daniel Kulp 

>
> Please file a JIRA and submit the changes as a patch.   This is excellent!
>
> https://issues.apache.org/jira/browse/CXF
>
>
> Dan
>
> On Thu August 27 2009 10:17:52 am Dan Ryazansky wrote:
> > The current version of CXF uses a Derby database when Reliable messaging
> is
> > turned on. However, we required use of ORACLE.
> >
> > I had to make the following changes to to make the code database agnostic
> > in RMTxStore:
> >
> > from
> > "CUR_MSG_NO DECIMAL(31, 0) NOT NULL DEFAULT 1, "
> > to
> > "CUR_MSG_NO DECIMAL(31, 0) DEFAULT 1 NOT NULL, "
> > Derby doesn't care about the order of NOT NULL / DEFAULT, Oracle does
> >
> > from
> > "EXPIRY BIGINT, "
> > to
> > "EXPIRY DECIMAL(31, 0), "
> > Oracle doesn't have BIGINT. DECIMAL is the one data type that seems to
> work
> > across different DBs.
> >
> > from
> > "X0Y32".equals(ex.getSQLState())
> > to
> > "X0Y32".equals(ex.getSQLState()) || 955 == ex.getErrorCode()
> > When checking for table creation (955 is the Oracle error code if the
> table
> > already exists).
> >
> > Is this something that should be committed into the repository?
>
> --
> Daniel Kulp
> dk...@apache.org
> http://www.dankulp.com/blog
>

Re: [VOTE] Release CXF 2.2.3

2009-07-30 Thread Eoghan Glynn

+1

/Eoghan

2009/7/29 Daniel Kulp :
>
> his is a vote to release CXF 2.2.3
>
> Once again, there have been a bunch of bug fixes and enhancements that
> have been done compared to the 2.2.2 release.   Over 86 JIRA issues
> are resolved for 2.2.3.
>
>
> List of issues:
> https://issues.apache.org/jira/browse/CXF/fixforversion/12313983
>
> The Maven staging area is at:
> https://repository.apache.org/content/repositories/cxf-staging-003/
>
> The distributions are in:
> https://repository.apache.org/content/repositories/cxf-staging-003/org/apache/cxf/apache-cxf/2.2.3
>
> This release is tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.3
>
>
> Here is my +1.   The vote will be open here for at least 72 hours.
>
>
> --
> Daniel Kulp
> dk...@apache.org
> http://www.dankulp.com/blog
>

Re: [VOTE] Release CXF 2.1.6

2009-07-30 Thread Eoghan Glynn

+1

/Eoghan

2009/7/29 Daniel Kulp :
>
>
> This is a vote to release CXF 2.1.6
>
> Once again, there have been a bunch of bug fixes and enhancements that
> have been done compared to the 2.1.5 release.   Over 74 JIRA issues
> are resolved for 2.1.6
>
>
> List of issues:
>
> The Maven staging area is at:
> https://repository.apache.org/content/repositories/cxf-staging-002/
>
> The distributions are in:
> https://repository.apache.org/content/repositories/cxf-staging-002/org/apache/cxf/apache-cxf/2.1.6/
>
> This release is tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.1.6
>
>
> Here is my +1.   The vote will be open here for at least 72 hours.
>
> --
> Daniel Kulp
> dk...@apache.org
> http://www.dankulp.com/blog
>

Re: [VOTE] Release CXF 2.0.12

2009-07-30 Thread Eoghan Glynn

 +1

/Eoghan

2009/7/29 Daniel Kulp :
>
> This is a vote to release CXF 2.0.12
>
> Once again, there have been a bunch of bug fixes and enhancements that
> have been done compared to the 2.0.11 release.   Over 32 JIRA issues
> are resolved for 2.0.12
>
> *Note:* as announced earlier this will be the last 2.0.x release of Apache
> CXF.   Users are encouraged to start migrating to 2.2.x.
>
>
> List of issues:
> https://issues.apache.org/jira/browse/CXF/fixforversion/12313903
>
> The Maven staging area is at:
> https://repository.apache.org/content/repositories/cxf-staging-001/
>
> The distributions are in:
> https://repository.apache.org/content/repositories/cxf-staging-001/org/apache/cxf/apache-cxf/2.0.12/
>
> This release is tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.0.12
>
>
> Here is my +1.   The vote will be open here for at least 72 hours.
>
> --
> Daniel Kulp
> dk...@apache.org
> http://www.dankulp.com/blog
>

Re: CXF WorkQueueManager : How to see the mbean on Jboss

2009-07-22 Thread Eoghan Glynn

Note that in order for any CXF MBean to actually be exposed, you'll
have to enable the IntrumentationManager (which is disabled by
default).

See [1] for details.

Cheers,
Eoghan

[1] http://cwiki.apache.org/CXF20DOC/jmx-management.html


2009/7/21 Rao, Sameer V :
> CXF Asynch processing creates a ThreadPool and registers itself as
> MBean. How/Under which object name does that appear in JBossAS4.3
> container?
>

Re: Questions about CXF WS-RM

2009-06-18 Thread Eoghan Glynn

Hi Richard, further comments in-line ...

> IMHO WS-RM 1.1 is the right way to do WS-RM, because this spec.
> addresses unacknowledged anonymous messages use case (see
WS-MakeConnection)
> This usecase wasn't addressed in WS-RM 1.0 and so I consider
> this old RM spec. broken.

Absolutely,  the MakeConnection mechanism is the biggest motivation for
moving to 1.1.

> I don't see the relevant source code for CXF bus integration?

Well the "bus integration" is just the addition of the RM interceptors to
the Bus-level interceptor chains as opposed to the per-endpoint chains.

> Could you give me the pointer to impl or test?

The interceptors can be added explicitly to the Bus-level chains a la:

http://svn.apache.org/viewvc/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/ws/rm/rminterceptors.xml?revision=773965

or implicitly by setting the  feature on the Bus
instance, e.g.:

http://svn.apache.org/viewvc/cxf/trunk/distribution/src/main/release/samples/ws_rm/src/demo/ws_rm/server/ws_rm.xml?view=co

> And how is the integration with other WS-* technologies?

Well WS-RM requires WS-Addressing, so these will always be working together.

What other specific WS-* services did you have in mind?

> I mean do CXF WS-RM support e.g. WS-RM with WS-Security?

I don't believe we've done any specific testing of WS-Security with WS-RM.

Dan may have a better sense of this, but off the top of my head there *may*
be issues with re-transmitted messages (e.g. replay detection may get in the
way, though I guess if the message went un-acknowledged in the first place,
the original message may never have been seen by the WS-Sec layer).

> If I have two RM responses comming from the server (I mean RM responses
with real SOAP response).
> How this is handled? User should take care of that there can be more than
just one async SOAP response?
> What if client will use synchronous JAX-WS api?

There is no problem with a client having multiple outstanding requests to
the same server/endpoint. WS-Addressing message correlation will ensure that
each response is correlated to the corresponding request (requests contain a
 header which is then referenced in the response's
 header). This is true whether the request is made via JAX-WS
async (a purely client-side thread-based mchanism) and/or is decoupled (in
which case the server sends the response over a *separate* server->client
connection). Similarly it would also be true when the WS-RM 1.1
MakeConnection mechanism is supported.

> Well this should be addressed in JAX-WS spec otherwise this would leave to
proprietary client side API
> for manipulating the client RM store. Let's see what will come out with
next metro release. AFAIK
> the Sun folks are working on RM 1.1 at the moment there.

Yes, it would have to be proprietary if the JAX-WS spec doesn't address this
issue.

But when you say "should be addressed in the JAX-WS spec", do you mean in
2.3? I haven't heard that JAX-WS 2.2 will address this.

Cheers,
Eoghan

2009/6/18 Richard Opalka 

> Hi Eoghan,
>
>  see in lined comments below:
>
> Richard
>
> Eoghan Glynn wrote:
>
>> Hi Richard,
>>
>> Apologies for the delay in replying.
>>
> NP
>
>> Please see my comments in-line.
>>
>> 2009/6/15 Richard Opalka :
>>
>>
>>>  what's the current state of CXF WS-RM?
>>>
>>>
>>
>> See below.
>>
>>
>>
>>> I'm asking because we'd like to integrate probably
>>> WS-RM in our JBossWS CXF integration.
>>>
>>>
>>
>> Great that you're thinking of using CXF WS-RM.
>>
>>
>>
>>> The main questions are:
>>> * Which WS-RM specs are supported now (I know about 1.0, is 1.1 supported
>>> already)?
>>>
>>>
>>
>> Only WS-RM 1.0 (2005/02) is supported as yet. This was the current
>> version of the spec when the original RM implementation was done as
>> part of the Celtix project (the precursor to CXF).
>>
>> We've had some interest in WS-RM 1.1 and I intend to do a costing on
>> the implementation effort soon, and hopefully will get the time to
>> implement support for it in the CXF 2.3 timeframe.
>>
>>
> IMHO WS-RM 1.1 is the right way to do WS-RM, because this spec.
> addresses unacknowledged anonymous messages use case (see
> WS-MakeConnection)
> This usecase wasn't addressed in WS-RM 1.0 and so I consider
> this old RM spec. broken.
>
>>
>>
>>> * Is QoS (Quality of Service) ensured in CXF WS-RM implementation?
>>>
>>>
>>
>> Well yes, in so far as the qualities of service envisaged by the WS-RM
>> spec as concerned. So for example

Re: Questions about CXF WS-RM

2009-06-17 Thread Eoghan Glynn

Hi Richard,

Apologies for the delay in replying. Please see my comments in-line.

2009/6/15 Richard Opalka :
>  what's the current state of CXF WS-RM?

See below.

> I'm asking because we'd like to integrate probably
> WS-RM in our JBossWS CXF integration.

Great that you're thinking of using CXF WS-RM.

> The main questions are:
> * Which WS-RM specs are supported now (I know about 1.0, is 1.1 supported
> already)?

Only WS-RM 1.0 (2005/02) is supported as yet. This was the current
version of the spec when the original RM implementation was done as
part of the Celtix project (the precursor to CXF).

We've had some interest in WS-RM 1.1 and I intend to do a costing on
the implementation effort soon, and hopefully will get the time to
implement support for it in the CXF 2.3 timeframe.

> * Is QoS (Quality of Service) ensured in CXF WS-RM implementation?

Well yes, in so far as the qualities of service envisaged by the WS-RM
spec as concerned. So for example the policy with regard to ordering
and duplicates may be asserted via the
/ws-rm-policy:RMAssertion/ws-rm:deliveryAssurance element in config
(see schema[1]).

However other QoS typically available in the MOM world, such as
message expiration/TTL and priority, are not part of WS-RM.

> * Is current CXF WS-RM implementation tightly coupled with Endpoint?

Well, CXF WS-RM can be configured on a per-endpoint basis, or for the
entire Bus.

However, internally the WS-RM layer creates an RMEndpoint for each
org.apache.cxf.endpoint.Endpoint with which a reliable exchange
occurs.

So that sense there is a certain one-to-one-ness going on. Is that
what you meant by being tightly coupled?

Or were you more thinking of using WS-RM to mediate message exchanges
with something other than CXF endpoints?

> * Is there some API for client side when receiving undelivered messages?

By undelivered messages, do you mean un-acknowledged messages that
have been resent?

If the original client is still running, then the retransmitted
response message will be delivered to the application in the normal
way (either by virtue of the invoking client thread being blocked, or
via a callback or pollable for an asynchronous invocation).

However, if the client application has been restarted since the
original request was sent, then there is no way currently for the
resent message to rendez-vous with the application logic. This
deficiency was clear to us when the original RM implementation was
done, and we had at the back of our mind the intention to do something
about it, via some sort of persistent callback mechanism. Any ideas
you might have in this regard would be welcome.

> Where I could find it?
> * Is there some detailed architecture documentation about CXF WS-RM?

No, unfortunately.

Hope this helps,
Eoghan

[1] 
http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/rm/src/main/resources/schemas/configuration/wsrm-manager-types.xsd

Re: CXF Roadmap

2009-06-12 Thread Eoghan Glynn

One thing I've had at the back of my mind is WS-RM 1.1 support.

Is that something that would be of interest to you?

Cheers,
Eoghan

2009/6/12 Richard Opalka :
> Hi CXF Team,
>
>  what's the current CXF roadmap from WS-* point of view?
> What specs are you going to work on next and what is the schedule for them?
> The roadmap as defined here:
>
> http://cxf.apache.org/roadmap.html
>
> just specifies "Other WS-* stuff"
>
> Richard
>
> --
> Richard Opalka
> JBoss Software Engineer
>
> Mail: ropa...@redhat.com
> Mobile: +420 731 186 942
>
>

Re: Integrating JAX-RS runtime into DOSGi

2009-06-12 Thread Eoghan Glynn

2009/6/12 David Bosschaert :
>
> 2009/6/11 Sergey Beryozkin :
> ...
>> The only question I have is where this model info should reside, in
>> META-INF/cxf-dosgi ? I'll check with Favid/Eoghan
>
> We already use OSGI-INF/cxf/intents for our CXF-DOSGi specific intents
> files, so maybe somewhere in the OSGI-INF/cxf area?
>

Yeah, makes sense to gather all the CXF-specific elements under OSGI-INF/cxf.

Maybe scope it further with OSGI-INF/cxf/jaxrs/resources or somesuch.

Cheers,
Eoghan

Re: [VOTE] Alessio Soldano for committer

2009-06-09 Thread Eoghan Glynn

+1

/Eoghan

2009/6/8 Daniel Kulp :
>
> Alessio has been one of the primary driving forces behind getting CXF to be a
> certified JAX-WS provider for JBoss.   As part of that work, he has identified
> several bugs/issues in CXF and has provided patches for many of them.   He has
> also been helping in the communities, especially related to supporting people
> trying to use CXF with JBoss.   In all, he has made significant contributions
> toward making CXF a better products.
>
> Thus, I think he's ready to become a committer.
>
> I'll hold the vote open for at least 72 hours.
>
> Here is my +1.
>
> --
> Daniel Kulp
> dk...@apache.org
> http://www.dankulp.com/blog
>

Re: [VOTE] Release CXF 2.2.2

2009-05-25 Thread Eoghan Glynn

+1

/Eoghan

2009/5/22 Daniel Kulp :
>
> This is a vote to release CXF 2.2.2
>
> With only 23 JIRA's resolved for 2.2.2, this doesn't have as many "fixes" as
> many of the previous patch releases.   HOWEVER, there is a one major new
> feature:   the JAX-RS 1.0 TCK now passes.   Thus, it's worth a release.   :-)
>
>
> List of issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12313901&styleName=Html&projectId=12310511&Create=Create
>
> The staging area is at:
> http://people.apache.org/~dkulp/stage_cxf/2.2.2
>
> The distributions are in the "dist" directory. The "maven" directory
> contains the stuff that will by pushed to the central repository.
>
> This release is tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.2
>
> I'm going to leave the vote open till at least Wednesday due to the long
> holiday weekend in the US and also due to me being on "vacation" next week so
> I'm not sure when I'll have time to close the vote and push the release.
>
> --
> Daniel Kulp
> dk...@apache.org
> http://www.dankulp.com/blog
>
>

RE: [VOTE][RESULT] Release CXF dOSGi 1.0

2009-05-13 Thread Eoghan Glynn

Sorry that should be 7 aye-sayers:

 eglynn, davidb, sberyozkin, seanoc, ubhole, dkulp, jgenender

-Original Message-
From: Eoghan Glynn [mailto:eogl...@gmail.com]
Sent: Wed 13/05/2009 17:44
To: dev@cxf.apache.org
Subject: [VOTE][RESULT] Release CXF dOSGi 1.0

Hi Folks,

I'm going to call this result as carried with six +1s and no dissenting votes.

For the record, the aye-sayers were:

  eglynn, davidb, sberyozkin, ubhole, dkulp, jgenender

Cheers,
Eoghan

[ANN] Apache CXF dOSGi 1.0 released

2009-05-13 Thread Eoghan Glynn

The Apache CXF dOSGi team is proud to announce the availability of our
first full release, 1.0.

The dOSGi subproject of CXF provides the Reference Implementation of
the Distribution Software (DSW) component of the Distributed OSGi
Specification[1].

Download information may be found here[2]

The best starting point for using dOSGi is the Getting Started Guide[3].

Also note the very detailed walk-through of the greeter demo[4].

If you need more help, or want to provide any feedback, please feel
free to drop us a note on the CXF dev or users list[5].

If you trip over any problems with dOSGi, don't hesitate to submit an
issue to the CXF JIRA[6] with the component set to "Distributed-OSGi".

Regards,
The CXF dOSGi team.


[1] See RFC 119 in http://www.osgi.org/download/osgi-4.2-early-draft3.pdf
[2] http://cwiki.apache.org/confluence/display/CXF/DOSGi+Releases
[3] http://cxf.apache.org/distributed-osgi.html#DistributedOSGi-GettingStarted
[4] http://cxf.apache.org/distributed-osgi-greeter-demo-walkthrough.htm
[5] http://cxf.apache.org/mailing-lists.html
[6] https://issues.apache.org/jira/browse/CXF

[VOTE][RESULT] Release CXF dOSGi 1.0

2009-05-13 Thread Eoghan Glynn

Hi Folks,

I'm going to call this result as carried with six +1s and no dissenting votes.

For the record, the aye-sayers were:

  eglynn, davidb, sberyozkin, ubhole, dkulp, jgenender

Cheers,
Eoghan

Re: svn commit: r772651 - in /cxf/dosgi/trunk/distribution/multi-bundle/src/main/xsl: equinox_distro_config.xslt felix_distro_config.xslt

2009-05-07 Thread Eoghan Glynn

2009/5/7 Daniel Kulp :
>
> Eoghan,
>
> Could the version be passed into the xslt via an xslt param?   That would
> avoid needing to modify it as part of the builds and such.
>
> Dan


Yeah, sure it could.

The literal version in the xslt was just a quick'n'dirty fix for a
minor issue in the OSGi container config snippets that I noticed right
on the cusp of cutting the take 2 release.

I'll replace it with something more maintainable.

/Eoghan

[VOTE] Release CXF dOSGi 1.0 (take 2)

2009-05-07 Thread Eoghan Glynn

Folks,

I'm calling a second vote to release CXF Distributed OSGi 1.0.

The main differences between this and the first take are:

  - addition of a sources distro
  - LICENSE file now contains references to licenses for 3rd party dependencies
  - removal of extraneous NOTICEs
  - addition of top-level READMEs
  - fix for algorithm used to compute DiscoveredServiceTracker property deltas
  - fix for name clash on some osgi.remote.* properties

The distributions are staged at:

  http://people.apache.org/~eglynn/stage_cxf_dosgi/dist

and the maven artifacts at:

  http://people.apache.org/~eglynn/stage_cxf_dosgi/maven

This release is tagged with cxf-dosgi-ri-1.0 at:

  http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.0

The vote will remain open for at least 72 hours.

Please consider this call to vote as my +1.

Cheers,
Eoghan

Re: [VOTE] Release CXF dOSGi 1.0

2009-05-06 Thread Eoghan Glynn

Thanks Dan, should be sorted in this latest commit:

http://svn.apache.org/viewvc?rev=772302&view=rev

/Eoghan

2009/5/6 Daniel Kulp :
>
>
> Pretty close.   Just mentioned on IRC that the source distro needs the
> LICENSE/NOTICE things.   Other than that, looks much better.
>
> Thanks!
> Dan
>
>
> On Wed May 6 2009 9:10:18 am Eoghan Glynn wrote:
>> 2009/5/5 Daniel Kulp :
>> > OK.   That kind of make sense (along with what Eoghan said).
>> >
>> > However, I really think there needs to at least be a "README" in the
>> > distributions that describes a little what it is along with pointers to
>> > the walkthroughs and such on the website.
>>
>> I've added a README with an overview of the different distros and
>> pointers to getting started docco, mailing lists, JIRA etc:
>>
>> http://svn.apache.org/viewvc/cxf/dosgi/trunk/distribution/multi-bundle/src/
>>main/release/README?view=markup
>>
>> I've also addressed your other concerns in these two commits:
>>
>> http://svn.apache.org/viewvc?rev=772157&view=rev
>> http://svn.apache.org/viewvc?rev=771670&view=rev
>>
>> So I think we should be good to go with a second cut at this release.
>>
>> Cheers,
>> Eoghan
>>
>> 2009/5/5 Daniel Kulp :
>> > OK.   That kind of make sense (along with what Eoghan said).
>> >
>> > However, I really think there needs to at least be a "README" in the
>> > distributions that describes a little what it is along with pointers to
>> > the walkthroughs and such on the website.
>> >
>> > Right now, I download and unpack the the tarball and I look at it and say
>> > "uhh.  what do I do with this?"    We definitely need a readme in
>> > there to describe things as well as provide pointers off to the web site,
>> > the users@ list for questions, etc.
>> >
>> > Dan
>> >
>> > On Tue May 5 2009 5:31:49 am David Bosschaert wrote:
>> >> Hi Dan,
>> >>
>> >> On the samples, they are not part of the distribution because they can
>> >> be installed straight from the internet. All of the DOSGi
>> >> documentation is available here:
>> >> http://cxf.apache.org/distributed-osgi.html and which contains links
>> >> to the sample source code and a very detailed walkthrough of the
>> >> greeter sample:
>> >> http://cxf.apache.org/distributed-osgi-greeter-demo-walkthrough.html
>> >> As the OSGi containers install stuff straight from the internet, you
>> >> don't have to have the bundles available locally. Once the release is
>> >> out I'm planning to update this page to point straight to the sample
>> >> artefacts in maven.
>> >>
>> >> There is no such page for the spring-dm demo, I'll take an action to
>> >> provide such a page with the DOSGi documentation, but I don't think
>> >> this should hold up the release.
>> >>
>> >> Hope this makes sense to you,
>> >>
>> >> David
>> >>
>> >> 2009/5/4 Daniel Kulp :
>> >> > I think I have to -1 this.   Couple legal things need to get ironed
>> >> > out:
>> >> >
>> >> > 1)  Since this is a full "distribution" type thing, what parts of that
>> >> > staging area will go into www.apache.org/dist/cxf?     I ASSUME the
>> >> > mutimodule bundle, but not really sure.     Also, there needs to be a
>> >> > tar.gz or zip of a "source" distribution of the whole contents of the
>> >> > tag.    That would also go into dist.
>> >> >
>> >> > 2)  I think some stuff in the NOTICE can be removed.   For example:
>> >> > DOSGi doesn't ship the MTOSI stuff, that could be removed.   Not
>> >> > major, but if a build has to be respun, let's get that cleaned up.
>> >> >
>> >> > 3) For the "distribution" builds, the LICENSE file needs to have at
>> >> > least the pointers to the LICENSES of the bundled deps appended to it.
>> >> >   See the LICENSE in the cxf distributions.   (remote-resources can do
>> >> > that, I may be able to help out tomorrow if I get out from under my
>> >> > backlog of email.  :-(   )
>> >> >
>> >> > 4) Actually, IS there a distribution that includes the samples,
>> >> > possible a readme, etc...?     Should the

Re: [VOTE] Release CXF dOSGi 1.0

2009-05-06 Thread Eoghan Glynn

2009/5/5 Daniel Kulp :
>
> OK.   That kind of make sense (along with what Eoghan said).
>
> However, I really think there needs to at least be a "README" in the
> distributions that describes a little what it is along with pointers to the
> walkthroughs and such on the website.


I've added a README with an overview of the different distros and
pointers to getting started docco, mailing lists, JIRA etc:

http://svn.apache.org/viewvc/cxf/dosgi/trunk/distribution/multi-bundle/src/main/release/README?view=markup

I've also addressed your other concerns in these two commits:

http://svn.apache.org/viewvc?rev=772157&view=rev
http://svn.apache.org/viewvc?rev=771670&view=rev

So I think we should be good to go with a second cut at this release.

Cheers,
Eoghan


2009/5/5 Daniel Kulp :
>
> OK.   That kind of make sense (along with what Eoghan said).
>
> However, I really think there needs to at least be a "README" in the
> distributions that describes a little what it is along with pointers to the
> walkthroughs and such on the website.
>
> Right now, I download and unpack the the tarball and I look at it and say
> "uhh.  what do I do with this?"    We definitely need a readme in there to
> describe things as well as provide pointers off to the web site, the users@
> list for questions, etc.
>
> Dan
>
>
>
> On Tue May 5 2009 5:31:49 am David Bosschaert wrote:
>> Hi Dan,
>>
>> On the samples, they are not part of the distribution because they can
>> be installed straight from the internet. All of the DOSGi
>> documentation is available here:
>> http://cxf.apache.org/distributed-osgi.html and which contains links
>> to the sample source code and a very detailed walkthrough of the
>> greeter sample:
>> http://cxf.apache.org/distributed-osgi-greeter-demo-walkthrough.html
>> As the OSGi containers install stuff straight from the internet, you
>> don't have to have the bundles available locally. Once the release is
>> out I'm planning to update this page to point straight to the sample
>> artefacts in maven.
>>
>> There is no such page for the spring-dm demo, I'll take an action to
>> provide such a page with the DOSGi documentation, but I don't think
>> this should hold up the release.
>>
>> Hope this makes sense to you,
>>
>> David
>>
>> 2009/5/4 Daniel Kulp :
>> > I think I have to -1 this.   Couple legal things need to get ironed out:
>> >
>> > 1)  Since this is a full "distribution" type thing, what parts of that
>> > staging area will go into www.apache.org/dist/cxf?     I ASSUME the
>> > mutimodule bundle, but not really sure.     Also, there needs to be a
>> > tar.gz or zip of a "source" distribution of the whole contents of the
>> > tag.    That would also go into dist.
>> >
>> > 2)  I think some stuff in the NOTICE can be removed.   For example: DOSGi
>> > doesn't ship the MTOSI stuff, that could be removed.   Not major, but if
>> > a build has to be respun, let's get that cleaned up.
>> >
>> > 3) For the "distribution" builds, the LICENSE file needs to have at least
>> > the pointers to the LICENSES of the bundled deps appended to it.   See
>> > the LICENSE in the cxf distributions.   (remote-resources can do that, I
>> > may be able to help out tomorrow if I get out from under my backlog of
>> > email.  :-(   )
>> >
>> > 4) Actually, IS there a distribution that includes the samples, possible
>> > a readme, etc...?     Should there be?   Not a big deal either way, but a
>> > bit strange.
>> >
>> >
>> > Dan
>> >
>> > On Fri May 1 2009 12:39:48 pm Eoghan Glynn wrote:
>> >> Folks,
>> >>
>> >> I'm calling a vote to release CXF Distributed OSGi 1.0.
>> >>
>> >> The dOSGi subproject of CXF provides the Reference Implementation of
>> >> the Distribution Software (DSW) component of the Distributed OSGi
>> >> Specification[1].
>> >>
>> >> The staging area can be found at:
>> >>
>> >>   http://people.apache.org/~eglynn/stage_cxf_dosgi
>> >>
>> >> This release is tagged with cxf-dosgi-ri-1.0 at:
>> >>
>> >>   http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.0
>> >>
>> >> The vote will remain open for at least 72 hours.
>> >>
>> >> Please consider this call to vote as my +1.
>> >>
>> >> Cheers,
>> >> Eoghan
>> >>
>> >> [1] See RFC 119 in
>> >> http://www.osgi.org/download/osgi-4.2-early-draft3.pdf
>> >
>> > --
>> > Daniel Kulp
>> > dk...@apache.org
>> > http://www.dankulp.com/blog
>
> --
> Daniel Kulp
> dk...@apache.org
> http://www.dankulp.com/blog
>

Fwd: [VOTE] Release CXF dOSGi 1.0

2009-05-05 Thread Eoghan Glynn

Sent this earlier to dkulp individually, I meant to reply-all.

-- Forwarded message --
From: Eoghan Glynn 
Date: 2009/5/5 10:13
Subject: Re: [VOTE] Release CXF dOSGi 1.0
To: Daniel Kulp 

2009/5/4 Daniel Kulp :
> On Mon May 4 2009 5:30:49 pm Eoghan Glynn wrote:
>
>> On issue #4, I'm of a mind to just pull in the samples bundles
>> directly in from maven. This is especially convenient when using the
>> Pax URL mvn protocol, allowing a mvn:groupId:artifactId:version style
>> of URL to referenced directly from the OSGi shell. This would be the
>> most natural approach for SMX4 in any case (BTW I'm planning to wrap
>> dOSGi up as a couple of SMX4 features, which would add another layer
>> of convenience).
>
> Well, part of the purpose of a "sample" is to provide the CODE for the sample
> so they can see how it works, modify it, learn from it, etc... Pulling the
> existing stuff from maven kind of defeats that purpose, does it not?

Well no, I wouldn't say it defeats the purpose. The demo is described
in a very detailed walkthrough on the wiki[1] with links into SVN for
browsing the code. I think this is sufficient for understanding and
learning etc.

Note the dOSGi samples are a bit different from the core CXF demos in
that the emphasis is on the simplicity of enabling pre-existing OSGi
code for distribution. So the actual application code is really of
secondary importance. The crucial thing is the few knobs that need to
be set in order to transparently expose or consume an OSGi service as
a remote web service.

Cheers,
Eoghan

[1] http://cxf.apache.org/distributed-osgi-greeter-demo-walkthrough.html

[VOTE] Release CXF dOSGi 1.0

2009-05-01 Thread Eoghan Glynn

Folks,

I'm calling a vote to release CXF Distributed OSGi 1.0.

The dOSGi subproject of CXF provides the Reference Implementation of
the Distribution Software (DSW) component of the Distributed OSGi
Specification[1].

The staging area can be found at:

  http://people.apache.org/~eglynn/stage_cxf_dosgi

This release is tagged with cxf-dosgi-ri-1.0 at:

  http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.0

The vote will remain open for at least 72 hours.

Please consider this call to vote as my +1.

Cheers,
Eoghan

[1] See RFC 119 in http://www.osgi.org/download/osgi-4.2-early-draft3.pdf

Re: Need Help with JAX-WS and JAX-RS example

2009-04-29 Thread Eoghan Glynn

What sort of failure are you seeing?


2009/4/29 cybercxf :
>
> I did but I am not sure if I am using right annotations of Restful services.
> Can you verify that for me by taking a look at the code I had attached in
> my first post.
>
> thanks.

Re: Need Help with JAX-WS and JAX-RS example

2009-04-29 Thread Eoghan Glynn

BTW to answer the other part of your question, it is possible use the
JAX-RS and JAX-WS annotations on the same implementation class.

See the BookStoreJaxrsJaxws[1] system test for an example.

Cheers,
Eoghan

[1] 
http://svn.apache.org/repos/asf/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/jaxrs/BookStoreJaxrsJaxws.java

2009/4/29 Eoghan Glynn :
> I'd suspect you've a mismatch between the version of
> cxf-rt-frontend-jaxrs and the cxf-api jars.
>
> The former depends on the Message.REQUEST_URI field, which is defined
> in the latter.
>
> This field was introduced on 2008-10-21, so you'll need a version of
> the API jar from after this date (2.0.10/2.1.4/2.2 or later).
> Preferably exactly the same version as you use for the JAX-RS stuff.
>
> Cheers,
> Eoghan
>
> 2009/4/29 cybercxf :
>>
>> When I run the RestClient.java, it is giving me error
>>
>> java.lang.NoSuchFieldError: REQUEST_URI
>>
>> Can someone help me, what should be the @Path. Is the code for using the
>> same service class (HelloWorldImpl.java) for both JAX-WS, JAX-RS?
>>
>> Please see all the code below and let me know.
>>
>> thanks.
>>
>>
>> Code
>> 
>>
>>
>> HelloWorld.java (Inteface)
>> ===
>>
>> import javax.jws.WebParam;
>> import javax.jws.WebService;
>> import javax.jws.WebParam.Mode;
>>
>> @WebService(name = "HelloWorld")
>> public interface HelloWorld {
>>void receive(@WebParam(name = "itemXML", mode = Mode.IN) String 
>> itemXML);
>> }
>>
>> HelloWorldImpl.java
>> ==
>>
>> import javax.jws.WebMethod;
>> import javax.jws.WebService;
>> import javax.ws.rs.Consumes;
>> import javax.ws.rs.POST;
>> import javax.ws.rs.Path;
>> import javax.ws.rs.PathParam;
>>
>> @Path("/HelloWorld")
>> @WebService(endpointInterface = "org.openpipeline.services.HelloWorld",
>> serviceName = "HelloWorld")
>> @Consumes("application/xml")
>> public class HelloWorldImpl implements HelloWorld{
>>@WebMethod
>>@POST
>>@Path("/receive")
>>public void receive(@PathParam("*/*")String itemXML) {
>>System.out.println(itemXML);
>>}
>> }
>>
>> Server.java
>> 
>>
>> import org.apache.cxf.jaxrs.JAXRSServerFactoryBean;
>> import org.apache.cxf.jaxrs.lifecycle.SingletonResourceProvider;
>> import org.apache.cxf.jaxws.JaxWsServerFactoryBean;
>>
>> public class Server {
>>public static void main(String[] args){
>>HelloWorldImpl implementor = new HelloWorldImpl();
>>
>>/*
>> * Start JAX-WS service
>> */
>>JaxWsServerFactoryBean svrFactory = new 
>> JaxWsServerFactoryBean();
>>svrFactory.setServiceClass(HelloWorld.class);
>>svrFactory.setAddress("http://localhost:9000/";);
>>svrFactory.setServiceBean(implementor);
>>svrFactory.create();
>>
>>/*
>> * Start JAX-RS service
>> */
>>JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
>>sf.setResourceClasses(HelloWorldImpl.class);
>>sf.setResourceProvider(HelloWorldImpl.class,
>>new SingletonResourceProvider(new HelloWorldImpl()));
>>sf.setAddress("http://localhost:9001/";);
>>
>>sf.create();
>>
>>}
>> }
>>
>>
>> RestClient.java
>> 
>>
>> import org.apache.commons.httpclient.HttpClient;
>> import org.apache.commons.httpclient.methods.PostMethod;
>> import org.apache.commons.httpclient.methods.RequestEntity;
>> import org.apache.commons.httpclient.methods.StringRequestEntity;
>>
>> public class RestClient {
>>
>>public static void main(String args[]) throws Exception {
>>
>>PostMethod post = new
>> PostMethod("http://localhost:9001/HelloWorld/receive/";);
>>post.addRequestHeader("Accept", "application/xml");
>>RequestEntity entity = new StringRequestEntity("Hello 
>> REST!",
>> "application/xml", "ISO-8859-1");
>>post.setRequestEntity(entity);
>>HttpClient httpclient = new HttpClient();
>>
>>

Re: Need Help with JAX-WS and JAX-RS example

2009-04-29 Thread Eoghan Glynn

I'd suspect you've a mismatch between the version of
cxf-rt-frontend-jaxrs and the cxf-api jars.

The former depends on the Message.REQUEST_URI field, which is defined
in the latter.

This field was introduced on 2008-10-21, so you'll need a version of
the API jar from after this date (2.0.10/2.1.4/2.2 or later).
Preferably exactly the same version as you use for the JAX-RS stuff.

Cheers,
Eoghan

2009/4/29 cybercxf :
>
> When I run the RestClient.java, it is giving me error
>
> java.lang.NoSuchFieldError: REQUEST_URI
>
> Can someone help me, what should be the @Path. Is the code for using the
> same service class (HelloWorldImpl.java) for both JAX-WS, JAX-RS?
>
> Please see all the code below and let me know.
>
> thanks.
>
>
> Code
> 
>
>
> HelloWorld.java (Inteface)
> ===
>
> import javax.jws.WebParam;
> import javax.jws.WebService;
> import javax.jws.WebParam.Mode;
>
> @WebService(name = "HelloWorld")
> public interface HelloWorld {
>void receive(@WebParam(name = "itemXML", mode = Mode.IN) String 
> itemXML);
> }
>
> HelloWorldImpl.java
> ==
>
> import javax.jws.WebMethod;
> import javax.jws.WebService;
> import javax.ws.rs.Consumes;
> import javax.ws.rs.POST;
> import javax.ws.rs.Path;
> import javax.ws.rs.PathParam;
>
> @Path("/HelloWorld")
> @WebService(endpointInterface = "org.openpipeline.services.HelloWorld",
> serviceName = "HelloWorld")
> @Consumes("application/xml")
> public class HelloWorldImpl implements HelloWorld{
>@WebMethod
>@POST
>@Path("/receive")
>public void receive(@PathParam("*/*")String itemXML) {
>System.out.println(itemXML);
>}
> }
>
> Server.java
> 
>
> import org.apache.cxf.jaxrs.JAXRSServerFactoryBean;
> import org.apache.cxf.jaxrs.lifecycle.SingletonResourceProvider;
> import org.apache.cxf.jaxws.JaxWsServerFactoryBean;
>
> public class Server {
>public static void main(String[] args){
>HelloWorldImpl implementor = new HelloWorldImpl();
>
>/*
> * Start JAX-WS service
> */
>JaxWsServerFactoryBean svrFactory = new 
> JaxWsServerFactoryBean();
>svrFactory.setServiceClass(HelloWorld.class);
>svrFactory.setAddress("http://localhost:9000/";);
>svrFactory.setServiceBean(implementor);
>svrFactory.create();
>
>/*
> * Start JAX-RS service
> */
>JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
>sf.setResourceClasses(HelloWorldImpl.class);
>sf.setResourceProvider(HelloWorldImpl.class,
>new SingletonResourceProvider(new HelloWorldImpl()));
>sf.setAddress("http://localhost:9001/";);
>
>sf.create();
>
>}
> }
>
>
> RestClient.java
> 
>
> import org.apache.commons.httpclient.HttpClient;
> import org.apache.commons.httpclient.methods.PostMethod;
> import org.apache.commons.httpclient.methods.RequestEntity;
> import org.apache.commons.httpclient.methods.StringRequestEntity;
>
> public class RestClient {
>
>public static void main(String args[]) throws Exception {
>
>PostMethod post = new
> PostMethod("http://localhost:9001/HelloWorld/receive/";);
>post.addRequestHeader("Accept", "application/xml");
>RequestEntity entity = new StringRequestEntity("Hello 
> REST!",
> "application/xml", "ISO-8859-1");
>post.setRequestEntity(entity);
>HttpClient httpclient = new HttpClient();
>
>try {
>int result = httpclient.executeMethod(post);
>System.out.println("Response status code: " + result);
>System.out.println("Response body: ");
>} finally {
>// Release current connection to the connection pool 
> once you are
>// done
>post.releaseConnection();
>}
>
>System.out.println("\n");
>System.exit(0);
>}
> }
>
> Client.java
> 
>
> public class Client {
>public static void main(String[] args){
>JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
>factory.getInInterceptors().add(new LoggingInInterceptor());
>factory.getOutInterceptors().add(new LoggingOutInterceptor());
>factory.setServiceClass(HelloWorld.class);
>
>factory.setAddress("http://localhost:9000/HelloWorld";);
>HelloWorld client = (HelloWorld) factory.create();
>Item item = new Item();
>item.importXML("Hello");
>client.receive(item.toString());
>}
> }
>
> --
> View this message in context: 
> http://www.nabble.com/Need-Help-with-JAX-WS-and-JAX-RS-example-tp23287998p23287998.html
> Sent

Re: A rather crazy idea for a feature

2009-04-28 Thread Eoghan Glynn

Hi Benson,

Do you mean using an NIO MappedByteBuffer?

That would be an interesting thing to look at doing.

Obviously limiting it to MTOM attachments sortta simplifies things,
but of course there's also the possibility to go the whole hog and
write a full-blown transport based on shared memory. Now in a previous
life, I had great fun adding NIO support to a commercial CORBA ORB.
One lesson learned from the experience was that to fully leverage the
potential efficiency gains from NIO, one must marshall *directly* into
an NIO buffer as opposed to some intermediate representation. So for a
full-blown transport option, we would probably need to layer a
java.io.{In|Out}Stream implementation over the NIO buffer to
facilitate efficient StAX-based (parse|write} of the XML. Also some
carefull thought would need to be put into the impact of asynchrony on
the read side, dealing with the partial availability of data for
incoming events etc. In the CORBA case there was lots of complexity
around alignment and boundaries in the encoding and non-atomic reads
of primitives, but I guess all that would be avoided in this case as
it sort of fell out from the binary nature of the GIOP protocol.

Cheers,
Eoghan


2009/4/28 Benson Margulies :
> Imagine a CXF extension to MTOM that used shared memory to move the
> attachment. The bytes from the DataSource or whatever would be pushed into a
> mapped file, and the client would map the same file. Maybe this is just the
> file: URL as the MTOM identifier, and the mapping of the file is just an
> opimization on top of that.
>

Re: [VOTE] Release CXF 2.2.1

2009-04-23 Thread Eoghan Glynn

+1

/Eoghan

Re: [VOTE] Release CXF 2.1.5

2009-04-23 Thread Eoghan Glynn

+1

/Eoghan

Re: [VOTE] Release Apache CXF 2.0.11

2009-04-23 Thread Eoghan Glynn

+1

/Eoghan

Re: Convert a message from saaj to cxf?

2009-04-16 Thread Eoghan Glynn

Internally in the CXF stack, usually we need to convert the other way
round, i.e. to populate the SAAJ model if its required for example
when a JAX-WS SOAPHandler is installed. This conversion is the
responsibility of the SAAJ{In|Out}Interceptor[1] classes.

However in your case, rather than doing a straight conversion from
SAAJ SOAPMessage to CXF SoapMessage, I wonder could you just wrap the
former inside the latter.

By that I mean create a wrapper class that extends
org.apache.cxf.binding.soap.SoapMessage, but delegates to an embedded
SAAJ SOAPMessage instance where appropriate. So for example
SoapMessage.getHeaders() would map onto
SOAPMessage.getSOAPHeader().examineAllHeaderElements() with mediation
between the CXF SoapHeader type and the corresponding SAAJ
SOAPHeaderElement. I'm not sure if there such a direct correspondence
for everything you'll need, but it might be an idea worth exploring.

Cheers,
Eoghan

[1] 
http://svn.apache.org/repos/asf/cxf/trunk/rt/bindings/soap/src/main/java/org/apache/cxf/binding/soap/saaj/SAAJInInterceptor.java
http://svn.apache.org/repos/asf/cxf/trunk/rt/bindings/soap/src/main/java/org/apache/cxf/binding/soap/saaj/SAAJOutInterceptor.java

2009/4/16 Kid_79 :
>
> Hi all,
> I'm trying to use cxf for my security.
>
> It's possible converts a saaj's message (javax.xml.soap.SOAPMessage) in to
> cxf's message (org.apache.cxf.binding.soap.SoapMessage)?
>
> Can you help me?
> Thanks
> --
> View this message in context: 
> http://www.nabble.com/Convert-a-message-from-saaj-to-cxf--tp23074793p23074793.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>
>

Re: Distributed OSGi Discovery implementation in CXF

2009-04-10 Thread Eoghan Glynn

2009/4/10 Sergey Beryozkin :
> Would it still make sense to keep the Local Discovery service implementation
> ? For ex to test against multiple Discovery instances ?

I think we definitely need to keep the local discovery service intact
in order to support the static remote-services.xml style of
configuration.

Cheers,
Eoghan

Re: Distributed OSGi Discovery implementation in CXF

2009-04-10 Thread Eoghan Glynn

Hi David,

This would be a very welcome addition to the distributed OSGi support in CXF!

So please, fire away and commit what you've done so far.

Thanks,
Eoghan

2009/4/10 David Bosschaert :
> Hi all,
>
> Over the past while I have done some experimentation around a possible
> implementation of the Distributed OSGi RFC 119 Discovery service.
>
> The current CXF-DOSGi codebase only contains the Distribution Software
> (DSW) component, which means that you need to configure the location
> of your remote services manually. Adding a Discovery service (as
> specified in RFC 119) would enable dynamic discovery of remote
> services as well.
>
> I've started using Apache Zookeeper as the underlying technology to
> implement a Discovery service and at this stage I have it working,
> although what I have is not completely finished.
>
> I think this could be a useful addition to the CXF DOSGi codebase, as
> together with the DSW code that's already there it would provide the
> implementation of the two core parts of RFC 119.
> If folks agree that this is useful to have, I can start contributing
> this to the http://svn.apache.org/repos/asf/cxf/dosgi/trunk/discovery
> and continue working on it from that location.
>
> Thoughts anyone?
>
> Cheers,
>
> David
>

Re: Working towards a DOSGi 1.0 release

2009-03-26 Thread Eoghan Glynn

Hi David,

On the general point, I definitely agree that we need to be thinking about a
1.0 release.

On the specifics ...

> * We need to make sure that all the API's we are using are exactly
> correct with the lasted RFC 119 version, e.g. I think we need to add
> something to the ServicePublication interface...

In my commit last week (r756476), I updated ServicePublication to the latest
version from the OSGi SVN, so I think we're good on that score.

However as yet we don't actually do anything specific with the
remote-versioning mechanism defined in ServicePublication, i.e. the funky
service.interface.version="org.foo.bar|1.0.0.1 org.sna.fu|2.1" property. I'm
not sure though as to how much explicit mediation with this property
setting, if any, would be required by the DSW on the consumer side. So we'll
need to figure that out, and for completeness propbably do a bit of an audit
against the final 119 version to ensure we're in good shape otherwise.

Cheers,
Eoghan


2009/3/26 

> Hi all,
>
> Since CXF 2.2 is out now I was thinking about what work needs to be
> done for a DOSGi 1.0 release.
>
> I've just updated the poms to depend on CXF 2.2, but there's still a
> few things to do...
>
> * there is CXF-1966. It would be good to get a solution to this. I
> heard that Spring-DM 1.2.0 is going to be released within 2 weeks and
> that version should work with Felix 1.4.1, so I'm considering removing
> the checked in Equinox jar and moving to 1.2.0-RC1 using Felix for the
> moment until we can depend on Spring-DM 1.2.0. Are folks generally ok
> with that? Once Equinox 3.5 is released, maybe we can add it back in
> to system test runs as a second platform, by obtaining it from maven
> or wget or something once its available in a fixed place...
> * We need to make sure that all the API's we are using are exactly
> correct with the lasted RFC 119 version, e.g. I think we need to add
> something to the ServicePublication interface...
>
> Anything else we need to think of?
>
> Cheers,
>
> David
>

RE: [VOTE] Release Apache CXF 2.2

2009-03-18 Thread Eoghan Glynn

+1

-Original Message-
From: Daniel Kulp [mailto:dk...@apache.org]
Sent: Sun 15/03/2009 18:57
To: dev@cxf.apache.org
Subject: [VOTE] Release Apache CXF 2.2

This is a vote to release CXF 2.2

This release is a major step forward for CXF with several new features 
including:
 * WS-SecurityPolicy support
 * WS-SecureConversation
 * Some WS-Trust support (client side)
 * JAX-RS 1.0 
along with MANY other improvements and enhancements.

The staging area is at:
http://people.apache.org/~dkulp/stage_cxf/2.2

The distributions are in the "dist" directory. The "maven" directory
contains the stuff that will by pushed to the central repository.

This release is tagged at:
http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.2

Here is my +1.   The vote will be open here for at least 72 hours.

-- 
Daniel Kulp
dk...@apache.org
http://www.dankulp.com/blog

comet & CXF

2009-03-05 Thread Eoghan Glynn


Hi Folks,

A quick question, has anyone come across a requirement or interest in any sort 
of cometd or Bayeux integration in CXF?

Cheers,
Eoghan

RE: svn commit: r748171 - in /cxf/trunk/systests/src/test/java/org/apache/cxf/systest/ws/addressing: GreeterImpl.java MAPTest.java

2009-02-26 Thread Eoghan Glynn



Thanks Dan,

I'll disable this for now and move the Jetty thread pool stuff to a separate 
test.

/Eoghan


-Original Message-
From: Daniel Kulp [mailto:dk...@apache.org]
Sent: Thu 26/02/2009 16:04
To: dev@cxf.apache.org
Cc: egl...@apache.org
Subject: Re: svn commit: r748171 - in 
/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/ws/addressing: 
GreeterImpl.java MAPTest.java
 


Eoghann,

I'm getting a bunch of random issues with this test now.   Sometimes it works
fine. However, I'm also getting some stack traces, test failures, etc.
on occasion.   Example:

---
 T E S T S 
---
Running org.apache.cxf.systest.ws.addressing.MAPTest   
Exception in thread "Thread-2" javax.xml.ws.soap.SOAPFaultException: Fault 
string, and possibly fault code, not set
at 
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:144) 

at $Proxy48.greetMeLater(Unknown Source)
   
at org.apache.cxf.systest.ws.addressing.MAPTest$1.run(MAPTest.java:73)  
   
at java.lang.Thread.run(Thread.java:595)
   
Caused by: java.lang.NullPointerException   
   
at 
org.apache.cxf.systest.ws.addressing.HeaderVerifier.verify(HeaderVerifier.java:130)
 
at 
org.apache.cxf.systest.ws.addressing.HeaderVerifier.mediate(HeaderVerifier.java:83)
 
at 
org.apache.cxf.systest.ws.addressing.HeaderVerifier.handleMessage(HeaderVerifier.java:71)
   
at 
org.apache.cxf.systest.ws.addressing.HeaderVerifier.handleMessage(HeaderVerifier.java:1)

at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
  
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:641)
   
at 
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2106)
at 
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1985)

at 
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1910)
 
at 
org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66) 
   
at 
org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:609)   
   
at 
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)

at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:469)   
 
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:299)   
 
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:251)   
 
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)  
 
at 
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:123) 
  
... 3 more  
 
Tests run: 8, Failures: 0, Errors: 0, Skipped: 3, Time elapsed: 30.047 sec 


Another run:
---
 T E S T S 
---
Running org.apache.cxf.systest.ws.addressing.MAPTest   
Tests run: 8, Failures: 1, Errors: 0, Skipped: 3, Time elapsed: 13.876 sec <<< 
FAILURE!
testFallbackThreadPoolConfig(org.apache.cxf.systest.ws.addressing.MAPTest)  
Time elapsed: 5.89 sec  <<< FAILURE!
java.lang.AssertionError: unexpected duration: 5873 

at org.junit.Assert.fail(Assert.java:74)

at org.junit.Assert.assertTrue(Assert.java:37)  

at 
org.apache.cxf.systest.ws.addressing.MAPTest.testFallbackThreadPoolConfig(MAPTest.java:87)
   
at sun.reflect.NativeMethodAccessorIm

RE: [VOTE] Andrzej Michalec for committer

2009-02-17 Thread Eoghan Glynn


+1

/Eoghan

RE: [VOTE] Release Apache CXF 2.1.4 (Take 2)

2009-02-06 Thread Eoghan Glynn

+1

RE: [VOTE] Release CXF 2.0.10 (Take 2)

2009-02-06 Thread Eoghan Glynn

+1

RE: [VOTE] Release CXF 2.0.10

2009-02-04 Thread Eoghan Glynn




+1

/Eoghan

RE: [VOTE] Release Apache CXF 2.1.4

2009-02-04 Thread Eoghan Glynn



+1 

/Eoghan

propagation of trunk commits to 2.0.x-fixes

2009-01-19 Thread Eoghan Glynn


Folks,

Are commits to trunk still propagated to 2.0.x-fixes, or is it just 2.1.x-fixes 
that's actively maintained now?

Cheers,
Eoghan

RE: http://cxf.apache.org/schemas/core.xsd out of date

2009-01-07 Thread Eoghan Glynn


The id attribute seems to be visible now on 
http://cxf.apache.org/schemas/core.xsd

/Eoghan

-Original Message-
From: David Bosschaert [mailto:david.bosscha...@gmail.com]
Sent: Wed 07/01/2009 14:04
To: dev@cxf.apache.org
Subject: Re: http://cxf.apache.org/schemas/core.xsd out of date
 
Thanks - I copied the file to /www/cxf.apache.org/schemas
It's not yet visible on http://cxf.apache.org/schemas/core.xsd, I
assume it will have to be replicated there by some process?

Cheers,

David

2009/1/7 Benson Margulies :
> Any committer has access to copy a new version on people.apache.org, I think.
>
> On Wed, Jan 7, 2009 at 7:00 AM, David Bosschaert
>  wrote:
>> Hi all,
>>
>> The XML Schema at http://cxf.apache.org/schemas/core.xsd is different
>> from what is in SVN
>> (http://svn.apache.org/viewvc/cxf/trunk/rt/core/src/main/resources/schemas/core.xsd?view=markup).
>> Specifically, it's missing the fact that the logging element has an ID
>> attribute.
>> How does the schema at http://cxf.apache.org/schemas/ get updated?
>> Apparently its not linked to SVN...
>>
>> Thanks,
>>
>> David
>>
>

RE: JMS clientReceiveTimeout default value

2008-12-12 Thread Eoghan Glynn


Yeah 60s seems a lot more reasonable for a default.

Cheers,
Eoghan

-Original Message-
From: Willem Jiang [mailto:willem.ji...@gmail.com]
Sent: Fri 12/12/2008 14:05
To: dev@cxf.apache.org
Subject: Re: JMS clientReceiveTimeout default value
 
Hi Eoghan,

How about set it to be 60s?
I think we take the http client timeout(60s) as an example.

Cheers,

Willem

Eoghan Glynn wrote:
> 
> Folks,
> 
> Is a default value of 2000ms reasonable for the JMS clientReceiveTimeout?
> 
> For even moderately long-lived requests, this seems *way* too tight to me.
> 
> A timeout in the ballpark of 2s seems more appropriate for localhost 
> demo-type situation where you want the user to get rapid feedback if they've 
> set things up wrong, or for tests where again you want things to fail fast. 
> But if that's the motivation, couldn't the demos/tests just configure an 
> appropriately tight timeout, but leave much more slack in the default?
> 
> Cheers,
> Eoghan 
>

JMS clientReceiveTimeout default value

2008-12-12 Thread Eoghan Glynn



Folks,

Is a default value of 2000ms reasonable for the JMS clientReceiveTimeout?

For even moderately long-lived requests, this seems *way* too tight to me.

A timeout in the ballpark of 2s seems more appropriate for localhost demo-type 
situation where you want the user to get rapid feedback if they've set things 
up wrong, or for tests where again you want things to fail fast. But if that's 
the motivation, couldn't the demos/tests just configure an appropriately tight 
timeout, but leave much more slack in the default?

Cheers,
Eoghan

RE: Would it make sense to add a Distributed-OSGi component to CXF-Jira?

2008-12-11 Thread Eoghan Glynn



Yep agreed, makes sense to have a separate distributed OSGi category in JIRA.

Cheers,
Eoghan


-Original Message-
From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED]
Sent: Thu 11/12/2008 11:27
To: dev@cxf.apache.org
Subject: Would it make sense to add a Distributed-OSGi component to CXF-Jira?
 
Hi all,

Currently all of the bugs against the Distributed OSGi code are filed
in the 'OSGi' component in CXF. However I think this is potentially
confusing as the 'OSGi' component really hints to me that it relates
to OSGi properties of core CXF (e.g. the way OSGi metadata is added to
OSGi-bundelized CXF libraries).

Since this is quite a different area from the code that implements the
Distributed OSGi specification I was wondering would it make sense to
add a 'Distributed OSGi' component to JIRA as well for bugs relating
to that code?

Cheers,

David

RE: Would it make sense to add a Distributed-OSGi component to CXF-Jira?

2008-12-11 Thread Eoghan Glynn



Yep agreed, makes sense to have a separate distributed OSGi category in JIRA.

Cheers,
Eoghan


-Original Message-
From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED]
Sent: Thu 11/12/2008 11:27
To: dev@cxf.apache.org
Subject: Would it make sense to add a Distributed-OSGi component to CXF-Jira?
 
Hi all,

Currently all of the bugs against the Distributed OSGi code are filed
in the 'OSGi' component in CXF. However I think this is potentially
confusing as the 'OSGi' component really hints to me that it relates
to OSGi properties of core CXF (e.g. the way OSGi metadata is added to
OSGi-bundelized CXF libraries).

Since this is quite a different area from the code that implements the
Distributed OSGi specification I was wondering would it make sense to
add a 'Distributed OSGi' component to JIRA as well for bugs relating
to that code?

Cheers,

David

RE: Problem with cxf-bundle-minimal

2008-11-26 Thread Eoghan Glynn



> Is it the case for a big bundle too ?

Well the big bundle pulls in a bunch of other org.apache.cxf.tools.wsdlto* 
packages, not just org.apache.cxf.tools.wsdlto.core.

But obviously that's the right thing to do in the big bundle case, as all 
classes form the cxf-tools-wsdlto-* modules are actually included in the big 
bundle.

Whereas in the minimal bundle, *only* the org.apache.cxf.tools.wsdlto.core 
package is imported/exported. This causes a runtime failure as the package 
cannot be resolved due to the cxf-tools-wsdlto-* classes being excluded.

/Eoghan

-Original Message-
From: Sergey Beryozkin [mailto:[EMAIL PROTECTED]
Sent: Wed 11/26/2008 9:12 AM
To: dev@cxf.apache.org
Subject: Re: Problem with cxf-bundle-minimal
 
Hi Eoghan

In this case it looks like some other module recursively pulls in 
cxf-tools-wsdlto-* ...
Is it the case for a big bundle too ?

Cheers, Sergey

- Original Message - 
From: "Eoghan Glynn" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, November 26, 2008 1:58 PM
Subject: Problem with cxf-bundle-minimal



Folks,

For some reason the minimal bundle lists org.apache.cxf.tools.wsdlto.core in 
its Import- & Export-Package manifest headers, even 
though the cxf-tools-wsdlto-* modules are excluded from this bundle.

The net result is an unresolved package error when the minimal bundle is 
installed.

Anyone know why this unnecessary dependency is pulled into the bundle manifest?

Cheers,
Eoghan

Problem with cxf-bundle-minimal

2008-11-26 Thread Eoghan Glynn


Folks,

For some reason the minimal bundle lists org.apache.cxf.tools.wsdlto.core in 
its Import- & Export-Package manifest headers, even though the 
cxf-tools-wsdlto-* modules are excluded from this bundle.

The net result is an unresolved package error when the minimal bundle is 
installed.

Anyone know why this unnecessary dependency is pulled into the bundle manifest? 

Cheers,
Eoghan

[RESULT][VOTE] David Bosschaert for committer

2008-11-16 Thread Eoghan Glynn


Well I think we can safely declare a result here having received 14 
endorsements (of which 12 were binding PMC-member votes), and no dissenting 
voices.

So welcome to the team David!

There's a little bureaucracy required to get things squared away with the ASF, 
Dan should be able to guide you through this. 

For the record, +1 votes were received from:

Ajay Paibir, Benson Margulies, Christian Schneider, Dan Kulp, Eoghan Glynn, 
Freeman Fang, Glen Mazza, Guillaume Nodet, Jeff Genender, Jim Ma, Richard Hall, 
Sergey Beryozkin, Ulhas Bhole, Willem Jiang

Cheers,
Eoghan

-Original Message-
From: Eoghan Glynn [mailto:[EMAIL PROTECTED]
Sent: Tue 11/11/2008 10:57
To: dev@cxf.apache.org
Subject: [VOTE] David Bosschaert for committer
 

Folks,

I'd like to propose David Bosschaert for CXF committership, on the basis of 

- the many quality patches he's submitted for our CXF-based distributed OSGi 
reference implementation

- his community participation especially in driving the re-integration of the 
Felix fork in the CXF sandox with the main Felix codebase

- his promotion of CXF (by extension via the dOSGi RI) in the wider OSGi 
community 

Consider this proposal a +1 from me.

The vote will remain open for at least 72 hours.

Cheers,
Eoghan

RE: why does the SOAP CheckFaultInterceptor run in the POST_PROTOCOL phase?

2008-11-16 Thread Eoghan Glynn

Hi Dan,

I'm open to correction on the security stuff, but I think we might still be OK 
with the re-ordering approach even in the presence of whitespace, as the WS-Sec 
in-interceptor (at least the WSS4J version anyway) also runs in the 
PRE-PROTOCOL phase.

So as long as the CheckFaultInterceptor runs near the end of this phase (after 
the security interceptor has already validated the signature or whatever), then 
it should be OK to advance the XMLStreamReader over any whitespace preceding 
the first body element. Assuming there's a test that validates the behaviour on 
whitespace, I guess this could be easily checked.

However, there is one other case where a simple re-ordering would still seem 
problematic - if the response is not a fault to begin with, but one of the 
JAX-WS SOAPHandlers throws a ProtocolException and thus changes it to a fault. 
In that case I guess we'd need to check again for a fault after the handler 
chain has been traversed. It might be more straight-forward to just rerun the 
(very simple) CheckFaultInterceptor at at a second point in the call chain, 
instead of splitting the (relatively complex) JAX-WS interceptor into two parts.

Does that make sense to you?

Cheers,
Eoghan

-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: Fri 14/11/2008 15:26
To: dev@cxf.apache.org
Cc: Eoghan Glynn
Subject: Re: why does the SOAP CheckFaultInterceptor run in the POST_PROTOCOL 
phase?

Actually, I remember why I put it that late.

The CheckFaultOut stuff HAS to occur after anything related to SAAJ/DOM is 
done.When it gets there, the XmlStreamReader sits at the first child of 
the soap:body.   However, that might NOT be an element.   It may be 
whitespace.   However, CheckFaultOut has to advance to the first element to 
see it's a fault.  Thus, that whitespace is lost.   That then invalidates any 
signature that may be on the soap body.  You get signature validation issues.   

Since the JAXWS handler interceptor things builds an SAAJ if there isn't 
already one, the CheckFaultOut cannot run before it or the whitespace is 
lost.  

What MIGHT work would be to split the JAXWS handler thing into two parts.   
One that runs real early in the phase chain and if there are handlers, add 
the SAAJInInerceptor and it's second part that does the real work.   That 
second part could then safely assume the SAAJ model is there.   

Dan

On Friday 14 November 2008 11:39:00 am Eoghan Glynn wrote:
> Thanks for the quick response Dan, some comments inline ...
>
> > > Is there any reason why the SOAP CheckFaultInterceptor runs in the
> > > POST_PROTOCOL phase, as opposed to PRE_PROTOCOL?
> >
> > Well, the basic reason is that to check for a fault, it needs to look at
> > the first element in the body.  The headers and envelop and such are
> > handled in the PROTOCOL phase, thus, it needs to be checked afterword.
>
> Sure, but it could do that equally well near the end of PRE_PROTOCOL phase,
> say if its configured to run after the MustUnderstandInterceptor.
>
> Come to think of it though, the ReadHeadersInterceptor runs in the READ
> phase, so we're gauranteed the headers are out of the way by the time
> PRE_PROTOCOL kicks in.
>
> Also, at least in the 2.0.6.x version I'm looking at, once the
> ReadHeaderInterceptors is done, the  element has already
> been stripped off the XMLStreamReader. So the CheckFaultInterceptor is
> nicely tee'd up to read off the  element, whether it runs in
> PRE_PROTOCOL or POST_PROTOCOL.
>
> Of course, another option would be to move the JAX-WS handler interceptors
> to the POST_PROTOCOL phase.
>
> > > The net result is handleFault() is never called for a client-side
> > > JAX-WS SOAPHandler, as the CheckFaultInterceptor (which is responbile
> > > for determining if a fault is present in the incoming message) is
> > > assigned to a phase that runs *after* the PRE_PROTOCOL phase in which
> > > the JAX-WS handler chain is traversed. So Handler.handleFault() can
> > > never be called, as it isn't yet known that the message actually
> > > contains a fault.
> >
> > Which MAY be correct.   I'd need to double check the spec and TCK and
> > such. (before committing any change in this area, let me know and I'll
> > run the tck on it).   The handleFault may be for handling faults that are
> > generated as part of processing the normal message. I'd need to
> > double check on that.
>
> The JAX-WS 2.0/1 specs seems to say little more than:
>
> "9.3.2.2 handleFault
> Called for fault message processing ..."
>
> which seems to imply that handleFault should should be called for a fault
> message on both the client- & server-sides.
>
> Curren

RE: why does the SOAP CheckFaultInterceptor run in the POST_PROTOCOL phase?

2008-11-14 Thread Eoghan Glynn


Thanks for the quick response Dan, some comments inline ...


> > Is there any reason why the SOAP CheckFaultInterceptor runs in the
> > POST_PROTOCOL phase, as opposed to PRE_PROTOCOL?
> 
> Well, the basic reason is that to check for a fault, it needs to look at the 
> first element in the body.  The headers and envelop and such are handled in 
> the PROTOCOL phase, thus, it needs to be checked afterword.


Sure, but it could do that equally well near the end of PRE_PROTOCOL phase, say 
if its configured to run after the MustUnderstandInterceptor.

Come to think of it though, the ReadHeadersInterceptor runs in the READ phase, 
so we're gauranteed the headers are out of the way by the time PRE_PROTOCOL 
kicks in.

Also, at least in the 2.0.6.x version I'm looking at, once the 
ReadHeaderInterceptors is done, the  element has already been 
stripped off the XMLStreamReader. So the CheckFaultInterceptor is nicely tee'd 
up to read off the  element, whether it runs in PRE_PROTOCOL or 
POST_PROTOCOL.

Of course, another option would be to move the JAX-WS handler interceptors to 
the POST_PROTOCOL phase.

 
> > The net result is handleFault() is never called for a client-side JAX-WS
> > SOAPHandler, as the CheckFaultInterceptor (which is responbile for
> > determining if a fault is present in the incoming message) is assigned to a
> > phase that runs *after* the PRE_PROTOCOL phase in which the JAX-WS handler
> > chain is traversed. So Handler.handleFault() can never be called, as it
> > isn't yet known that the message actually contains a fault.
> 
> Which MAY be correct.   I'd need to double check the spec and TCK and such.  
> (before committing any change in this area, let me know and I'll run the tck 
> on it).   The handleFault may be for handling faults that are generated as 
> part of processing the normal message. I'd need to double check on that.


The JAX-WS 2.0/1 specs seems to say little more than:

"9.3.2.2 handleFault
Called for fault message processing ..."

which seems to imply that handleFault should should be called for a fault 
message on both the client- & server-sides. 

Currently in CXF, handleFault is called on a server-side handler for an 
outgoing fault, but handleMessage is called on a client-side handler for that 
same message when inbound. Seems unlikely that this sort of inconsistency would 
actually be intended by the spec. Though stranger things have happened, and 
obviously you were on the spec EG so you'd have deeper knowledge of the spec 
meant to say ... :)

 
> > So before I go fixing this I wanted to check if this apparent mis-ordering
> > was just an oversight, or whether there's method to the madness :)
> 
> That all said, I've THOUGHT about adding a HttpErrorCodeInterceptor or 
> something that goes very early in the chain to flip it over to the 
> faultInChain if the response code is 500.  That could be done LONG before any 
> processing of anything else is done.   Obviously only useful for HTTP 
> transport though. The current implementation means that any stream 
> related things only on the faultInChain wouldn't ever get called.   Flipping 
> over based on response code would fix that.


Yeah, that would work ... but as you point out, the restriction HTTP sortta 
makes it a non-runner in the general case.

Cheers,
Eoghan

why does the SOAP CheckFaultInterceptor run in the POST_PROTOCOL phase?

2008-11-14 Thread Eoghan Glynn


Folks,

Is there any reason why the SOAP CheckFaultInterceptor runs in the 
POST_PROTOCOL phase, as opposed to PRE_PROTOCOL?

The net result is handleFault() is never called for a client-side JAX-WS 
SOAPHandler, as the CheckFaultInterceptor (which is responbile for determining 
if a fault is present in the incoming message) is assigned to a phase that runs 
*after* the PRE_PROTOCOL phase in which the JAX-WS handler chain is traversed. 
So Handler.handleFault() can never be called, as it isn't yet known that the 
message actually contains a fault.

So before I go fixing this I wanted to check if this apparent mis-ordering was 
just an oversight, or whether there's method to the madness :)

Cheers,
Eoghan

[VOTE] David Bosschaert for committer

2008-11-11 Thread Eoghan Glynn


Folks,

I'd like to propose David Bosschaert for CXF committership, on the basis of 

- the many quality patches he's submitted for our CXF-based distributed OSGi 
reference implementation

- his community participation especially in driving the re-integration of the 
Felix fork in the CXF sandox with the main Felix codebase

- his promotion of CXF (by extension via the dOSGi RI) in the wider OSGi 
community 

Consider this proposal a +1 from me.

The vote will remain open for at least 72 hours.

Cheers,
Eoghan

RE: [DOSGi] Spring-DM based demo added to CXF-1879

2008-11-03 Thread Eoghan Glynn

Thanks for these David, I'll do the needful ...

/Eoghan

-Original Message-
From: David Bosschaert [mailto:[EMAIL PROTECTED]
Sent: Mon 03/11/2008 04:44
To: dev@cxf.apache.org
Subject: Re: [DOSGi] Spring-DM based demo added to CXF-1879

Hi all,

I've also attached some small improvements to the greeter demo in a
patch to this bug. It would be great if someone could apply these two
patches.

Many thanks,

David

2008/10/21 David Bosschaert <[EMAIL PROTECTED]>:
> Hi all,
>
> I've added a new Spring-DM based demo for the Distributed OSGi stuff
> to https://issues.apache.org/jira/browse/CXF-1879
>
> Cheers,
>
> David
>

RE: Getting the Distributed OSGi component out of the CXF sandbox

2008-11-03 Thread Eoghan Glynn



Hi David,

It would be great to have RFC 126 support in Felix as well as Equinox, as 
obviously this would remove a barrier to wide adoption of dOSGi.

So I agree, it would be a good move to contribute back the ListenerHook support 
from the forked version of Felix that we've put in the CXF sandox. In practical 
terms, it would be more straight-forward for us to take a dependency on another 
maven-friendly Apache project. However, there are a few bits of work required 
before the Felix-based ListenerHook support could be submitted to Felix:

- align the ListenerHook interface with the final version used in Equinox

- find some alternative mechanism for transparent registration of remote 
services looked up directly (i.e. via BundleContext.getServiceReferences() as 
opposed to a ServiceTracker/Listener)

- probably a bit more test coverage

We'd then be relying on the Felix community to flesh out the initial 
contribution, so as to form a fully-fledged RFC 126 implementation (e.g. add 
support for the FindHook, which we don't use directly in distributed OSGi, but 
would be useful in other contexts). 

But I also think we really should be leveraging the existing Equinox 126 
implementation in the near-term, for example to validate the initial re-basing 
of dOSGi on the new version of the ListenerHook. Also, the earlier we smoke out 
any issues in the Equinox service hooks (e.g. in advance of the OSGi EEG f2f 
meeting next week), the better chance we have of getting a rapid fix.

Cheers,
Eoghan

-Original Message-
From: David Bosschaert [mailto:[EMAIL PROTECTED]
Sent: Mon 03/11/2008 04:28
To: dev@cxf.apache.org
Subject: Getting the Distributed OSGi component out of the CXF sandbox
 
Hi all,

The DOSGi sanbox project is getting closer to being a fully functional
Reference Implementation of the Distribution Software (DSW) component
of Distributed OSGi (RFC 119).
The main thing that prevents it from moving out of the sandbox is the
fact that it currently uses a modified version of Felix. Distributed
OSGi depends on a new addition to the OSGi Core Spec: the Service
Registry hooks (RFC 126). It uses this to transparently notify any
registered Discovery systems of the OSGi services that consumers are
interested in so that these Discovery systems can register just those
remote services that make sense to the current application.
For this purpose, the modified Felix code in the CXF DOSGi sanbox
codebase contains the bits of RFC 126 that it needs to function. It's
not a full RFC 126 implementation though.

Felix itself doesn't yet contain an implementation of RFC 126 and my
understanding is that the project would potentially be interested in
our work regarding Service Registry hooks. Therefore one idea would be
to take our RFC 126 bits and submit them to the Felix project. We
should then ultimately be able to simply depend on Felix and all of
the DOSGi code will then be ready to move out of the sandbox.

BTW the latest builds of Equinox do actually contain an implementation
of the full RFC 126 specification, so the DOSGi code should already
work with Equinox.

Thoughts anyone?

David

RE: [VOTE] Release Apache CXF 2.1.3 (2nd try)

2008-10-20 Thread Eoghan Glynn

+1

/Eoghan

-Original Message-
From: Willem Jiang [mailto:[EMAIL PROTECTED]
Sent: Sat 18/10/2008 11:19
To: dev@cxf.apache.org
Subject: [VOTE] Release Apache CXF 2.1.3 (2nd try)

Once again, there have been a bunch of bug fixes and enhancements that
have been done compared to the 2.1.2 release.   Over 52 JIRA issues
are resolved for 2.1.3.

List of issues:
https://issues.apache.org/jira/browse/CXF/fixforversion/12313354

The staging area is at:
http://people.apache.org/~ningjiang/stage_cxf/2.1.3

The distributions are in the "dist" directory. The "maven" directory
contains the stuff that will by pushed to the central repository.

This release is tagged at:
http://svn.apache.org/repos/asf/cxf/tags/cxf-2.1.3

Here is my +1.   The vote will be open here for at least 72 hours.

Willem

RE: Distributed OSGi update

2008-10-20 Thread Eoghan Glynn



Thanks David for this summary!

> There is a lot of work that still needs to be done:
> ...
> - We need better documentation.

On the subject of docco for dOSGi, I wrote up a quick "getting started" guide a 
while back. It would need a bit of updating as it dates from before the 
donation of the dOSGi code to CXF (so it refers to our internal SVN repos as 
opposed to the Apache one). Also its in OpenDocument & PDF formats, so it'll 
need to be wiki-ified to fit in the CXF docco convention. But it could be a 
useful starting point.

Cheers,
Eoghan 


-Original Message-
From: David Bosschaert [mailto:[EMAIL PROTECTED]
Sent: Mon 20/10/2008 04:38
To: dev@cxf.apache.org
Subject: Distributed OSGi update
 
Hi all,

Just a little update on how things are going wrt to the Distributed
OSGi implementation that is currently in the CXF sandbox.

Last week Eoghan, Sergey and myself were participating in the OSGi
BundleFest in Montpellier (France) where we worked hard on integrating
the various parts of Distributed OSGi (also known as OSGi RFC 119
[1]). These parts are:
* The Distribution Software (DSW) Reference Implementation, this is
what is based on CXF and what currently lives in the CXF sandbox.
* The Discovery Service Refence Implementation.
* The OSGi TCK test suite.
We can't say that everything fully worked yet, because we found bugs
in the various parts, but we did achieve the integration. This means
that we did manage to get the DSW/Discovery integration working up to
a certain level. We also got the RI parts working in the OSGi TCK
framework.

There is a lot of work that still needs to be done:
- We need better test coverage for the DOSGi RI, esp around system tests.
- We need better documentation. Obviously RFC 119 contains a lot of
information about how to use Distributed OSGi, and the upcoming OSGi
Spec (version 4.2) will also contain a lot of info, we need better
documentation on how to build, use and configure CXF-specific pieces
(such as CXF-specific intents).
- There are still a number of open bugs on the DOSGi implementation.
Obviously any help on these things will be great!

Looking a little more long-term. We are aiming at having the RFC 119
implementations in good shape well in time for OSGiCon/EclipseCon
2009. The next release of the OSGi Specification is also expected to
be available some time in 2009.

Best regards,

David

[1] http://www.osgi.org/download/osgi-4.2-early-draft.pdf

RE: [DOSGi] Patch for CXF-1876

2008-10-20 Thread Eoghan Glynn


No worries, will do ...

/Eoghan

-Original Message-
From: David Bosschaert [mailto:[EMAIL PROTECTED]
Sent: Mon 20/10/2008 06:08
To: dev@cxf.apache.org
Subject: Re: [DOSGi] Patch for CXF-1876
 
Thanks Eoghan!
I've submitted a subsequent patch to this bug which contains extra
unit tests. Would appreciate if they could be applied too.

Cheers,

David

2008/10/16 Eoghan Glynn <[EMAIL PROTECTED]>:
>
> Thanks David, applied.
> Cheers,
> Eoghan
>
> -Original Message-
> From: David Bosschaert [mailto:[EMAIL PROTECTED]
> Sent: Thu 16/10/2008 12:03
> To: dev@cxf.apache.org
> Subject: [DOSGi] Patch for CXF-1876
>
> Hi all,
>
> I've attached a patch to https://issues.apache.org/jira/browse/CXF-1876
> Would greatly appreciate if someone could apply the patch.
>
> Cheers,
>
> David
>
>

RE: [DOSGi] Patch for CXF-1876

2008-10-16 Thread Eoghan Glynn

Thanks David, applied.
Cheers,
Eoghan

-Original Message-
From: David Bosschaert [mailto:[EMAIL PROTECTED]
Sent: Thu 16/10/2008 12:03
To: dev@cxf.apache.org
Subject: [DOSGi] Patch for CXF-1876

Hi all,

I've attached a patch to https://issues.apache.org/jira/browse/CXF-1876
Would greatly appreciate if someone could apply the patch.

Cheers,

David

Re: [VOTE] Release CXF 2.0.9

2008-10-10 Thread Eoghan Glynn



+1

Willem Jiang wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
This is a vote to release CXF 2.0.9


Once again, there have been a bunch of bug fixes and enhancements that
have been done compared to the 2.0.9 release.   Over 37 JIRA issues
are resolved for 2.0.9 which is a large number of fixes for the 2.0.x
branch.

List of issues:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&pid=12310511&fixfor=12313314

The staging area is at:
http://people.apache.org/~ningjiang/stage_cxf/2.0.9

The distributions are in the "dist" directory. The "maven" directory
contains the stuff that will by pushed to the central repository.

This release is tagged at:
http://svn.apache.org/repos/asf/cxf/tags/cxf-2.0.9


Here is my +1.   The vote will be open here for at least 72 hours.

Willem
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
iEYEARECAAYFAkjvTt8ACgkQI1CSmK6N6eTuWACdFBA+C8R3DzKTWCIinln0sCaC

zWAAn04fkhek/PMlgRHwCeevV45CTwN6
=4dc9
-END PGP SIGNATURE-



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: Initial bits for a DOSGi distribution (CXF-1854)

2008-10-09 Thread Eoghan Glynn



Thanks David, patch applied.

David Bosschaert wrote:

Hi all,

I've attached a patch to https://issues.apache.org/jira/browse/CXF-1854 
which contains the beginning of a distribution of the DOSGi stuff. The 
distribution contains all the required dependencies (OSGi bundles) is 
built as part of the maven build in distribution/multi-bundle/target


Would appreciate if someone could apply.

Thanks!

David


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: [DOSGi] patch for CXF-1851

2008-10-09 Thread Eoghan Glynn



Thanks David, patch is applied.

/Eoghan

David Bosschaert wrote:

Hi Eoghan,

Yes, the patch contained fairly complex moves of a number of XML files, 
which involved moving them to new directories etc.


To get around the problem, I have created a new patch that was created 
without using moves (I simply copied the file and deleted the original). 
This causes some history to be lost, but this only concerns some XML 
metadata files. I hope this is acceptable.


The patch to https://issues.apache.org/jira/browse/CXF-1851 is called 
'remote_services_location_nomoves.patch'.


Hope this works.

Cheers,

David

Eoghan Glynn wrote:


Did you do the moves as a single step, or more like moving a to c via:

mv a b
mv b c


David Bosschaert wrote:
Yeah, I moved intent-map.xml from META-INF/osgi into a new directory 
called OSGI-INF/cxf/intents in a few places. I also moved 
remote-services.xml from META-INF/osgi to OSGI-INF/remote-services in 
a few places...


FYI I created the patch using Tortoise 1.5.0 on Windows...

Cheers,

David

Eoghan Glynn wrote:


Thanks David,

However svn-apply got a bit confused when I tried to apply the patch.

Did you create some new elements in your working copy and then move 
them a different directory?


For example, svn-apply complains that the patch attempts to delete 
the non-existent:


dsw/cxf-dsw/src/main/resources/OSGI-INF/cxf/intent-map.xml

i.e. this file is non-existent in the master repo, but presumably 
existed as a new element in your working copy before being moved 
(which in SVN terms maps onto an add and delete).


I'm not sure how to proceed with this one. Can any of the SVN gurus 
in the community comment?


Cheers,
Eoghan


David Bosschaert wrote:

Hi all,

I attached a patch to https://issues.apache.org/jira/browse/CXF-1851

Would greatly appreciate if someone could apply it.
Thanks!

David



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: [DOSGi] patch for CXF-1851

2008-10-08 Thread Eoghan Glynn



Did you do the moves as a single step, or more like moving a to c via:

mv a b
mv b c


David Bosschaert wrote:
Yeah, I moved intent-map.xml from META-INF/osgi into a new directory 
called OSGI-INF/cxf/intents in a few places. I also moved 
remote-services.xml from META-INF/osgi to OSGI-INF/remote-services in a 
few places...


FYI I created the patch using Tortoise 1.5.0 on Windows...

Cheers,

David

Eoghan Glynn wrote:


Thanks David,

However svn-apply got a bit confused when I tried to apply the patch.

Did you create some new elements in your working copy and then move 
them a different directory?


For example, svn-apply complains that the patch attempts to delete the 
non-existent:


dsw/cxf-dsw/src/main/resources/OSGI-INF/cxf/intent-map.xml

i.e. this file is non-existent in the master repo, but presumably 
existed as a new element in your working copy before being moved 
(which in SVN terms maps onto an add and delete).


I'm not sure how to proceed with this one. Can any of the SVN gurus in 
the community comment?


Cheers,
Eoghan


David Bosschaert wrote:

Hi all,

I attached a patch to https://issues.apache.org/jira/browse/CXF-1851

Would greatly appreciate if someone could apply it.
Thanks!

David


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, 
Ireland



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland




IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: [DOSGi] patch for CXF-1851

2008-10-08 Thread Eoghan Glynn



Thanks David,

However svn-apply got a bit confused when I tried to apply the patch.

Did you create some new elements in your working copy and then move them 
a different directory?


For example, svn-apply complains that the patch attempts to delete the 
non-existent:


dsw/cxf-dsw/src/main/resources/OSGI-INF/cxf/intent-map.xml

i.e. this file is non-existent in the master repo, but presumably 
existed as a new element in your working copy before being moved (which 
in SVN terms maps onto an add and delete).


I'm not sure how to proceed with this one. Can any of the SVN gurus in 
the community comment?


Cheers,
Eoghan


David Bosschaert wrote:

Hi all,

I attached a patch to https://issues.apache.org/jira/browse/CXF-1851

Would greatly appreciate if someone could apply it.
Thanks!

David


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: [DOSGi] patch with further pieces for CXD-1836

2008-10-07 Thread Eoghan Glynn



Thanks David, patch applied.

/Eoghan

David Bosschaert wrote:

Hi all,

I've attached another patch to 
https://issues.apache.org/jira/browse/CXF-1836 that implements the 
required Service Properties on the DistributionProvider service. The 
patch is called DistributionProvider-properties.patch and a direct link 
to it can be found here: 
https://issues.apache.org/jira/secure/attachment/12391635/DistributionProvider-properties.patch 



It would be great if someone could apply the patch.

Thanks!

David


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: Proposal for a new JMS configuration for CXF

2008-10-07 Thread Eoghan Glynn


Daniel Kulp wrote:


- ensuring the multiplicity of conduit beans configured alongside a
failover selector is consistent with the set of ports defined in the
WSDL, as the CXF static failover strategy is based on burning the
alternate ports into a multi-port service definition in the WSDL.


Well, this COULD actually remove that limitation.  A FailoverSelector 
could have a bunch of conduits configured via configuration (like 
roundrobin) and failover from one to the other.  Thus, the failover 
stuff would work for code first cases much better.   If the 
FailoverSelector doesn't have any conduits coming in from spring, it 
could use the multi-port strategy it currently uses.


Yeah, that makes sense all right in the particular case of the alternate 
addresses being taken from the WSDL. Encoding the alternate addresses in 
s versus configuring the same info in the  
would be similar strategies in the sense that in both cases the cluster 
is statically defined (i.e. of fixed size and membership, modulo changes 
to WSDL or config, which would generally require a restart/refresh in 
the client).


But I also had in mind the case where the addresses are retrieved 
dynamically from some external agency, such as a registry service. I've 
built an example of this approach in another project which is layered 
over CXF. In this case the cluster is dynamically assembled, and no 
specific addressing info is statically burned into the client's WSDL (or 
config).


Now in this latter case, there's a slightly different possible use-case 
for the  wiring. Instead of using this mechanism to 
inject the target addresses (and other config) for individual conduits, 
we could instead have a place-holder "abstract" conduit bean containing 
only non-address config to be used for any concrete conduit instance (of 
a particular type) created for this proxy over its lifetime, including 
any failover events.


So for example, suppose I wanted to ensure that AllowChunking was always 
set to false for a particular proxy because I suspect there's a bug in 
the server-side stack's support for HTTP chunking (real-life example 
from our own in-house interop testing). And say I'm using my 
registry-mediated faliover strategy. In this case it would be neat to 
just do something like:


  http://apache.org/hw}MyPort";>

  

  


   http://apache.org/hw}MyPort.http-conduit";
 abstract="true">
   
   

...
  

and have the AllowChunking="false" applied to *any* HTTP conduit created 
for this proxy over its lifetime.


Cheers,
Eoghan



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: Proposal for a new JMS configuration for CXF

2008-10-06 Thread Eoghan Glynn




Hi Dan,

Dan Diephouse made a similar proposal about 18 months ago, and I was 
opposed at the time as it didn't accomodate what was trying to acheive 
with ConduitSelectors.


That discussion was also conflated with a bunch of other proposed 
changes, but in retrospect I think the  bean had the 
essence of a really good idea.


So as long as support for the flexible conduit selection is maintained, 
I think this proposal would have potential.


Possible wrinkles would include things like:

- ensuring that the choice of conduit selector is validated against the 
presence or absence of fine-grained conduit beans, e.g. it wouldn't make 
sense to wire in any conduit beans at all when the deferred conduit 
selector is in use, as the whole idea here is to ensure that a conduit 
isn't created until we're sure we really need it (as we would never do 
so in the coloc case)


- ensuring the multiplicity of conduit beans configured alongside a 
failover selector is consistent with the set of ports defined in the 
WSDL, as the CXF static failover strategy is based on burning the 
alternate ports into a multi-port service definition in the WSDL.


Cheers,
Eoghan


Daniel Kulp wrote:
I completely agree with MUCH of this.   I'd love it if the jaxws:client 
and jaxws:endpoint/server things had a:






type thing that would configure that.   It's SLIGHTLY more complicated by 
the presence of the conduit selector things in the client which allows 
load balancing and such.   However, that could be made even more 
configurable with something like:









(default would be the current "Upfront" selector.)



Dan



On Sunday 05 October 2008, Christian Schneider wrote:

Hi Willem,

if I understand it right there is always one conduit for each client
or endpoint. So I would not try to reference a conduit config via the
endpoint name like it is done now. The conduit can as well be
described as a parameter of client or endpoint. I really do not like
the way the old JMSConduit configured itself. Extracting the
configuration should be outside of the object to be configured.

The way camel does this is ok. But instead of referencing a jms
configuration in the address line I would simply set it as a parameter
in client or endpoint. If you want to centralize certain parts of the
config spring still has the ref="" to reference a central config bean.
Additionally we can use abstract config beans so several jms
configurations can share some common parts.

By simply being a property of the client or endpoint they can simply
add it to the endpointInfo. So the TransportFactory can extract it and
set the Conduit or Destination with it.

Greetings

Christian

Willem Jiang schrieb:

You could take a look at the configuration of camel transport for
CXF. we inject the camel context (which could be an extension of
TransportConfig) into the CamelTransportFactory or the
{CamelConduit|CamelDestion}.

Endpoint can find the CamelTransportFactory by using the transport
id or transport perfix like 'camel:'.  Each Conduit or Destination
configuration has its own id, when the endpoint find the transport
factory and create the conduit or destination, current CXF
configuration will call the 'configure' method which will seach the
spring context and configure the conduit or destination according
the bean id.

If you want to add the TransportConfig into the endpoint , we need
to hack the code of endpoint looking up the transport factory, and
set the TransportConfig into the transport factory or the
{conduit|destination}.

Any thoughts?







IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: [DOSGi] Patch attached to JIRA CXF-1811

2008-10-06 Thread Eoghan Glynn



Thanks for the patch David, now applied.

/Eoghan


David Bosschaert wrote:

Hi all,

I attached a further patch for CXF-1811 to this bug: 
https://issues.apache.org/jira/secure/attachment/12391563/property_rename2.patch 

The patch is called 'property_rename2.patch'. A direct link to the 
patch: 
https://issues.apache.org/jira/secure/attachment/12391563/property_rename2.patch 



In addition to fixing the service property names, the patch includes:
* When an intent is on the osgi.remote.requires.intents list and cannot 
be satisfied, the service is not exposed remotely.

* All satisfied intents are added to an osgi.intents publication property.
* New unit tests added for the above.
* Also, added extra unit tests for intent map overriding and merging.

Would greatly appreciate if someone could apply the patch.

Best regards,

David


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

1 2 >

1 - 100 of 128 matches

Mail list logo