Re: 10 years of CXF - Happy Birthday!

[David Bosschaert]

Congratulations! Happy birthday CXF!

David

On 17 April 2018 at 08:54, Francois Papon 
wrote:

> Happy Birthday to all the CXF guys !
>
> Thanks for your great job :)
>
> François
>
>
> Le 16/04/2018 à 22:15, Dennis Kieselhorst a écrit :
> > Hi,
> >
> > it's time to celebrate: 10 years ago, on April 16th in the year 2008,
> > CXF graduated from the Apache incubator as a merge of the Objectweb
> > Celtix project and the Codehaus XFire project (see
> > http://incubator.apache.org/projects/cxf.html for more details).
> >
> > Today we have lots of more features, support for additional
> > specifications and a large user base.
> >
> > Thanks to anyone who made this possible and looking forward to another
> > 10 years :-)
> >
> > Cheers
> > Dennis
>
>

Re: [VOTE] - Release Apache CXF DOSGi 2.0.0

[David Bosschaert]

+1

Cheers,

David

On 14 September 2016 at 15:16, Christian Schneider 
wrote:

> This is a vote to release Apache CXF DOSGi 2.0.0.
>
> The main change in this version is to split the SOAP support from the REST
> support. So it is now possible to only install SOAP support or only REST
> support. The multi bundle distro still contains both variants but the karaf
> features are now separate.
>
> As a new distro style we now offer a repository pom with the bundle
> dependencies which is suitable to create a bndtools index from it. So it is
> very easy to use CXF-DOSGi in bndtools. There is also such a repository pom
> for the samples that contains everything needed to run the samples from
> bndtools. The first example that uses this is the soap example. It contains
> a soap.bndrun file that can be directly started and debugged from eclipse.
> This pom based repo might be a replacement for the current multi bundle
> distro as it is much smaller and more flexible.
>
> The bndtools based assembly uses the resolver to create a minimal set of
> bundles for the sample. For SOAP and REST together I was able to make this
> as small as 9 MB. For pure SOAP it is just 7.7 MB.
>
> Another big change is that the examples are now based on a slightly
> changed TaskList service which is easier to understand that the previous
> Greeter example. The examples now have karaf features to make it easy to
> test them in karaf.
>
> Apart from these major changes I looked through the open issues and marked
> a lot of them as fixed as they should be solved in the new code. Please
> give feedback if anything is not yet solved.
>
> I have not yet changed the wiki documentation to reflect the new code. As
> it would be difficult to have the old and new documentation side by side in
> the wiki I did most of the documentation in the code using github markdown
> syntax. This allows to have the documentation closer to the code and also
> will allow to look into the documentation of previous releases.
> I plan to point to the gihub docs from the wiki and keep the old wiki
> contents as documentation of the 1.x releases.
>
> You can find the new documentation here:
>
> https://github.com/apache/cxf-dosgi
>
> If you want to try the new code I recommend to follow the installation
> instructions of the examples:
>
> https://github.com/apache/cxf-dosgi/tree/master/samples
>
> Btw. as usual .. until the release is pushed to maven central you will
> have to add the maven repo listed below to your karaf instance.
>
> Release Notes - CXF Distributed OSGi - Version 2.0.0
>
>
> ** Bug
> * [DOSGI-19] - Discovery Software doesn't notice changed Service
> Properties.
> * [DOSGI-22] - It would benefit the RFC 119 TCK if multiple instances
> of DOSGi could be run in a single OSGi container.
> * [DOSGI-52] - -Dorg.apache.cxf.spring.validation.mode=VALIDATION_NONE
> doesn't have an effect
> * [DOSGI-73] - OSGi Declarative Service-based consumer does not
> register proxy service on demand
> * [DOSGI-108] - service.exported.interfaces doesn't support
> comma-seperated String value
> * [DOSGI-124] - ReceiveTimeout not configurable while using cxf-rest
> service in OSGI
> * [DOSGI-159] - Endpoint description contains wrong
> org.apache.cxf.ws.address when using HTTPService style
> * [DOSGI-171] - service objects are never released (using ungetService)
> * [DOSGI-185] - Restarting of Jetty/PaxWeb makes exported services
> unavailable
> * [DOSGI-186] - documentation incorrect
> * [DOSGI-187] - service configuration for service-namespace,
> service-name and service-port only take affect if wsdl-location is also
> configured
> * [DOSGI-196] - Greeter demo does not work in standalone Felix
> * [DOSGI-199] - NoSuchMethodError in tests (Jetty version mismatch)
> * [DOSGI-209] - when bundles registers two WS with different
> SoapBinding Style Document/RPC then one of the STYLE is not as expected
> * [DOSGI-213] - ASM library not in Multibundle 1.6.0, so no naming of
> webservice parameters possible
> * [DOSGI-219] - DOSGi Fails to Publish Service Under Apache Karaf 3.0.3
> * [DOSGI-225] - Service publication with 
> org.apache.cxf.ws.httpservice.context
> property does not work
> * [DOSGI-226] - Cannot configure org.apache.cxf.dosgi.dsw.Activator
> via Felix fileinstall
> * [DOSGI-227] - Build fails with JDK 8
> * [DOSGI-236] - IllegalArgumentException: No SchemaFactory exception
> during build
> * [DOSGI-240] - Fix checkstyle in eclipse
> * [DOSGI-242] - Refactor provider to prepare for split
>
> ** Improvement
> * [DOSGI-101] - Update the guide on using DOSGI RI withing Eclipse
> * [DOSGI-144] - can not deploy CXF 1.3.1 on Virgo Tomcat 3.5.RELEASE
> * [DOSGI-152] - Update systests2 to use pax-exam 2.5
> * [DOSGI-237] - Upgrade Distributed OSGI to OSGI 5.0
> * [DOSGI-239] - Extract decorator xml support into separate bundle
> * [DOSGI-241] - Simplify examples
>

Re: [VOTE] - Release Apache CXF DOSGi 1.8.0

[David Bosschaert]

+1

David

On 31 March 2016 at 14:45, Christian Schneider 
wrote:

> This is a vote to release Apache CXF DOSGi 1.8.0.
>
> The main change in this release to move out the core of Remote Service
> Admin and the discovery support to the Apache Aries Remote Service Admin
> project.
> http://aries.apache.org/modules/rsa.html
>
> So the functionality that remains in CXF DOSGi is to implement a provider
> for Aries RSA and the multibundle distribtuion and karaf features.
>
> Release Notes - CXF Distributed OSGi - Version 1.8.0
>
> https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%201.8.0%20AND%20project%20%3D%20DOSGI
>
> ** Bug
> * [DOSGI-221] - HttpServiceManager.getHttpService sometimes return null
>
> ** Improvement
> * [DOSGI-235] - Switch to Aries RSA release 1.8.0
> * [DOSGI-228] - Upgrade to CXF 3.1.5
> * [DOSGI-229] - Refactor to make Remote Service Admin core independent
> of CXF
> * [DOSGI-232] - Remove code that moved to aries-rsa
>
> ** New Feature
> * [DOSGI-230] - Create TCP provider
> * [DOSGI-231] - Create ExportPolicy SPI
>
> Tag:
>
>
> https://git-wip-us.apache.org/repos/asf?p=cxf-dosgi.git;a=tag;h=42f3fa3aa36552a511ca7db7c52f5925e8c92fdd
>
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecxf-1070
>
> +1 from me.
>
> Christian
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>

Re: Hibernate and OSGi

[David Bosschaert]

Hi Benson,

Maybe my misunderstanding, but I thought this email was a general
call-out for help on Hibernate and OSGi. osgi-...@mail.osgi.org is an
open email list for general help on OSGi. I did not see the CXF
connection in your email.

Cheers,

David

On 16 December 2015 at 07:18, Benson Margulies  wrote:
> David, I'm not sure of your point here. We've been discussing issues
> with the -CXF- OSGi support for bean validation in two JIRAs and a
> number of email messages. Some people suggested engaging the Hibernate
> community; I did, and sent an email with the coordinates. I don't see
> why I would poke a generic osgi mailing list that I've never
> participated in.
>
>
> On Tue, Dec 15, 2015 at 6:26 PM, David Bosschaert
>  wrote:
>> Hi Benson,
>>
>> Did you post this to the right mailing list? Forwarding to osgi-dev...
>>
>> Cheers,
>>
>> David
>>
>> On 15 December 2015 at 16:20, Benson Margulies  wrote:
>>> Could people who actually understand this stuff please chime in on
>>> https://hibernate.atlassian.net/browse/HV-1039?

Re: Hibernate and OSGi

[David Bosschaert]

Hi Benson,

Did you post this to the right mailing list? Forwarding to osgi-dev...

Cheers,

David

On 15 December 2015 at 16:20, Benson Margulies  wrote:
> Could people who actually understand this stuff please chime in on
> https://hibernate.atlassian.net/browse/HV-1039?

Re: [VOTE] Apache DOSGi 1.7.0 Release

[David Bosschaert]

+1

David

On 3 July 2015 at 15:12, Christian Schneider  wrote:
> The Apache CXF DOSGi sub project implements the OSGi Remote Services and
> Remote Services Admin Service specifications [1] which provide a distributed
> computing model based around OSGi Services.
>
> This release works on Apache Karaf 3 and 4. It will not work on Karaf 2
> anymore.
>
> Release Notes - CXF Distributed OSGi - Version 1.7.0
>
> ** Bug
> * [DOSGI-214] - Endpoint publication to discovery does not always work
> * [DOSGI-215] - ZooKeeperDiscovery restarts ZooKeeper-connection for no
> reason
> * [DOSGI-216] - ZookeeperStarter restarts ZooKeeper too easily
>
> ** Improvement
> * [DOSGI-220] - Upgrade to cxf 3.1.1
>
> Staging Area:
> https://repository.apache.org/content/repositories/orgapachecxf-1046
>
> The vote will be open for at least 72 hours.
>
> Here is my +1
>
>
> Christian
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>

Re: How to handle "applications" in OSGi that offer / consume cxf services and want to enforce application level rules

[David Bosschaert]

On 24 September 2014 15:03, Christian Schneider  wrote:
> Hi David,
>
> I also still think it might be intersting to share a cxf bus between bundles
> to make it easier to configure common things. Any ideas about this?

Yes, this should be possible. The Composite Subsystem type allows you
to define the sharing policy. It basically allows you to declare what
APIs to export (and import) and the same for the services. So you
could think of a CXF subsystem that contains all of the CXF API and
implementation, but that only exports the public API and the public
services...

Just to give you an idea, you can define the sharing policy in the
SUBSYSTEM.MF file, using Import-Package/Export-Package and
Subsystem-ImportService/Subsystem-ExportService

Cheers,

David

Re: How to handle "applications" in OSGi that offer / consume cxf services and want to enforce application level rules

[David Bosschaert]

You could take a look at OSGi subsystems, which is chapter 134 of the
OSGi Enterprise R5 specs [1]. The Application and Composite subsystems
allow for separation of subsystems (while the Feature subsystem shares
everything, just like with Karaf features).

There is an implementation of OSGi subsystems available in Apache
Aries. If you want to get that up and running quickly you could take a
look at a presentation I did recently [2].

Cheers,

David

[1] http://www.osgi.org/Download/Release5
[2] 
http://adapt.to/2014/en/schedule/using-osgi-subsystems-with-apache-felix.html

On 24 September 2014 14:42, Christian Schneider  wrote:
> I would like to deploy two (or more) CXF based applications into the same
> OSGi framework.
> How can I enforce common rules per application while keeping the
> applications separate from each other?
>
> I created a wiki page to show the scenario and describe current approaches I
> found and their limitations as well as an idea for a new approach.
> I would be happy about any feedback. Did you have a similar case? How did
> you solve it?
>
> https://cwiki.apache.org/confluence/display/CXF/Grouping+bundles+to+applications+in+OSGi
>
> Christian
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>

Re: [VOTE] CXF 2.6.15/2.7.12/3.0.1

[David Bosschaert]

+1

David

On 15 July 2014 20:57, Daniel Kulp  wrote:
>
> This is a vote to release the latest patch releases on all three branches.
>
> There are over 80 fixes for 3.0.1 with most back ported to 2.7.12 and some to 
> 2.6.15.
>
> Note: this is expected to be the last release of the 2.6.x branch.
>
> Tags:
> 2.6.15:
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=67f6d1aaba4108b4e42bb2cfee098b8e6bec8ccd
> 2.7.12:
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=18e0bb93814c9c8d244816ed9b2ea48a30a7fb38
> 3.0.1:
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=dffa15d68cbcea75faa138bfee7c2443ff930505
>
>
> Staging repos:
> 2.6.15:
> https://repository.apache.org/content/repositories/orgapachecxf-1024/
> 2.7.12
> https://repository.apache.org/content/repositories/orgapachecxf-1025/
> 3.0.1
> https://repository.apache.org/content/repositories/orgapachecxf-1026/
>
> Vote will be open for 72 hours.
>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>

Re: [VOTE] CXF 2.6.14/2.7.11 - take 2

[David Bosschaert]

+1

David

On 9 April 2014 04:44, Daniel Kulp  wrote:
>
>
> It's been 2 months since the last releases... This is a vote to release 
> 2.7.11 and 2.6.14.
>
> There are over 60 issues fixed for 2.7.11 and more than 20 ported back to 
> 2.6.14.
>
>
> This second attempt fixes the blueprint parsing issues that Aki found as well 
> as a potential NPE in the Logging interceptors.
>
>
> Staging area:
> https://repository.apache.org/content/repositories/orgapachecxf-1017/
> https://repository.apache.org/content/repositories/orgapachecxf-1018/
>
> Tag:
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=22e7ed37f8967f6fc2e0035f3b56eb5b882e0582
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=0245050c1c326a6bfa26186806615dc311686946
>
> This vote will be open for 72 hours.
>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>

Re: [VOTE] CXF 2.6.14/2.7.11

[David Bosschaert]

+1

David

On 6 April 2014 17:34, Daniel Kulp  wrote:
>
> It's been 2 months since the last releases... This is a vote to release 
> 2.7.11 and 2.6.14.
>
> There are over 60 issues fixed for 2.7.11 and more than 20 ported back to 
> 2.6.14.
>
>
> Staging area:
> https://repository.apache.org/content/repositories/orgapachecxf-1014/
> https://repository.apache.org/content/repositories/orgapachecxf-1015/
>
> Tag:
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=6c4a45138976c7c7b770fdaa979cd0eddb2449c6
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=tag;h=0d3b94e213446763d348fb07c51e71fe00fa3151
>
>
> This vote will be open for 72 hours.
>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>

Re: Discuss: Switching cxf to git

[David Bosschaert]

Yes, good idea!

David

On 22 January 2014 09:20, Christian Schneider  wrote:
> Recently many apache projects switched from svn to git (like Camel and
> Karaf).
> As git has many advantages compared to svn (especially for back ports) I
> think it makes sense to also do this switch for cxf.
>
> Any opinions?
>
> Christian
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>

Re: [VOTE] Apache DOSGi 1.6.0 Release

[David Bosschaert]

+1 from me!

David

On 16 January 2014 14:46, Christian Schneider  wrote:
> The Apache CXF DOSGi sub project is the Reference Implementation of the OSGi
> Remote Services and
> Remote Services Admin Service specifications [1] which provide a distributed
> computing model based around OSGi Services.
>
> The CXF DOSGi 1.6.0 release contains the following fixes and improvements:
>
>  * 12 issues resolved (see jira)
>
> 
>  * Multi bundle distro now created from karaf features. So less effort
>for new releases
>  * CXF updated to 2.7.8
>  * jdom dependency removed
>  * Bug fixes
>
> Migration:
> For usage with felix it is now necessary to change the system package
> exports like in karaf. The Multibundle distro contains the necessary config.
>
> Also see the release notes:
> http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.6.0/distribution/sources/src/main/release/release_notes.txt
>
> Staging area:
> https://repository.apache.org/content/repositories/orgapachecxf-1000/
>
> The vote will be open for at least 72 hours.
>
> Here's my +1.
>
> Best regards,
>
> Christian
>
> [1] Chapters 13 and 122 in the OSGi 4.2 Enterprise Specification at
> http://www.osgi.org/Download/Release4V42
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>

Re: [VOTE] Apache CXF 2.7.8/2.6.11

[David Bosschaert]

+1

David

On 20 November 2013 16:20, Daniel Kulp  wrote:
>
> We've resolved over 75 issues since 2.7.7 and almost 35 ported back to 2.6.11.
>
>
> List of issues:
> 2.6.11
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12325006
> 2.7.8
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12325005
>
> The Maven staging areas are at:
> 2.6.11
> https://repository.apache.org/content/repositories/orgapachecxf-155/
> 2.7.8
> https://repository.apache.org/content/repositories/orgapachecxf-158/
>
> The distributions are in the org/apache/cxf/apache-cxf/ directory of the 
> Maven staging areas.
>
>
> This releases are tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.11
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.8
>
> This vote will be open for at least 72 hours.
>
>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>

Re: [VOTE] Apache CXF 2.7.7/2.6.10 - take 2

[David Bosschaert]

+1

David


On 18 September 2013 18:08, Daniel Kulp  wrote:

>
>
> We've resolved over 90 issues since 2.7.6 and almost 50 ported back to
> 2.6.10.   This second attempt fixes some regressions in the JAX-WS TCK as
> well as some issues within Eclipse RCP framework.
>
>
> This also includes an update release of our build-utils to get the PMD
> stuff needed to work with the latest Eclipse.
>
>
> List of issues:
> 2.6.10
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12324771
> 2.7.7
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12324770
>
> The Maven staging areas are at:
> build-utils:
> https://repository.apache.org/content/repositories/orgapachecxf-042/
> 2.6.10
> https://repository.apache.org/content/repositories/orgapachecxf-041/
> 2.7.7
> https://repository.apache.org/content/repositories/orgapachecxf-073/
>
> The distributions are in the org/apache/cxf/apache-cxf/ directory of the
> Maven staging areas.
>
>
> This releases are tagged at:
> http://svn.apache.org/repos/asf/cxf/build-utils/tags/cxf-build-utils-2.6.0/
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.10
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.7
>
> This vote will be open for at least 72 hours.
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

Re: [VOTE] Apache CXF 2.7.7/2.6.10

[David Bosschaert]

+1

David


On 14 September 2013 13:36, Daniel Kulp  wrote:

>
>
> We've resolved over 90 issues since 2.7.6 and almost 50 ported back to
> 2.6.10.
>
> This also includes an update release of our build-utils to get the PMD
> stuff needed to work with the latest Eclipse.
>
>
> List of issues:
> 2.6.10
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12324771
> 2.7.7
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12324770
>
> The Maven staging areas are at:
> build-utils:
> https://repository.apache.org/content/repositories/orgapachecxf-042/
> 2.6.10
> https://repository.apache.org/content/repositories/orgapachecxf-041/
> 2.7.7
> https://repository.apache.org/content/repositories/orgapachecxf-043/
>
> The distributions are in the org/apache/cxf/apache-cxf/ directory of the
> Maven staging areas.
>
>
> This releases are tagged at:
> http://svn.apache.org/repos/asf/cxf/build-utils/tags/cxf-build-utils-2.6.0/
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.10
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.7
>
> This vote will be open for at least 72 hours.
>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

Re: [VOTE] Apache CXF patch releases (2.5.11/2.6.9/2.7.6 and xjc-utils 2.6.2)

[David Bosschaert]

+1

David


On 17 July 2013 17:57, Daniel Kulp  wrote:

>
>
> We've resolved over 75 issues since 2.7.5 and almost 50 ported back to
> 2.5.11 and 2.6.9.
>
> This also includes an minor 2.6.2 release of xjc-utils to get the update
> to the boolean getter plugin that was requested.
>
>
> List of issues:
> 2.5.11
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12324275
> 2.6.9
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12324384
> 2.7.6
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12324383
>
> The Maven staging areas are at:
> xjc-utils:
> https://repository.apache.org/content/repositories/orgapachecxf-153
> 2.5.11
> https://repository.apache.org/content/repositories/orgapachecxf-152
> 2.6.9
> https://repository.apache.org/content/repositories/orgapachecxf-155
> 2.7.6
> https://repository.apache.org/content/repositories/orgapachecxf-159
>
> The distributions are in the org/apache/cxf/apache-cxf/ directory of the
> Maven staging areas.
>
>
> This releases are tagged at:
> http://svn.apache.org/repos/asf/cxf/xjc-utils/tags/xjc-utils-2.6.2/
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.11
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.9
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.6
>
> This vote will be open for at least 72 hours.
>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

Re: [VOTE] Apache DOSGi 1.5.0 Release take two

[David Bosschaert]

Very cool!

+1 from me.

David


On 28 June 2013 08:37, Christian Schneider  wrote:

> The Apache CXF DOSGi sub project is the Reference Implementation of the
> OSGi Remote Services and
> Remote Services Admin Service specifications [1] which provide a
> distributed computing model based around OSGi Services.
>
> The CXF DOSGi 1.5.0 release contains the following fixes and improvements:
>
>  * 25 issues resolved (see jira)
> fixforversion/12323560#**selectedTab=com.atlassian.**
> jira.plugin.system.project%**3Aversion-issues-panel
> >
>  * Single bundle distro was removed
>  * CXF updated to 2.7.2
>  * Many bug fixes
>  * Some more refactorings
>
> Migration:
> For usage with felix it is now necessary to change the system package
> exports like in karaf. The Multibundle distro contains the necessary config.
>
> Also see the release notes:
> http://svn.apache.org/repos/**asf/cxf/dosgi/tags/cxf-dosgi-**
> ri-1.5.0/distribution/sources/**src/main/release/release_**notes.txt
>
> Staging area:
> https://repository.apache.org/**content/repositories/**orgapachecxf-085
>
> The vote will be open for at least 72 hours.
>
> Here's my +1.
>
> Best regards,
>
> Christian
>
> [1] Chapters 13 and 122 in the OSGi 4.2 Enterprise Specification at
> http://www.osgi.org/Download/**Release4V42
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>

Fwd: [ANN] OSGi CT License for ASF

[David Bosschaert]

FYI

David

-- Forwarded message --
From: Felix Meschberger 
Date: 27 May 2013 14:38
Subject: [ANN] OSGi CT License for ASF
To: jcp-o...@apache.org


Hi all

You may have heard elsewhere on this list that the ASF's license to using
the OSGi CTs expired some time ago.

We have now been able to renew the license backdated to the expiry date of
the previous license (Dec. 2, 2011). So anyone's use of the OSGi CTs under
the license (remember only ASF open source implementations can be checked
with the CTs under our license) is properly covered.

Further information on using the OSGi CTs can be found at [1].

Hope that helps.

Regards
Felix
V.P. Apache Felix

[1]
http://felix.apache.org/documentation/development/using-the-osgi-compliance-tests.html

Re: [VOTE] CXF 2.7.5/2.6.8 - take 3

[David Bosschaert]

+1

3rd time lucky ;)

David


On 12 May 2013 17:58, Sergey Beryozkin  wrote:

> +1
>
> Sergey
>
> On 11/05/13 02:22, Daniel Kulp wrote:
>
>>
>> We've resolved over 40 issues since 2.7.4.   Not a lot, but it includes
>> an OSGi fix that is blocking a Camel issues which may also be causing
>> issues with the ServiceMix release.  This also affects CXF 2.6.x which
>> affects Camel 2.10.x/ServiceMix 4.5.1 so I decided to do a 2.6.x release as
>> well.
>>
>> This third build fixes the security login issues Colm discovered along
>> with a potential class loader deadlock.
>>
>>
>> List of issues:
>> 2.6.8
>> https://issues.apache.org/**jira/secure/ReleaseNote.jspa?**
>> projectId=12310511&version=**12324276
>> 2.7.5
>> https://issues.apache.org/**jira/secure/ReleaseNote.jspa?**
>> projectId=12310511&version=**12324277
>>
>> The Maven staging areas are at:
>> 2.6.8
>> https://repository.apache.org/**content/repositories/**orgapachecxf-172/
>> 2.7.5
>> https://repository.apache.org/**content/repositories/**orgapachecxf-001/
>>
>> The distributions are in the org/apache/cxf/apache-cxf/ directory of the
>> Maven staging areas.
>>
>> This releases are tagged at:
>> http://svn.apache.org/repos/**asf/cxf/tags/cxf-2.6.8
>> http://svn.apache.org/repos/**asf/cxf/tags/cxf-2.7.5
>>
>> This vote will be open for at least 72 hours.
>>
>>
>>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com
>

Re: [VOTE] CXF 2.7.5/2.6.8

[David Bosschaert]

+1

David


On 6 May 2013 15:39, Alessio Soldano  wrote:

> +1
>
> On 05/04/2013 02:14 PM, Daniel Kulp wrote:
> >
> >
> > We've resolved over 40 issues since 2.7.4.   Not a lot, but it includes
> an OSGi fix that is blocking a Camel issues which may also be causing
> issues with the ServiceMix release.  This also affects CXF 2.6.x which
> affects Camel 2.10.x/ServiceMix 4.5.1 so I decided to do a 2.6.x release as
> well.
> >
> >
> > List of issues:
> > 2.6.8
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12324276
> > 2.7.5
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12324277
> >
> > The Maven staging areas are at:
> > 2.6.8
> > https://repository.apache.org/content/repositories/orgapachecxf-172/
> > 2.7.5
> > https://repository.apache.org/content/repositories/orgapachecxf-174/
> >
> > The distributions are in the org/apache/cxf/apache-cxf/ directory of the
> Maven staging areas.
> >
> > This releases are tagged at:
> > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.8
> > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.5
> >
> > This vote will be open for at least 72 hours.
> >
> >
>
>
> --
> Alessio Soldano
> Web Service Lead, JBoss
>

Re: [VOTE] Release Apache CXF 2.5.10/2.6.7/2.7.4

[David Bosschaert]

+1

David


On 28 March 2013 17:09, Daniel Kulp  wrote:

>
> We've resolved over 80 issues since 2.7.3, which is a bunch
>
>
> List of issues:
> 2.5.10
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12324007
> 2.6.7
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12324006
> 2.7.4
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12324005
>
> The Maven staging areas are at:  (forgot to close between 2.5.10 and 2.6.7)
> 2.5.10
> 2.6.7
> https://repository.apache.org/content/repositories/orgapachecxf-030/
> 2.7.4
> https://repository.apache.org/content/repositories/orgapachecxf-031/
>
>
> The distributions are in the org/apache/cxf/apache-cxf/ directory of the
> Maven staging areas.
>
>
> This releases are tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.10
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.7
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.4
>
> This vote will be open for at least 72 hours.
>
>
> Here's my +1.
>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

Re: [VOTE] CXF 2.7.3/2.6.6/2.5.9

[David Bosschaert]

+1

David


On 29 January 2013 08:30, Daniel Kulp  wrote:

>
>
>
> We've resolved over 35 issues since 2.7.2.  Not a huge number, but
> sufficient.
>
>
> List of issues:
> 2.5.9
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12323912
> 2.6.6
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12323911
> 2.7.3
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12323910
>
> The Maven staging areas are at:
> 2.5.9
> https://repository.apache.org/content/repositories/orgapachecxf-184/
> 2.6.6
> https://repository.apache.org/content/repositories/orgapachecxf-185/
> 2.7.3
> https://repository.apache.org/content/repositories/orgapachecxf-187/
>
> The distributions are in the org/apache/cxf/apache-cxf/ directory of the
> Maven staging areas.
>
>
> This releases are tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.9
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.6
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.3
>
> This vote will be open for at least 72 hours.
>
>
> Here's my +1.
>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

Re: [VOTE] Apache DOSGi 1.4.0 Release

[David Bosschaert]

Hi Christian,

I had a brief look at it and the demos that I tried with it worked. However
I did find some other issues:
* The Multi-Bundle distro Felix configuration files specify
the org.osgi.framework.system.packages framework property. They shouldn't
really do this (IMHO) and I've created bug DOSGI-155 for that.
* I ran the updated framework through the OSGi RemoteServices and
RemoteServiceAdmin Conformance Testsuites and some new failures have
appeared in this release. See DOSGI-156 for more details.

I think that many improvements have been made to reach 1.4.0 and I don't
think the above issues should block this release. I think we should try to
fix them for a 1.4.1 release that we should do in the near future.

In the mean time:
* People can work around DOSGI-155 by modifying these configuration files
themselves if the org.osgi.framework.system.packages value is not correct
for their environment.
* I will try to spend some time trying to the OSGi tests passing again. I
have been running against the Enterprise R5 CT. I just noticed that this is
not yet available in https://svn.apache.org/repos/tck/osgi-cts [3]. I'll
work on getting it in there too.

An email of this length is a bit unusual for a simple vote email, but
here's my +1 for releasing this as I think that despite the issues it would
be useful to release this so that people can continue testing and working
with it.

Best regards,

David

[1] https://issues.apache.org/jira/browse/DOSGI-155
[2] https://issues.apache.org/jira/browse/DOSGI-156
[3]
http://felix.apache.org/documentation/development/using-the-osgi-compliance-tests.html


On 22 January 2013 19:47, Christian Schneider wrote:

> The Apache CXF DOSGi subproject is the Reference Implementation of the
> OSGi Remote Services and
> Remote Services Admin Service specifications [1] which provide a
> distributed computing model based around OSGi Services.
>
> The CXF DOSGi 1.4.0 release contains the following fixes and improvements:
>
>  * 41 issues resolved (see jira)
>
> 
> >
>  * Karaf feature for easy installation in Apache Karaf
>
> 
> >
>  * Zookeeper discovery 
> >
> now
>supports automatic reconnects and Cluster configuration
>  * DOSGi is now independent of spring dm
>  * Custom intents are now created by publishing e.g. CXF Features as
>services
>  * Big refactorings make the code much easier to understand
>
> Also see the release notes:
> http://svn.apache.org/repos/**asf/cxf/dosgi/tags/cxf-dosgi-**
> ri-1.4.0/distribution/sources/**src/main/release/release_**notes.txt
>
> Staging area:
> https://repository.apache.org/**content/repositories/**orgapachecxf-155/
>
> The vote will be open for at least 72 hours.
>
> Here's my +1.
>
> Best regards,
>
> Christian
>
> [1] Chapters 13 and 122 in the OSGi 4.2 Enterprise Specification at
> http://www.osgi.org/Download/**Release4V42
>
> --
>  Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>

Re: DOSGi release next tuesday

[David Bosschaert]

+1 sounds good to me!

David


On 16 January 2013 14:17, Christian Schneider wrote:

> We just fixed the last issue in version 1.4 of DOSGi. So I would like to
> do a release next tuesday.
>
> See
> https://issues.apache.org/jira/browse/DOSGI/fixforversion/12319877
>
> Optionally we can include the two issues below:
> https://issues.apache.org/jira/browse/DOSGI-106
> https://issues.apache.org/jira/browse/DOSGI-152
>
> Is the release date ok with everyone?
>
> Christian
>
>

Re: [VOTE] Apache CXF 2.5.8/2.6.5/2.7.2

[David Bosschaert]

+1

David


On 7 January 2013 07:30, Alessio Soldano  wrote:

> +1
>
> Alessio
>
> On 01/04/2013 11:22 PM, Daniel Kulp wrote:
> >
> >
> > We've resolved over 35 issues since 2.7.1.  Not a huge number, but
> sufficient.
> >
> >
> > List of issues:
> > 2.5.8
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12323606
> > 2.6.5
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12323605
> > 2.7.2
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12323604
> >
> > The Maven staging areas are at:
> > 2.5.8
> > https://repository.apache.org/content/repositories/orgapachecxf-99/
> > 2.6.5
> > https://repository.apache.org/content/repositories/orgapachecxf-100/
> > 2.7.2
> > https://repository.apache.org/content/repositories/orgapachecxf-101/
> >
> > The distributions are in the org/apache/cxf/apache-cxf/ directory of the
> Maven staging areas.
> >
> >
> > This releases are tagged at:
> > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.8
> > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.5
> > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.2
> >
> > This vote will be open for at least 72 hours.
> >
> >
> > Here's my +1.
> >
> >
>
>
> --
> Alessio Soldano
> Web Service Lead, JBoss
>

Re: [VOTE] Apache CXF 2.5.7/2.6.4/2.7.1

[David Bosschaert]

+1 from me too.

David


On 7 December 2012 14:41, Daniel Kulp  wrote:

>
> We've resolved over 110 issues since 2.7.0.   That's a very large number
> for a patch release so we definitely should get this out.   Over 90 were
> ported back to 2.6.4, again, a large number.
>
>
> List of issues:
> 2.5.7
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12323349
> 2.6.4
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12323348
> 2.7.1
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12323347
>
> The Maven staging areas are at:
> 2.5.7
> https://repository.apache.org/content/repositories/orgapachecxf-120/
> 2.6.4
> https://repository.apache.org/content/repositories/orgapachecxf-121/
> 2.7.1
> https://repository.apache.org/content/repositories/orgapachecxf-122/
>
>
> The distributions are in the org/apache/cxf/apache-cxf/ directory of the
> Maven staging areas.
>
>
> This releases are tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.7
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.4
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.1
>
> This vote will be open for at least 72 hours.
>
>
> Here's my +1.
>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

Re: CXF-DOSGI: Update to Java 1.6?

[David Bosschaert]

Sounds like a good idea to me.

David


On 29 November 2012 10:16, Christian Schneider wrote:

> I would like to update CXF-DOSGi to Java 1.6. This gets us in sync again
> with CXF which also uses 1.6 now.
> The advantage is that we avoid some API constraint warnings and do not
> need to import APIs like JAXWS.
> Java 1.6 also allows to use @Override for methods defined in interfaces
> which gives some safety.
>
> What do you think?
>
> Christian
>

Re: CXF DOSGi: Idea for replacement of IntentMap reading

[David Bosschaert]

Contributing new intents using the whiteboard pattern. Sounds like an
interesting idea!

One thing you could think of is to create a separate bundle that provides
backward compatibility. I mean it could read the intent-map.xml (using any
XML parser, doesn't have to be Spring) as we have it today and register the
appropriate whiteboard services. If people don't need to
backward compatibility they wouldn't install this bundle...

Just my 2c,

David


On 16 November 2012 10:50, Christian Schneider wrote:

> On 11/16/2012 11:33 AM, Sergey Beryozkin wrote:
> > Hi Christian
> >
> > I'm not sure anyone uses custom intents, there were some ideas from
> > users on how to get custom intents, suggesting how it can be done
> > based on the existing approach but it was too difficult as far as I
> > recall. So what you suggest seems more flexible and OSGI-friendly.
> >
> > Typically, reacting to an intent means adding a CXF-level interceptor.
> > How will it work with your approach ?
> >
> Basically it is the same with my aproach. We get the intent map using a
> service instead of directly reading the config file but everything after
> this point is the same.
> The only thing I can imagine is that there may be a timing issue. When
> we check for services of type intent map before the service is exported
> we have a problem.
>
> Christian
>
>

Re: CXF-DOSGi release in about two weeks?

[David Bosschaert]

On 12 November 2012 16:34, Daniel Kulp  wrote:

>
> Personally, I kind of prefer that latter.   The DOSGi stuff has been kind
> of languishing a bit.  If we can start a process of smaller, incremental
> but more often releases that add stuff in, I'd be much happier.   Getting
> things into the hands of the users sooner isn't a bad thing.  :-)The
> entire Release Early, Release Often mantra.
>
>
+1, this would be my preference too.

David

Re: CXF-DOSGi should we support an eclipse update site?

[David Bosschaert]

Hi Christian,

The more features like to this to make it easy to use CXF-DOSGi the better IMHO.

As an aside, I was doing some work on creating an OSGi Subsystem
archive for the multi-bundle distro. This would give you a single
cxfdosgi.esa file which then contains all the bundles just like the
multi-bundle distro. It would effectively give you the ease-of-use of
the single-bundle distro, but still provide the full modularity that
the multi-bundle distro has.

Unfortunately I haven't been able to finish this yet. If anyone else
beats me to it, feel free to go ahead :)
BTW The OSGi Subsystem spec is a new OSGi specification that's part of
the Enterprise R5 spec [1].

Cheers,

David

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

On 12 November 2012 10:09, Christian Schneider  wrote:
> Hi all,
>
> we currently have the single bundle and multi bundle distributions for
> CXF-DOSGi. These are ok for pure Equinox and Felix frameworks.
> For Apache Karaf we will have a feature file in the next version that
> makes using DOSGi really simple there.
>
> I wonder if we should support an Eclipse Update Site for DOSGi to make
> it similarly easy to use in Eclipse RCP applications.
> Perhaps there are even other options.
>
> Christian
>

Re: CXF-DOSGi release in about two weeks?

[David Bosschaert]

Hi Christian,

Sounds great and I think the work you've done and the work you're
proposing to do is a great step forward.

However, some of the features that you've planned are fairly large,
and I would wonder whether it's feasible to have them all added and
stable within 2 weeks.
Would it not be better to implement all of these first and then call
for the release when it's all ready?

Alternatively, if, for some reason you are unable to finish all of the
work that you're planning to do, we could still do a release with the
features that made it and delay the other ones to an later release,
IMHO...

Cheers,

David

On 12 November 2012 10:04, Christian Schneider  wrote:
> Hi all,
>
> There are a lot of new features in the CXF DOSGi implementation. I would
> like to do a release of DOSGi in about two weeks. What do you think
> about it?
> Here are the done and planned features.
>
> Highlights:
> - Karaf Feature file for DOSGi
> - Reconnection support for Zookeeper discovery
>
> I am planning to do these additional features before the release:
> - Switch logging to slf4j-api
> - Use pax logging for all distributions
> - Support Zookeeper in Cluster mode
> - Remove Spring dependency (switch intention map support to OSGi service)
>
> Christian
>
> Here are the detailed issues:
> https://issues.apache.org/jira/browse/DOSGI/fixforversion/12319877#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel
>
>

Re: CXF-DSOGI: Proposal to switch logging to slf4j

[David Bosschaert]

No objection from me either.

Best regards,

David

On 31 October 2012 14:45, Daniel Kulp  wrote:
>
> On Oct 31, 2012, at 7:15 AM, Christian Schneider  
> wrote:
>
>> Hi all,
>>
>> currently we use a mix of log4j and util logging in CXF-DOSGi.
>
> That definitely should be fixed.   Not sure why we would have had a mix like 
> that.
>
>
>> I just saw that zookeeper changed their logging to slf4j. It seems their 
>> current release is not completely correct but I am sure they will soon work 
>> fine with just slf4j as an import.
>> As CXF-DOSGi only runs on OSGi and slf4j is the simplest way to support 
>> logging on OSGi I propose we switch the logging to slf4j. So we are in line 
>> with Apache Karaf and Zookeeper.
>
> The main concern I would have had is if any of the CXF-DOSGi code used the 
> Messages.properties resource bundles for the logging messages like the main 
> CXF code does.  However, I just did a quick search through the DOSGi code and 
> don't see any of them.  Apparently not used there.
>
> Thus, I don't really have any major objection to it.
>
> Dan
>
>
>> Please also see the two related issues in jira:
>> https://issues.apache.org/jira/browse/DOSGI-135
>> https://issues.apache.org/jira/browse/DOSGI-132
>>
>> So what do you think?
>>
>> Best regards
>>
>> Christian
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>

Re: [VOTE] Release Apache CXF 2.4.10, 2.5.6, 2.6.3

[David Bosschaert]

+1

David

On 6 October 2012 12:40, Daniel Kulp  wrote:
>
>
> We've resolved over 48 issues since 2.6.2 with a bunch of them fairly 
> important.
>
> List of issues:
> 2.4.10
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12322966
> 2.5.6
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12322965
> 2.6.3
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12322964
>
>
> The Maven staging areas are at:
> 2.4.10
> https://repository.apache.org/content/repositories/orgapachecxf-093/
> 2.5.6
> https://repository.apache.org/content/repositories/orgapachecxf-094/
> 2.6.3
> https://repository.apache.org/content/repositories/orgapachecxf-095/
>
> The distributions are in the org/apache/cxf/apache-cxf/ directory of the 
> Maven staging areas.
>
>
> This releases are tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.10
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.6
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.3
>
> This vote will be open for at least 72 hours.
>
>
> Here's my +1.
>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>

Re: [VOTE] Apache CXF 2.7.0

[David Bosschaert]

+1

David

On 6 October 2012 12:43, Daniel Kulp  wrote:
>
> It's been 6 months since 2.6.x was first released and thus time for the next 
> big thing.  :-)
>
> We have several new features including two new transports (UDP and an Async 
> based HTTP transport), WS-Discovery support, many JAX-RS enhancements while 
> on the road to 2.0 support, etc….
>
>
> The Maven staging area is at:
> https://repository.apache.org/content/repositories/orgapachecxf-098/
>
> The distributions are in the org/apache/cxf/apache-cxf/ directory of the 
> Maven staging areas.
>
> This releases are tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.0
>
> Migration guide is at:
> http://cxf.apache.org/docs/27-migration-guide.html
>
> Vote will be open for 72 hours.
>
> Here is my +1.
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>

Re: [VOTE] Release Apache CXF 2.4.9/2.5.5/2.6.2

[David Bosschaert]

+1

David

On 15 August 2012 02:20, Daniel Kulp  wrote:
>
> We've resolved over 80 issues since 2.6.1 and we're a little overdue for a 
> release.
>
> List of issues:
> 2.4.9
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12321666
> 2.5.5
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12321667
> 2.6.2
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12321668
>
>
> The Maven staging areas are at:
> 2.4.9
> https://repository.apache.org/content/repositories/orgapachecxf-001/
> 2.5.5
> https://repository.apache.org/content/repositories/orgapachecxf-002/
> 2.6.2
> https://repository.apache.org/content/repositories/orgapachecxf-004/
>
> The distributions are in the org/apache/cxf/apache-cxf/ directory of the 
> Maven staging areas.
>
>
> This releases are tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.9
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.5
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.2
>
> This vote will be open for at least 72 hours.
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>

Using CXF-DOSGi in a Cloud scenario

[David Bosschaert]

Hi all,

FYI - I started using CXF-DOSGi in a cloud scenario and have been
playing with potential enhancements that can be useful in this
context. I've shared my experiences here:
http://coderthoughts.blogspot.com/2012/07/controlling-osgi-services-in-cloud.html

Thoughts and feedback much appreciated.

David

Re: Thoughts about DOSGI 1.3.2 release

[David Bosschaert]

On 11 July 2012 22:42, Sergey Beryozkin  wrote:
> Hi David, All
>
> So far I'm really behind the target of getting DOSGI 1.3.2 released around
> this time of the year. I'm managed to get a bit of time and resolved
> DOSGI-111, however it's difficult for me right now to prioritize on other
> DOSGI JIRAs - I'm a bit overwhelmed with the current and the incoming
> (JAX-)RS related tasks. Somehow, Jettison
> 1.3.2 will have to be released as well.
>
> However I'm intending to keep the process going - the plan is to attempt to
> fix at least one specific JIRA, particularly to do with managing multiple
> contexts, etc, every 2 or so weeks. Not perfect :-), but there will be some
> progress.
>
> David, I've seen you creating a new subsystem distribution.
> Will it let us drop a single bundle distro ?

Hi Sergey,

Yes I started on the subsystem distro. This will be usable with
implementations of the OSGi Enterprise R5 subsystem specification [1].
Currently the build process is not ideal and contains some hardcoded
stuff, so the subsystem distribution is not ready. There has been some
discussion in the Aries user list in relation to a maven plugin that
will smoothen this out [2].
The subsystem distro will combine the convenience of the single bundle
distro with the modularity of the multi-bundle distro. The best of
both worlds :)
However, I'm not sure whether it will completely replace the single
bundle distro. It requires a subsystem implementation to be present in
the OSGi framework and not everyone may have this.

Additionally, I added some stuff in the discovery area:
* Fixed a NPE when remote services with non-supported service
registration properties were put in the Discovery Server.
* Added a Discovery Plugin (experimental) that allows the
transformation of discovery information.

Cheers,

David

[1] Chapter 134 of the Enterprise Spec in http://www.osgi.org/Download/Release5
[2] 
http://mail-archives.apache.org/mod_mbox/aries-user/201207.mbox/%3C2A06A984-24E5-4793-A716-E0816CAF333A%40yahoo.com%3E

Re: CXF-DOSGi Zookeeper discovery data transformation

[David Bosschaert]

Hi Sergey,

On 25 June 2012 11:32, Sergey Beryozkin  wrote:
>> The plugin also allows you to change the path where it is changed by
>> returning a different path, so for example in my case the fullPath
>> variable is
>>   /osgi/service_registry/org/acme/foo/SomeInterface/127.0.0.1#8080##foo
>> It would allow you to change that to something like
>>   /osgi/service_registry/org/acme/foo/SomeInterface/my.cloud.host#80##foo
>>
> Sounds good. Minor observation is I guess that the plugin would only be
> interested in replacing the the "127.0.0.1#8080##foo" part, and if yes then
> may be it will be marginally simpler to have:
>
> String process(Map mutableProperties,
>               String registryPath,
>               String hostInformation);
>
> String actualHostInfo = plugin.process(properties,
>
> "/osgi/service_registry/org/acme/foo/SomeInterface",
>                                       "127.0.0.1#8080##foo");
>
> Not sure if it make sense :-). Having a plugin to do a basic parsing of the
> fullPath would not ne a big issue I guess :-)

Good point. Changing the registryPath doesn't make sense, so I removed
it completely from the callback.
It now has the following API:

String process(Map mutableProperties, String endpointKey);

I've committed it all with unit tests in r1353598.

Cheers,

David

Re: CXF-DOSGi Zookeeper discovery data transformation

[David Bosschaert]

Hi Sergey,

On 22 June 2012 17:43, Sergey Beryozkin  wrote:
> Hi David
>
> On 22/06/12 15:58, David Bosschaert wrote:
>>
>> Hi all,
>>
>> I'm currently playing with CXF-DOSGi in the context of a cloud setup
>> and I'm also using the Zookeeper-based discovery.
>> The problem that I'm facing is that the host and port as known by the
>> local framework (running inside a cloud instance) is not the same as
>> the public host and port. Obviously to be able to access the remoted
>> service from outside you need the public host and port.
>>
>> So I came up with a DiscoveryPlugin interface which bundles can
>> register in the OSGi Service Registry (in the true OSGi Whiteboard
>> pattern way) to support such a transformation.
>> It has the following API:
>>
>> public interface DiscoveryPlugin {
>>     String process(Map  mutableMap, String fullPath);
>> }
>>
>> Before the ZooKeeper client code in CXF registers the endpoint with
>> the ZooKeeper server all registered DiscoveryPlugin are given a chance
>> to process the data. They can change the properties of the service
>> registration and change the path. So in my case I can change the URL
>> where the local framework thinks it registers it (e.g.
>> 127.5.3.123:8080) to the URL from where things are publicly accessible
>> (e.g. my.cloud.instance:80).
>>
>> Would everyone be happy with me adding this feature to the
>> cxf-dosgi-ri-discovery-distributed module? It's backward compatible -
>> if you have no plugins registered nothing happens.
>>
> Looks like a neat idea.
>
> What does mutableMap will represent ?

You're right - I could have made that a little more clear :) It
represents the service registration properties that will be stored in
ZooKeeper. For an example service they look like this:

  endpoint.framework.uuid=609a4e6b-9abe-0011-1888-adf8693241e9,
  endpoint.id=http://127.0.0.1:8080/repo,
  endpoint.package.version.org.acme.foo=1.0.0.SNAPSHOT
  endpoint.service.id=44,
  objectClass=[org.acme.foo.SomeInterface],
  org.apache.cxf.ws.address=http://127.0.0.1:8080/repo,
  service.imported.configs=[org.apache.cxf.ws],
  service.imported=true,
  service.intents=[SOAP.1_1, HTTP, SOAP],

So it might be more appropriate to call the argument mutableProperties
instead of mutableMap (I'll make sure to add proper JavaDoc too :).
Whatever you change in that map will be stored in ZooKeeper using the
changed value (note that the actual service registration in the local
framework doesn't change).

The plugin also allows you to change the path where it is changed by
returning a different path, so for example in my case the fullPath
variable is
  /osgi/service_registry/org/acme/foo/SomeInterface/127.0.0.1#8080##foo
It would allow you to change that to something like
  /osgi/service_registry/org/acme/foo/SomeInterface/my.cloud.host#80##foo

Cheers,

David

CXF-DOSGi Zookeeper discovery data transformation

[David Bosschaert]

Hi all,

I'm currently playing with CXF-DOSGi in the context of a cloud setup
and I'm also using the Zookeeper-based discovery.
The problem that I'm facing is that the host and port as known by the
local framework (running inside a cloud instance) is not the same as
the public host and port. Obviously to be able to access the remoted
service from outside you need the public host and port.

So I came up with a DiscoveryPlugin interface which bundles can
register in the OSGi Service Registry (in the true OSGi Whiteboard
pattern way) to support such a transformation.
It has the following API:

public interface DiscoveryPlugin {
String process(Map mutableMap, String fullPath);
}

Before the ZooKeeper client code in CXF registers the endpoint with
the ZooKeeper server all registered DiscoveryPlugin are given a chance
to process the data. They can change the properties of the service
registration and change the path. So in my case I can change the URL
where the local framework thinks it registers it (e.g.
127.5.3.123:8080) to the URL from where things are publicly accessible
(e.g. my.cloud.instance:80).

Would everyone be happy with me adding this feature to the
cxf-dosgi-ri-discovery-distributed module? It's backward compatible -
if you have no plugins registered nothing happens.

Cheers,

David

Re: CXF-DOSGi Logging

[David Bosschaert]

Hi Bert,

I agree, there's too much noise from the log messages. Improving that would
certainly be nice.

Cheers,

David

On Thursday, 14 June 2012, jbert  wrote:
> Hey,
>
> I've been using DOSGi for a while, but what annoys me most is that either
I
> get no logging, or I get spammed with INFO messages which don't mean much
to
> me seeing how I just use DOSGi as a library to expose web-services.
>
> I've opened a bug report to bundle a few other annoyances (logging to the
> standard output/error streams) and attached a patch. Could someone review
it
> and give some feedback? I'd love to see this get fixed in a next release.
>
>
> With best regards,
>
> Bert
>
>
> --
> View this message in context:
http://cxf.547215.n5.nabble.com/CXF-DOSGi-Logging-tp5709834.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>

Re: [VOTE] Apache CXF 2.3.11/2.4.8/2.5.4/2.6.1

[David Bosschaert]

+1

David

On 30 May 2012 19:15, Daniel Kulp  wrote:
>
>
> We've resolved over 90 issues since 2.6.0 was released. We've back ported
> over 70 of them to 2.5.4 and 40 to 2.4.8 and 25 to 2.3.11.
>
>
> List of issues:
> 2.3.11:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12320749
> 2.4.8:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12320748
> 2.5.4:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12320747
> 2.6.1:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12320746
>
>
> The Maven staging areas are at:
> 2.3.12:
> https://repository.apache.org/content/repositories/orgapachecxf-149/
> 2.4.8:
> https://repository.apache.org/content/repositories/orgapachecxf-159/
> 2.5.4:
> https://repository.apache.org/content/repositories/orgapachecxf-160/
> 2.6.1:
> https://repository.apache.org/content/repositories/orgapachecxf-161/
>
>
> The distributions are in the org/apache/cxf/apache-cxf/ directory of the
> Maven staging areas.
>
>
> This releases are tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.11
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.8
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.4
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.1
>
>
> This vote will be open for at least 72 hours.
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com

Re: Thoughts about DOSGI 1.3.2 release

[David Bosschaert]

Migrating to blueprint will also solve
https://issues.apache.org/jira/browse/DOSGI-69 which is a
long-standing issue that many people want to see resolved.

David

On 28 May 2012 18:51, Sergey Beryozkin  wrote:
> FYI:
>
> https://issues.apache.org/jira/browse/DOSGI-115
>
> The proposed fix will probably work with Gemini straight away :-)
>
> Sergey
>
>
> On 28/05/12 18:45, Sergey Beryozkin wrote:
>>
>> On 28/05/12 18:35, David Bosschaert wrote:
>>>
>>> I can understand that it's a significant refactoring.
>>>
>>> If you stay within the pure Blueprint model (within the spec) you
>>> shouldn't get bound to Aries. Eclipse Gemini also has an
>>> implementation.
>>
>>
>> Sure and there was a proposal on how to get Gemini used under the hood,
>> but the issue is how to get both used as needed.
>>
>> Having DOSGi migrated to Blueprint and CXF 2.6.x would obviously improve
>> DOSGi CXF a lot, specifically, its OSGI-'awareness' would increase a lot.
>>
>> But as I said, there are still quite a few issues in this list:
>>
>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=project+%3D+DOSGI+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC
>>
>>
>> which IMHO are quite important to get fixed for the users be able to do
>> their POCs, before making a big 'leap' forward.
>>
>> Unfortunately I can not afford spending several weeks on migrating the
>> code to Blueprint, testing with Aries & Gemini, etc...Perhaps we will
>> get a bit of help from DOSGI CXF users :-)
>>
>> Cheers, Sergey
>>
>>>
>>> Cheers,
>>>
>>> David
>>>
>>> On 28 May 2012 18:17, Sergey Beryozkin wrote:
>>>>
>>>> Hi David
>>>>
>>>> On 28/05/12 18:09, David Bosschaert wrote:
>>>>>
>>>>>
>>>>> Sounds good, Sergey. I'm all for releasing frequently.
>>>>>
>>>>> One of the things that I think would be good to tackle is to migrate
>>>>> to OSGi Blueprint (from of the current Spring-based approach). Is that
>>>>> something that you were thinking of looking at?
>>>>>
>>>> Not really. Some users would like to use Blueprint but not be bound to
>>>> Aries. So for me it's a DOSGI 1.4 level issue which will require a
>>>> significant time investment.
>>>>
>>>> Cheers, Sergey
>>>>
>>>>> Cheers,
>>>>>
>>>>> David
>>>>>
>>>>> On 28 May 2012 17:34, Sergey Beryozkin wrote:
>>>>>>
>>>>>>
>>>>>> Hi
>>>>>>
>>>>>> I'm thinking of starting working toward releasing DOSGI 1.3.2.
>>>>>> I think I'll spend the next 2 or months on fixing few issues I can
>>>>>> find
>>>>>> some
>>>>>> time for, given that there's a lot of other CXF/etc work that needs
>>>>>> to be
>>>>>> taken care of.
>>>>>> I'd like to suggest that the next release will be 1.3.2 as opposed to
>>>>>> 1.4.0.
>>>>>> Moving to CXF 2.6.1 at the DOSGI level will be a pretty major effort,
>>>>>> giving
>>>>>> that a minimal bundle in CXF 2.6.x has gone.
>>>>>>
>>>>>> It seems that there are still quite a few issues there that are
>>>>>> important
>>>>>> to
>>>>>> be fixed for the base/simple DOSGI applications to work reliably and
>>>>>> given
>>>>>> that 2.5.x branch is still relatively 'young', I'd probably prefer to
>>>>>> stay
>>>>>> on 2.5.x (2.5.4 for DOSGI 1.3.2 and might be CXF 2.5.5/2.5.6 for DOSGI
>>>>>> 1.3.3), simply to make the most of the limited time that I will be
>>>>>> able
>>>>>> to
>>>>>> spend on DOSGi, before making a major switch to CXF 2.6.x - and
>>>>>> hoping by
>>>>>> that time many of the 'basic' DOSGI features have been fixed...
>>>>>>
>>>>>> Thanks, Sergey
>>>>>>
>>>>
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com

Re: Thoughts about DOSGI 1.3.2 release

[David Bosschaert]

I can understand that it's a significant refactoring.

If you stay within the pure Blueprint model (within the spec) you
shouldn't get bound to Aries. Eclipse Gemini also has an
implementation.

Cheers,

David

On 28 May 2012 18:17, Sergey Beryozkin  wrote:
> Hi David
>
> On 28/05/12 18:09, David Bosschaert wrote:
>>
>> Sounds good, Sergey. I'm all for releasing frequently.
>>
>> One of the things that I think would be good to tackle is to migrate
>> to OSGi Blueprint (from of the current Spring-based approach). Is that
>> something that you were thinking of looking at?
>>
> Not really. Some users would like to use Blueprint but not be bound to
> Aries. So for me it's a DOSGI 1.4 level issue which will require a
> significant time investment.
>
> Cheers, Sergey
>
>> Cheers,
>>
>> David
>>
>> On 28 May 2012 17:34, Sergey Beryozkin  wrote:
>>>
>>> Hi
>>>
>>> I'm thinking of starting working toward releasing DOSGI 1.3.2.
>>> I think I'll spend the next 2 or months on fixing few issues I can find
>>> some
>>> time for, given that there's a lot of other CXF/etc work that needs to be
>>> taken care of.
>>> I'd like to suggest that the next release will be 1.3.2 as opposed to
>>> 1.4.0.
>>> Moving to CXF 2.6.1 at the DOSGI level will be a pretty major effort,
>>> giving
>>> that a minimal bundle in CXF 2.6.x has gone.
>>>
>>> It seems that there are still quite a few issues there that are important
>>> to
>>> be fixed for the base/simple DOSGI applications to work reliably and
>>> given
>>> that 2.5.x branch is still relatively 'young', I'd probably prefer to
>>> stay
>>> on 2.5.x (2.5.4 for DOSGI 1.3.2 and might be CXF 2.5.5/2.5.6 for DOSGI
>>> 1.3.3), simply to make the most of the limited time that I will be able
>>> to
>>> spend on DOSGi, before making a major switch to CXF 2.6.x - and hoping by
>>> that time many of the 'basic' DOSGI features have been fixed...
>>>
>>> Thanks, Sergey
>>>
>

Re: Thoughts about DOSGI 1.3.2 release

[David Bosschaert]

Sounds good, Sergey. I'm all for releasing frequently.

One of the things that I think would be good to tackle is to migrate
to OSGi Blueprint (from of the current Spring-based approach). Is that
something that you were thinking of looking at?

Cheers,

David

On 28 May 2012 17:34, Sergey Beryozkin  wrote:
> Hi
>
> I'm thinking of starting working toward releasing DOSGI 1.3.2.
> I think I'll spend the next 2 or months on fixing few issues I can find some
> time for, given that there's a lot of other CXF/etc work that needs to be
> taken care of.
> I'd like to suggest that the next release will be 1.3.2 as opposed to 1.4.0.
> Moving to CXF 2.6.1 at the DOSGI level will be a pretty major effort, giving
> that a minimal bundle in CXF 2.6.x has gone.
>
> It seems that there are still quite a few issues there that are important to
> be fixed for the base/simple DOSGI applications to work reliably and given
> that 2.5.x branch is still relatively 'young', I'd probably prefer to stay
> on 2.5.x (2.5.4 for DOSGI 1.3.2 and might be CXF 2.5.5/2.5.6 for DOSGI
> 1.3.3), simply to make the most of the limited time that I will be able to
> spend on DOSGi, before making a major switch to CXF 2.6.x - and hoping by
> that time many of the 'basic' DOSGI features have been fixed...
>
> Thanks, Sergey
>

Re: [VOTE] Apache CXF 2.3.10/2.4.7/2.5.3

[David Bosschaert]

+1

David

On 12 April 2012 21:23, Daniel Kulp  wrote:
>
> We've resolved over 110 issues since 2.5.2 which is a very large amount.
> We've back ported over 75 of them to 2.4.7 and 25 to 2.3.10.   These patch
> releases are certainly overdue.
>
>
> List of issues:
> 2.3.10:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12319493
> 2.4.7:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12319492
> 2.5.3:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12319491
>
>
> The Maven staging areas are at:
> 2.3.10:
> https://repository.apache.org/content/repositories/orgapachecxf-033/
> 2.4.7:
> https://repository.apache.org/content/repositories/orgapachecxf-034/
> 2.5.3:
> https://repository.apache.org/content/repositories/orgapachecxf-038/
>
>
> The distributions are in the org/apache/cxf/apache-cxf/ directory of the
> Maven staging areas.
>
>
> This releases are tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.10
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.7
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.3
>
>
> This vote will be open for at least 72 hours.
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com

Re: [VOTE] Release Apache CXF 2.6.0

[David Bosschaert]

+1

David

On 12 April 2012 21:26, Daniel Kulp  wrote:
>
> It's been 6 months since the 2.5.0 release and thus it's time for the 2.6
> release.   We've been VERY busy with many new features, lots of refactoring,
> bunch of OSGi enhancements, etc...  The migration guide at:
>
> http://cxf.apache.org/docs/26-migration-guide.html
>
> is certainly one of the "longest" migration guides we've had, although a
> large part of the reason for that is the extra extensive testing that's been
> done with 2.6.0 to identify as many issues as possible.
>
>
>
> The maven staging area:
> https://repository.apache.org/content/repositories/orgapachecxf-039/
>
> This release is tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.0
>
> The distributions are in the org/apache/cxf/apache-cxf/ directory of the
> Maven staging area.
>
>
>
> This vote will be open for at least 72 hours.
>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com

Re: [VOTE] Apache DOSGi 1.3.1 Release

[David Bosschaert]

I see the page has now updated itself. Apparently this takes longer
than it used to these days...

On 11 April 2012 07:34, David Bosschaert  wrote:
> Hi Matt,
>
> I have actually edited that page just after I sent the vote conclusion
> email yesterday but the edits didn't seem to have propagated to the
> 'real' page. In any case, you can download the singlebundle jar from
> maven via this link:
> http://repository.apache.org/service/local/repositories/releases/content/org/apache/cxf/dosgi/cxf-dosgi-ri-singlebundle-distribution/1.3.1/cxf-dosgi-ri-singlebundle-distribution-1.3.1.jar
>
> Does anybody know why
> https://cwiki.apache.org/confluence/display/CXF/DOSGi+Releases hasn't
> been copied to http://cxf.apache.org/dosgi-releases.html ? I thought
> that happened automatically...
>
> Cheers,
>
> David
>
> On 10 April 2012 21:32, mwsmith  wrote:
>> Hi David,
>>
>> Do you have an idea of when the 1.3.1 singlebundle jar will be available at
>> http://cxf.apache.org/dosgi-releases.html?  I'm experiencing difficulties
>> getting zookeeper configured with 1.3 (have had better luck with 1.2)...I
>> thought I'd give 1.3.1 a shot before posting a question about it.
>>
>> Thanks,
>> Matt
>>
>> --
>> View this message in context: 
>> http://cxf.547215.n5.nabble.com/VOTE-Apache-DOSGi-1-3-1-Release-tp5596697p5631093.html
>> Sent from the cxf-dev mailing list archive at Nabble.com.

Re: [VOTE] Apache DOSGi 1.3.1 Release

[David Bosschaert]

Hi Matt,

I have actually edited that page just after I sent the vote conclusion
email yesterday but the edits didn't seem to have propagated to the
'real' page. In any case, you can download the singlebundle jar from
maven via this link:
http://repository.apache.org/service/local/repositories/releases/content/org/apache/cxf/dosgi/cxf-dosgi-ri-singlebundle-distribution/1.3.1/cxf-dosgi-ri-singlebundle-distribution-1.3.1.jar

Does anybody know why
https://cwiki.apache.org/confluence/display/CXF/DOSGi+Releases hasn't
been copied to http://cxf.apache.org/dosgi-releases.html ? I thought
that happened automatically...

Cheers,

David

On 10 April 2012 21:32, mwsmith  wrote:
> Hi David,
>
> Do you have an idea of when the 1.3.1 singlebundle jar will be available at
> http://cxf.apache.org/dosgi-releases.html?  I'm experiencing difficulties
> getting zookeeper configured with 1.3 (have had better luck with 1.2)...I
> thought I'd give 1.3.1 a shot before posting a question about it.
>
> Thanks,
> Matt
>
> --
> View this message in context: 
> http://cxf.547215.n5.nabble.com/VOTE-Apache-DOSGi-1-3-1-Release-tp5596697p5631093.html
> Sent from the cxf-dev mailing list archive at Nabble.com.

Re: [VOTE] Apache DOSGi 1.3.1 Release

[David Bosschaert]

With 8 +1 votes this vote passes.

I'll promote the artifacts and update the download page.

Best regards,

David

On 28 March 2012 14:22, Jeff Genender  wrote:
> +1
>
> Jeff
>
> On Mar 28, 2012, at 3:13 AM, Colm O hEigeartaigh wrote:
>
>> +1.
>>
>> Colm.
>>
>> On Tue, Mar 27, 2012 at 7:02 PM, Daniel Kulp  wrote:
>>>
>>> +1
>>>
>>> Dan
>>>
>>>
>>> On Monday, March 26, 2012 09:00:40 PM David Bosschaert wrote:
>>>> The Apache CXF DOSGi subproject is the Reference Implementation of the
>>>> OSGi Remote Services and Remote Services Admin Service specifications
>>>> [1] which provide a distributed computing model based around OSGi
>>>> Services.
>>>>
>>>> We have been working on CXF-DOSGi release 1.3.1 which fixes issues
>>>> identified by the OSGi Remote Service Admin TCK when run on release
>>>> 1.3. For more details see the release notes:
>>>> http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.3.1/distribu
>>>> tion/sources/src/main/release/release_notes.txt
>>>>
>>>> Staging area:
>>>> https://repository.apache.org/content/repositories/orgapachecxf-101/
>>>>
>>>> The vote will be open for at least 72 hours.
>>>>
>>>> Here's my +1.
>>>>
>>>> Best regards,
>>>>
>>>> David
>>>>
>>>> [1] Chapters 13 and 122 in the OSGi 4.2 Enterprise Specification at
>>>> http://www.osgi.org/Download/Release4V42
>>> --
>>> Daniel Kulp
>>> dk...@apache.org - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>>
>>
>>
>>
>> --
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>

[VOTE] Apache DOSGi 1.3.1 Release

[David Bosschaert]

The Apache CXF DOSGi subproject is the Reference Implementation of the
OSGi Remote Services and Remote Services Admin Service specifications
[1] which provide a distributed computing model based around OSGi
Services.

We have been working on CXF-DOSGi release 1.3.1 which fixes issues
identified by the OSGi Remote Service Admin TCK when run on release
1.3. For more details see the release notes:
http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.3.1/distribution/sources/src/main/release/release_notes.txt

Staging area:
https://repository.apache.org/content/repositories/orgapachecxf-101/

The vote will be open for at least 72 hours.

Here's my +1.

Best regards,

David

[1] Chapters 13 and 122 in the OSGi 4.2 Enterprise Specification at
http://www.osgi.org/Download/Release4V42

Re: CXF-DOSGi and the OSGi Remote Service Admin TCK

[David Bosschaert]

On 22 March 2012 13:41, Sergey Beryozkin  wrote:
> I'm seeing 1.4-SNAPSHOT in poms, I guess I can update that easily later on
> to 1.3.2-SNAPSHOT as I won't have enough 'material' to call a 1.4 release in
> few months time, the upgrade to Blueprint would of course go to 1.4 :-), but
> I'm not sure when exactly it will happen...

Yes, I wasn't completely sure what the convention was. The poms
already contained 1.4-SNAPSHOT. I wasn't sure whether we wanted to
move back to 1.3.2-SNAPSHOT, but I would have no problems with it...

Cheers,

David

Re: CXF-DOSGi and the OSGi Remote Service Admin TCK

[David Bosschaert]

On 22 March 2012 11:13, Daniel Kulp  wrote:
> On Thursday, March 22, 2012 08:47:16 AM David Bosschaert wrote:
>> Yes, the changes to settings.xml helped. That got me past that issue.
>>
>> However, I ended up having some problems with the GPG side of things
>> (GPG on Mac OSX) - similar to [1] so I couldn't close the stage repo.
>> It seems like the artifacts were signed by a subkey which apparently
>> doesn't work. So it looks like I need to do things over again.
>> Does it harm doing mvn release:prepare and mvn release:perform a
>> second time with the same version? I guess this will mean that the tag
>> gets moved?
>
> Just make sure you "svn rm" the tag first.   Then it should be OK to just
> redo it.
>
> Dan

Ok, that seems to have worked now.
I have the CXF-DOSGi 1.3.1 artifacts staged here:
https://repository.apache.org/content/repositories/orgapachecxf-101/

Could someone please confirm that I did this correctly?

Before calling the vote I would like to run the actual artifacts
through the OSGi TCK to ensure that everything is still green.
Is there anything else that needs to be done before the vote can be called?

Cheers,

David

Re: CXF-DOSGi and the OSGi Remote Service Admin TCK

[David Bosschaert]

Yes, the changes to settings.xml helped. That got me past that issue.

However, I ended up having some problems with the GPG side of things
(GPG on Mac OSX) - similar to [1] so I couldn't close the stage repo.
It seems like the artifacts were signed by a subkey which apparently
doesn't work. So it looks like I need to do things over again.
Does it harm doing mvn release:prepare and mvn release:perform a
second time with the same version? I guess this will mean that the tag
gets moved?

Cheers,

David

[1] https://issues.sonatype.org/browse/OSSRH-1525

On 21 March 2012 20:44, Sergey Beryozkin  wrote:
> Yes, this is what I did.
>
> David, I think we also need to get your public gpg key added to
> http://pgp.mit.edu/, here are some links I found useful.
>
> http://irtfweb.ifa.hawaii.edu/~lockhart/gpg/gpg-cs.html
>
> https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+With+Maven
>
> You should be able to login to
> https://repository.apache.org/index.html#welcome
>
> with your apache login/password,
>
> This guide is good:
> http://www.apache.org/dev/publishing-maven-artifacts.html
>
> but this one on the Codehaus is also good:
> http://docs.codehaus.org/display/HAUSMATES/Codehaus+Maven+Repository+Usage+Guide
>
> HTH, thanks for deciding to give it a go :-) I'll get you a pint :-)
>
> Cheers, Sergey
>
>
>
>
> On 21/03/12 20:34, Daniel Kulp wrote:
>>
>>
>> David,
>>
>> Add to your ~/.m2/settings.xml something like:
>>
>>
>> 
>>     
>>         
>>             apache.releases.https
>>             dkulp
>>             yourapachepassword
>>         
>>    
>> 
>>
>> to setup your credentials needed to deploy to Nexus.   If that works, let
>> me
>> know and I'll update the release page.  (or feel free to update it)
>>
>>
>> Dan
>>
>>
>>
>> On Wednesday, March 21, 2012 07:55:24 PM David Bosschaert wrote:
>>>
>>> On 21 March 2012 19:09, David Bosschaert
>>
>> wrote:
>>>>
>>>> On 21 March 2012 15:34, Daniel Kulp  wrote:
>>>>>
>>>>> If you are willing to do the release, then I think it's a good idea.
>>>>>  I'd
>>>>> rather have a release often type thing if it fixes a few issue that are
>>>>> needed.    Do you know if it needs a new CXF proper release or is 2.5.2
>>>>> OK? If it's just a release of the DOSGi stuff, then it should be
>>>>> pretty simple. I think a simple:
>>>>>
>>>>> mvn release:prepare
>>>>> mvn release:perform
>>>>>
>>>>> should handle most of it.     The release-manangement page for cxf
>>>>> might
>>>>> have more details about setting up the gpg stuff, Nexus, etc...
>>>>
>>>>
>>>> It's the gpg and Nexus stuff that I'm unsure about in relation to how
>>>> releases are done at Apache, but I see things are documented well on
>>>> that page, so I'll give it a try soon.
>>>>
>>>> Cheers,
>>>>
>>>> David
>>>
>>>
>>> I successfully completed the release:prepare (I think) but the
>>> release:perform fails with the error below.
>>>
>>> Any ideas? Sergey, how did you do this before?
>>>
>>> David
>>>
>>>     [INFO] BUILD FAILURE
>>>     [INFO]
>>> 
>>> [INFO] Total time: 7.789s
>>>     [INFO] Finished at: Wed Mar 21 19:51:53 GMT 2012
>>>     [INFO] Final Memory: 10M/81M
>>>     [INFO]
>>> 
>>> [WARNING] The requested profile "deploy" could not be activated because
>>> it does not exist.
>>>     [ERROR] Failed to execute goal
>>> org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy
>>> (default-deploy) on project cxf-dosgi-ri: Failed to deploy artifacts:
>>> Could not transfer artifact
>>> org.apache.cxf.dosgi:cxf-dosgi-ri:pom:1.3.1 from/to
>>> apache.releases.https
>>> (https://repository.apache.org/service/local/staging/deploy/maven2):
>>> Failed to transfer file:
>>>
>>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apac
>>> he/cxf/dosgi/cxf-dosgi-ri/1.3.1/cxf-dosgi-ri-1.3.1.pom. Return code is:
>>> 401 ->  [Help 1]
>>> ... more stuff ...

Re: CXF-DOSGi and the OSGi Remote Service Admin TCK

[David Bosschaert]

On 21 March 2012 19:09, David Bosschaert  wrote:
> On 21 March 2012 15:34, Daniel Kulp  wrote:
>> If you are willing to do the release, then I think it's a good idea.  I'd
>> rather have a release often type thing if it fixes a few issue that are
>> needed.    Do you know if it needs a new CXF proper release or is 2.5.2 OK?
>> If it's just a release of the DOSGi stuff, then it should be pretty simple.
>> I think a simple:
>>
>> mvn release:prepare
>> mvn release:perform
>>
>> should handle most of it.     The release-manangement page for cxf might
>> have more details about setting up the gpg stuff, Nexus, etc...
>
> It's the gpg and Nexus stuff that I'm unsure about in relation to how
> releases are done at Apache, but I see things are documented well on
> that page, so I'll give it a try soon.
>
> Cheers,
>
> David

I successfully completed the release:prepare (I think) but the
release:perform fails with the error below.

Any ideas? Sergey, how did you do this before?

David

[INFO] BUILD FAILURE
[INFO] 

[INFO] Total time: 7.789s
[INFO] Finished at: Wed Mar 21 19:51:53 GMT 2012
[INFO] Final Memory: 10M/81M
[INFO] 

[WARNING] The requested profile "deploy" could not be activated
because it does not exist.
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy
(default-deploy) on project cxf-dosgi-ri: Failed to deploy artifacts:
Could not transfer artifact
org.apache.cxf.dosgi:cxf-dosgi-ri:pom:1.3.1 from/to
apache.releases.https
(https://repository.apache.org/service/local/staging/deploy/maven2):
Failed to transfer file:
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/cxf/dosgi/cxf-dosgi-ri/1.3.1/cxf-dosgi-ri-1.3.1.pom.
Return code is: 401 -> [Help 1]
... more stuff ...

Re: CXF-DOSGi and the OSGi Remote Service Admin TCK

[David Bosschaert]

On 21 March 2012 15:34, Daniel Kulp  wrote:
> If you are willing to do the release, then I think it's a good idea.  I'd
> rather have a release often type thing if it fixes a few issue that are
> needed.    Do you know if it needs a new CXF proper release or is 2.5.2 OK?
> If it's just a release of the DOSGi stuff, then it should be pretty simple.
> I think a simple:
>
> mvn release:prepare
> mvn release:perform
>
> should handle most of it.     The release-manangement page for cxf might
> have more details about setting up the gpg stuff, Nexus, etc...

It's the gpg and Nexus stuff that I'm unsure about in relation to how
releases are done at Apache, but I see things are documented well on
that page, so I'll give it a try soon.

Cheers,

David

Re: CXF-DOSGi and the OSGi Remote Service Admin TCK

[David Bosschaert]

Hi Sergey,

On 20 March 2012 22:09, Sergey Beryozkin  wrote:
> How does this Compendium cycle work ? Having CXF DOSGi RI 'endorced' as
> TCK-compliant is a strong enough reason to try to cut an interim release in
> the next few weeks, however, I'm wondering, when would be DOSGi CXF 1.3.1
> (released say in June/Jule) collected during the next cycle ?

The RI's don't get collected automatically. However during the RI/TCK
cycle of the Compendium 4.3 it was discovered that CXF-DOSGi had some
failures. That's when I started looking into things.
Every time an OSGi release is done, the TCKs are run with the RI
implementations that are checked in to the OSGi systems at that time.
So if there is a new CXF-DOSGi release we can always update the one in
the OSGi systems and have it be part of the next run.
The Compendium 4.3 run is due to close down really soon. The next
RI/TCK cycle after that is the Enterprise R5 cycle, which is currently
planned for June this year.

> I guess you are right in won't take long to quickly do another release, my
> priorities are all on CXF 2.6.0 (and related projects) due in 2-3 weeks, but
> I guess this can be done quickly enough. Personally I'd prefer to have at
> least couple of user-reported issues addressed along the way but I
> definitely have no time for it now,
>
> So if the collection can be easily organized in the next few months then I'd
> prefer to wait till then, but if not doing this release now would mean the
> collection will happen in one year time then I guess we should go for it.

So yes, we can certainly wait and have a released version checked in
for Enterprise R5, it will just mean that the Compendium R4.3 will
have a non-released version of CXF as the RI.

Cheers,

David

Re: CXF-DOSGi and the OSGi Remote Service Admin TCK

[David Bosschaert]

Hi Sergey,

On 20 March 2012 09:47, Sergey Beryozkin  wrote:
> Hi David
>
> On 20/03/12 08:00, David Bosschaert wrote:
>>
>> I just got confirmation that the current trunk of the CXF-DOSGi passes
>> the TCK again.
>
> Great news, thanks for the support from your side,
>
>> It would be *really* good if we could release this
>> version so that the Remote Services and RSA RI in the OSGi systems is
>> a released version of CXF-DOSGi rather than a snapshot. Sergey, could
>> I maybe ask you to do a release again?
>
> I'm planning to do a 1.3.1 release in the June/July time frame, few JIRAs
> have been opened against 1.3 so I'll try to address some of them too before
> cutting a new release.

The TCK compliance work I did was part of the OSGi 4.3 Compendium
cycle and I expect that the RIs for that (of which CXF-DOSGi is part)
will be collected soon - within 2 weeks is my guess, but I can get a
more detailed deadline if needed.
If we want a released version of CXF-DOSGi to be part of that RI, we
need to have that release before then. Otherwise they'll take the
current version which is based on a 1.4 snapshot...
Would there be an issue with just releasing what's there now (read:
really soon) and maybe do a 1.3.2 in June/July?
I've never done an Apache release so I'm not really sure how much work
is involved, but if it's just a matter of a few commands, I think it
would be worth it doing it now - but obviously that all depends on
time people have available too...

>> Here's a summary of the fixes:
>> * Fixed exports from Single Bundle Distro
>> * Fixed deadlock
>> * Fixed cleanup
>> * Fixed ExportReferenceImpl.equals() and hashCode()
>> * Fixed RemoteServiceAdminCore.exportService()
>>
>> As these issues are all exposed by the OSGi TCK I didn't write any
>> additional tests for them in the CXF-DOSGi codebase.
>> As an aside. Note that it is possible for Apache committers to run the
>> OSGi TCK. If anyone is interested let me know and I'll dig up the
>> details.
>
> Is that info in the public domain ? If yes then may be you can add this info
> to the DOSGi wiki ?

It is documented for Felix and Equinox projects that implement other
OSGi specs, but I'll take an action item to document this on the DOSGi
wiki as well.

Cheers,

David

Re: CXF-DOSGi and the OSGi Remote Service Admin TCK

[David Bosschaert]

I just got confirmation that the current trunk of the CXF-DOSGi passes
the TCK again. It would be *really* good if we could release this
version so that the Remote Services and RSA RI in the OSGi systems is
a released version of CXF-DOSGi rather than a snapshot. Sergey, could
I maybe ask you to do a release again?

Here's a summary of the fixes:
* Fixed exports from Single Bundle Distro
* Fixed deadlock
* Fixed cleanup
* Fixed ExportReferenceImpl.equals() and hashCode()
* Fixed RemoteServiceAdminCore.exportService()

As these issues are all exposed by the OSGi TCK I didn't write any
additional tests for them in the CXF-DOSGi codebase.
As an aside. Note that it is possible for Apache committers to run the
OSGi TCK. If anyone is interested let me know and I'll dig up the
details.

Cheers,

David

On 13 March 2012 07:30, David Bosschaert  wrote:
> Just a little update on this.
> I made some more changes and at this point in time we're getting
> close. For me the OSGi Remote Services and Remote Service Admin TCKs
> are 100% passing but other people did report a failure that we have to
> investigate a little further.
>
> I'll chime in again when everything is good, as we could do a release
> at that point.
>
> Cheers,
>
> David
>
> On 20 February 2012 22:38, Sergey Beryozkin  wrote:
>> Hi David
>>
>> On 19/02/12 00:42, David Bosschaert wrote:
>>>
>>> Hi all,
>>>
>>> I was recently running the CXF-DOSGi 1.3 release through the OSGi TCK
>>> to make sure it's still compliant with the spec.
>>> It turned out that the changes made between 1.2 and 1.3 cause a number
>>> of TCK failures, so I've been looking at fixing them.
>>> Here's a quick summary.
>>> * the single-bundle distro (which is used with the TCK) now includes
>>> the org.osgi.enterprise-4.2.0.jar. This is fine, but it didn't
>>> export/import the types defined in there which meant that these types
>>> existed twice in the VM, once inside the single bundle distro and once
>>> outside. This caused issues with ConfigAdmin and some event types
>>> since communication with the outside world wasn't possible with these
>>> types any more.
>>> I fixed this for the single-bundle distro (it doesn't apply to the
>>> multi-bundle distro).
>>> * ExportReferenceImpl, which is really a wrapper,  was used in a Map
>>> but missing hashCode and equals(). I added these.
>>> * There were some issues around close() calls not completely properly
>>> behaving, I fixed those
>>> * RemoteServiceAdminCore was putting objects of the wrong type in the
>>> collection returned by exportService()
>>>
>>> Some more changes may be needed in order to fully pass the TCK, but
>>> I've committed the above in r1290914.
>>>
>> Cool, guess you are thinking about 1.3.1 already :-)
>> Cheers, Sergey
>>
>>> Cheers,
>>>
>>> David
>>
>>

Re: CXF-DOSGi and the OSGi Remote Service Admin TCK

[David Bosschaert]

Just a little update on this.
I made some more changes and at this point in time we're getting
close. For me the OSGi Remote Services and Remote Service Admin TCKs
are 100% passing but other people did report a failure that we have to
investigate a little further.

I'll chime in again when everything is good, as we could do a release
at that point.

Cheers,

David

On 20 February 2012 22:38, Sergey Beryozkin  wrote:
> Hi David
>
> On 19/02/12 00:42, David Bosschaert wrote:
>>
>> Hi all,
>>
>> I was recently running the CXF-DOSGi 1.3 release through the OSGi TCK
>> to make sure it's still compliant with the spec.
>> It turned out that the changes made between 1.2 and 1.3 cause a number
>> of TCK failures, so I've been looking at fixing them.
>> Here's a quick summary.
>> * the single-bundle distro (which is used with the TCK) now includes
>> the org.osgi.enterprise-4.2.0.jar. This is fine, but it didn't
>> export/import the types defined in there which meant that these types
>> existed twice in the VM, once inside the single bundle distro and once
>> outside. This caused issues with ConfigAdmin and some event types
>> since communication with the outside world wasn't possible with these
>> types any more.
>> I fixed this for the single-bundle distro (it doesn't apply to the
>> multi-bundle distro).
>> * ExportReferenceImpl, which is really a wrapper,  was used in a Map
>> but missing hashCode and equals(). I added these.
>> * There were some issues around close() calls not completely properly
>> behaving, I fixed those
>> * RemoteServiceAdminCore was putting objects of the wrong type in the
>> collection returned by exportService()
>>
>> Some more changes may be needed in order to fully pass the TCK, but
>> I've committed the above in r1290914.
>>
> Cool, guess you are thinking about 1.3.1 already :-)
> Cheers, Sergey
>
>> Cheers,
>>
>> David
>
>

CXF-DOSGi and the OSGi Remote Service Admin TCK

[David Bosschaert]

Hi all,

I was recently running the CXF-DOSGi 1.3 release through the OSGi TCK
to make sure it's still compliant with the spec.
It turned out that the changes made between 1.2 and 1.3 cause a number
of TCK failures, so I've been looking at fixing them.
Here's a quick summary.
* the single-bundle distro (which is used with the TCK) now includes
the org.osgi.enterprise-4.2.0.jar. This is fine, but it didn't
export/import the types defined in there which meant that these types
existed twice in the VM, once inside the single bundle distro and once
outside. This caused issues with ConfigAdmin and some event types
since communication with the outside world wasn't possible with these
types any more.
I fixed this for the single-bundle distro (it doesn't apply to the
multi-bundle distro).
* ExportReferenceImpl, which is really a wrapper,  was used in a Map
but missing hashCode and equals(). I added these.
* There were some issues around close() calls not completely properly
behaving, I fixed those
* RemoteServiceAdminCore was putting objects of the wrong type in the
collection returned by exportService()

Some more changes may be needed in order to fully pass the TCK, but
I've committed the above in r1290914.

Cheers,

David

Re: [VOTE] Apache DOSGi 1.3 Release

[David Bosschaert]

Excellent work, Sergey. Big +1 from me!

David

On 2 February 2012 13:33, Sergey Beryozkin  wrote:
> Apache CXF DOSGI subproject is a Reference Implementation of the OSGI Remote
> Services Specification which offers an alternative approach toward
> dynamically deploying and updating remote service endpoints and consumers
> using the OSGI programming model.
>
> We have been working on the 1.3 release during the last 2 months and have
> resolved about 15 issues:
>
> http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.3/distribution/sources/src/main/release/release_notes.txt
>
> Apache CXF 2.5.2 JAX-WS and JAX-RS runtimes are used internally to create
> the web service endpoints and consumers.
>
> The staging area:
> https://repository.apache.org/content/repositories/orgapachecxf-178/
>
> This vote will be open for at least 72 hours.
>
> Here is my +1.
>
> Sergey
>
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com

Re: Preparing for DOSGi RI 1.3 release

[David Bosschaert]

+1 on including the enterprise jar. It should also replace the
compendium jar if that's currently mentioned in the project...

Cheers,

David

On 24 January 2012 18:37, jbert  wrote:
> I second the need for the enterprise API jar.
>
> I would also like to note that the POMs in trunk still need to be changed to
> point to the org.osgi.enterprise JAR, right now they're still pointing to
> the remoteadmin project. This means that the current sources cannot be built
> unless you check out a revision of November and build the remoteadmin
> project to get a 1.3 SNAPSHOT.
>
> If it's not clear what I mean, I could create a simple patch tomorrow.
>
>
> Best regards,
>
> Bert
>
>
> --
> View this message in context: 
> http://cxf.547215.n5.nabble.com/Preparing-for-DOSGi-RI-1-3-release-tp5094303p5324430.html
> Sent from the cxf-dev mailing list archive at Nabble.com.

Re: [VOTE] Apache CXF 2.3.9/2.4.6/2.5.2 - take 2

[David Bosschaert]

+1

David

On 20 January 2012 17:56, Daniel Kulp  wrote:
>
> We've resolved over 45 issues since 2.5.1.  Most importantly, several of them
> were regressions since 2.5.0 and thus we need to get a new release out.  We've
> also ported back over 25 of the fixes to 2.4.6 and 8 of those to 2.3.9.
>
> This is the second attempt at this release which fixes the issues of getting
> the 2.5.2 OSGi bundles properly deploying.
>
>
> List of issues:
> 2.3.9:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12319251
> 2.4.6:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12319250
> 2.5.2:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12319249
>
>
> The Maven staging areas are at:
> 2.3.9:
> https://repository.apache.org/content/repositories/orgapachecxf-099/
> 2.4.6:
> https://repository.apache.org/content/repositories/orgapachecxf-101/
> 2.5.2:
> https://repository.apache.org/content/repositories/orgapachecxf-112/
>
>
> The distributions are in the org/apache/cxf/apache-cxf/ directory of the Maven
> staging areas.
>
>
> This releases are tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.9
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.6
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.2
>
>
> This vote will be open for at least 72 hours.
>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com

Re: [VOTE] Apache CXF 2.3.9/2.4.6/2.5.2

[David Bosschaert]

+1

David.

On 20 January 2012 00:08, Daniel Kulp  wrote:
>
>
> We've resolved over 45 issues since 2.5.1.  Most importantly, several of them
> were regressions since 2.5.0 and thus we need to get a new release out.  We've
> also ported back over 25 of the fixes to 2.4.6 and 8 of those to 2.3.9.
>
> List of issues:
> 2.3.9:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12319251
> 2.4.6:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12319250
> 2.5.2:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12319249
>
>
> The Maven staging areas are at:
> 2.3.9:
> https://repository.apache.org/content/repositories/orgapachecxf-099/
> 2.4.6:
> https://repository.apache.org/content/repositories/orgapachecxf-101/
> 2.5.2:
> https://repository.apache.org/content/repositories/orgapachecxf-104/
>
>
> The distributions are in the org/apache/cxf/apache-cxf/ directory of the Maven
> staging areas.
>
>
> This releases are tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.9
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.6
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.2
>
>
> This vote will be open for at least 72 hours.
>
>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com

Re: DOSGi and Knopflerfish

[David Bosschaert]

Hi Jesus,

I'm not aware it was ever tried, however the same demo that Sergey
mentiones does work on the Equinox, Felix and JBoss OSGi Frameworks (I
have tried it on all these) so if it doesn't work with Knopflerfish it
might be an issue relating to that framework...

Best regards,

David

On 18 January 2012 16:37, Jesus  wrote:
> I develop a bundle like thats, but the result is the same: I can't access to
> my bundle :(
>
> Do you know if D-OSGi run in Knopflerfish??
>
> Thanks in advance.
>
> --
> View this message in context: 
> http://cxf.547215.n5.nabble.com/DOSGi-and-Knopflerfish-tp5154329p5155307.html
> Sent from the cxf-dev mailing list archive at Nabble.com.

Re: OSGi bundles and split packages....

[David Bosschaert]

>> WRT to changing packages, if you are really worried about backward
>> compatibility but would like to refactor the split packages out you
>> *could* consider renaming the package and creating a compatibility
>> bundle or fragment that contains the 'old' split packages and
>> delegates to the new ones. The users can slowly migrate. Non-migrated
>> users would need the compat bundle. Migrated ones will not need it...
>> It's not always practical, but it's an option to consider...
>
> Doesn't really work for CXF, at least of the areas I looked at.   For the most
> part, the stuff that needs to move are interfaces that the impls' would need
> to implement.   Thus, without some complex weaving to add the interfaces onto
> the impls at runtime, it would be a bit more difficult.

You could probably achieve some results with java.lang.reflect.Proxy,
but either way this would not be much fun.
I might be a possibility if you're only talking about a small number
of problematic cases...

Cheers,

David

Re: OSGi bundles and split packages....

[David Bosschaert]

Big +1 from me on this (obviously). The fragment approach seems like a
sensible idea to me as a migration strategy.

WRT to changing packages, if you are really worried about backward
compatibility but would like to refactor the split packages out you
*could* consider renaming the package and creating a compatibility
bundle or fragment that contains the 'old' split packages and
delegates to the new ones. The users can slowly migrate. Non-migrated
users would need the compat bundle. Migrated ones will not need it...
It's not always practical, but it's an option to consider...

Cheers,

David

On 5 December 2011 17:40, Daniel Kulp  wrote:
>
> I kind of did a little audit this morning to try and figure out how hard it
> will be to split the big bundle into little bundles to allow for smaller OSGi
> footprints and such by just loading the desired functionality into OSGi
> instead of the entire big bundle (and all it's deps).
>
> At this point, we have 25 packages that are split across multiple jars.   16
> of the 25 are split between common-utilities, api, and rt-core.   At this
> point, I'd likely just say make those 3 fragments of each other.   In the
> future, then figure out how to split that "big" bundle up a bit better.   Some
> of the 16 are "easy" (like cxf/phase) but not really worth spending time on if
> all of them cannot be resolved.
>
> Of the remaining 9, 5 are easy to resolve, 2 are "medium", and 2 are hard and
> would have a big impact.
>
>
> Here is my analysis:
>
> "Big 3" packages:
> org/apache/cxf/binding  cxf-api cxf-rt-core
> org/apache/cxf/buslifecycle  cxf-api cxf-rt-core
> org/apache/cxf/clustering  cxf-api cxf-rt-core
> org/apache/cxf/configuration  cxf-api cxf-common-utilities cxf-rt-core
> org/apache/cxf/configuration/spring  cxf-common-utilities cxf-rt-core
> org/apache/cxf/endpoint  cxf-api cxf-rt-core
> org/apache/cxf/feature  cxf-api  cxf-rt-core
> org/apache/cxf/headers  cxf-api cxf-rt-core
> org/apache/cxf/interceptor  cxf-api cxf-rt-core
> org/apache/cxf/io  cxf-api cxf-rt-core
> org/apache/cxf/phase  cxf-api cxf-rt-core
> org/apache/cxf/service  cxf-api cxf-rt-core
> org/apache/cxf/service/invoker  cxf-api cxf-rt-core
> org/apache/cxf/transport  cxf-api cxf-rt-core
> org/apache/cxf/workqueue  cxf-api cxf-rt-core
> org/apache/cxf/wsdl  cxf-api cxf-rt-core
>
>
> Not easy:
> org/apache/cxf/jaxb  cxf-common-utilities cxf-rt-databinding-jaxb
>    Classes from both are used all over the place.   Big user impact.
>    We COULD consider JAXB databinding a "core" thing and fragment it
>    in since JAXB is pretty much required for any usage of CXF.
>
> org/apache/cxf/service/factory  cxf-rt-core cxf-rt-frontend-simple
>    Couple classes in rt-core used by JAX-RS and thus not really pushable into
>    frontend-simple without pulling more deps for JAX-RS.   Changing package
>    name in either place would affect users. (changing package for
>    classes in rt-core would affect a LOT less users though)
>
>
>
> Medium:
> org/apache/cxf/ws/policy  cxf-api cxf-rt-ws-policy
>   Move impls and interceptors to private package.  May impact users if
>      referencing the impls/interceptors directly.
>   Push abstract and basic stuff up to cxf-api
>   Couple other issues to resolve (like WSPolicyFeature requires Spring)
>
> org/apache/cxf/ws/addressing  cxf-api cxf-rt-ws-addr
>   Moving all the classes from api to ws-addr can be done.  Users would need
>   to depend on cxf-rt-ws-addr in addition to cxf-api if using the classes.
>   The main one is the AddressingProperties interface.  Some internal CXF
> classes will need to be updated and fixed, but nothing major.   The only
> "hard" one would be AbstractMultiplexDestination's call into the
> AddressingProperties, but that's all of 2 lines of code and could likely be
> handled better by have ws-add save the "TO" EPR on the message/exchange
> directly.
>
> Easy:
> org/apache/cxf/frontend  cxf-rt-core cxf-rt-frontend-simple
>    Move from rt-core to sub-module (not used elsewhere anyway):
> org/apache/cxf/management  cxf-common-utilities cxf-rt-management
>    Change package for generated type.  No impact to users.
> org/apache/cxf/transport/http  cxf-rt-core cxf-rt-transports-http
>    Impl in "core" moved to private package, utility class moved to common
>    Possible impact to users as the utility class would move.
> org/apache/cxf/tools/common  cxf-api cxf-tools-common
>    Move to tools-common and update refs or replace with constants
> org/apache/cxf/tools/validator  cxf-api cxf-tools-validator
>    Move to tools-validator and adjust dependencies and set optional imports
>
>
> Anyway, what are people's thoughts on the above?   Is it worth pursing more
> closely for 2.6?   Other than the JAXB one above that still needs a good
> solution, the impact isn't very large and could easily be documented in the
> migration guides.
>
>
> Dan
>

Re: [VOTE] Release Apache CXF 2.3.4

[David Bosschaert]

+1

David

On 13 April 2011 08:42, Daniel Kulp  wrote:
>
>
> We've resolved over 59 issues since 2.3.3 and thus is time for a release.
>
> List of issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12316074
>
> The Maven staging areas are at:
> https://repository.apache.org/content/repositories/orgapachecxf-084
>
> The distributions are in:
> https://repository.apache.org/content/repositories/orgapachecxf-084/org/apache/cxf/apache-cxf/2.3.4/
>
> This release is tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.4
>
>
> This vote will be open for at least 72 hours.
>
> Here is my +1.
>
>
> --
> Daniel Kulp
> dk...@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>

Re: [VOTE] Release Apache CXF 2.4.0

[David Bosschaert]

+1

David

On 13 April 2011 08:51, Daniel Kulp  wrote:
>
> It's been about 6 months since the release of 2.3 and we've done a fantastic
> job implenting new features  and cleaning up various parts of the code and
> integrating new versions of libraries like WSS4J, Neethi, XmlSchema, etc...
> that provide a good base for new features and enhancements going forward.   I
> think it's time to get 2.4.0 out there.
>
>
> List of issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12315386
>
> Migration guide:
> http://cxf.apache.org/docs/24-migration-guide.html
>
> The Maven staging areas are at:
> https://repository.apache.org/content/repositories/orgapachecxf-085/
>
> The distributions are in:
> https://repository.apache.org/content/repositories/orgapachecxf-085/org/apache/cxf/apache-cxf/2.4.0/
>
> This release is tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.0
>
> Vote will be open for at least 72 hours.
>
> Here is my +1.
>
>
> --
> Daniel Kulp
> dk...@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>

Re: CXF OSGI application and HTTP transport

[David Bosschaert]

Hi Sergey,

Not sure I understand your email 100% (maybe I should spend more time
reading it ;) but just to make sure, the component you're proposing to
remove is not related to DOSGi, correct? DOSGi als uses a HTTP
transport, but that's is not the one you're suggesting to remove...

Cheers,

David

On 9 March 2011 11:26, Sergey Beryozkin  wrote:
> Hi
>
> I'd like to discuss a bit the possibility of making the CXF HTTP-OSGI
> transport redundant. Not sure if it's a good idea but I'd like to give it a
> chance :-) by discussing it on this list.
>
> The reason I'm concerned about CXF HTTP-OSGI transport is that it
> effectively takes the role of the CXF OSGI application.  At the moment it's
> a Spring DM application and may get updated to become a Blueprint one. CXF
> is bigger than its HTTP transport but we're limited only to its HTTP
> transport registering itself as the Servlet.
>
> The other thing which concerns me is its static nature to do with
> hard-coding the context name and the names of the properties it may support.
> Having a single context within a given container instance is a limitation,
> not a big one, but it is nonetheless. And hardcoding the names of the
> properties is not good at all because OSGI gives us a ManagedService
> interface.
>
> Finally we are just totally out of control here and just depend on the
> external injection.
>
> I hope we can find a way to break this dependency. It was really needed at a
> time but IMHO it limits the way CXF as a whole can play in OSGI.
> If we look at DOSGi, one of the reasons it is interesting to developers is
> that it effectively makes CXF JAX-WS and JAX-RS runtimes taking more active
> roles in the process. DOSGi provides callbacks for these components to wrap
> the registered/looked-up interfaces. Yet alternative way is to have
> individual Activators check a given bundle for the presence of say JAX-RS
> Application or may be JAX-WS @WebService interface and react.
>
> I'm wondering if the idea of introducing a top-level Activator (at the
> distribution level) delegating to module-specific Activators works or not.
> At the moment it seems like it can. HTTP, JAX-WS, JAX-RS/etc Activators can
> do whatever they need to and also expose the properties which can be
> dynamically updated...
> My only concern is how to synchronize the whole process and the idea of say
> HTTP Transport registering itself as some OSGI service (discussed in the
> other thread) can be a perfect solution. If it all can work then we will end
> up having a real CXF OSGI application, very flexible and advanced, it will
> be a different level really...
>
> Of course that could be a bad idea - there could be constraints there which
> basically make it not-workable...
>
> Cheers, Sergey
>

Re: Entry point for rsa

[David Bosschaert]

Sounds like this could quite well be done using the LDAP filters that
are supported natively by the OSGi Service Registry.
If you want to be in complete control of what you give to the caller
you may want to have a look at OSGi ServiceFactories.

Cheers,

David

On 14 February 2011 12:27, Pierre-Henry Perret  wrote:
>
>
> David Bosschaert wrote:
>>
>> Hi Pierre,
>>
>> Could you be a little more explicit in what you'd like to do?
>> The CXF-DOSGi Discovery mechanism uses the OSGi Configuration Admin
>> Service for its configuration, for example.
>>
>
> Ok. My applicaton has some remote services registered. I want to choose one
> of them on certain criteria, and then give it back to the caller, sort of  a
> dispatcher.
>
> Thanks
>
> -
> --
> Pierre
> --
> View this message in context: 
> http://cxf.547215.n5.nabble.com/Entry-point-for-rsa-tp3382668p3384372.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>

Re: Entry point for rsa

[David Bosschaert]

Hi Pierre,

Could you be a little more explicit in what you'd like to do?
The CXF-DOSGi Discovery mechanism uses the OSGi Configuration Admin
Service for its configuration, for example.

Best regards,

David

On 12 February 2011 12:18, Pierre-Henry Perret  wrote:
>
> Hello,
>
> Could you suggest an entry point for using the configadmin osgi service with
> cxf ?
>
> Thanks
>
>
>
> -
> --
> Pierre
> --
> View this message in context: 
> http://cxf.547215.n5.nabble.com/Entry-point-for-rsa-tp3382668p3382668.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>

Re: [VOTE] Apache CXF 2.3.2

[David Bosschaert]

+1

David

On 18 January 2011 04:26, Daniel Kulp  wrote:
>
> We've had a busy 8 weeks or so despite the holidays.   We've managed to fix 
> over 75 JIRA issues since 2.3.1 which is quite remarkable .  This also fixes 
> a bunch of OSGi related issues that are needed for
> Camel and ServiceMix.
>
> Note:  this vote also includes a release of the cxf-xjc-utils to fix a bunch 
> of issues that were resolved there.
>
>
> List of issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315921&styleName=Text&projectId=12310511&Create=Create
>
> The Maven staging areas are at:
> https://repository.apache.org/content/repositories/orgapachecxf-041/
> https://repository.apache.org/content/repositories/orgapachecxf-042/
>
> The distributions are in:
> https://repository.apache.org/content/repositories/orgapachecxf-042/org/apache/cxf/apache-cxf/2.3.2/
>
> This release is tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.2
> http://svn.apache.org/repos/asf/cxf/xjc-utils/tags/xjc-utils-2.3.2/
>
> The vote will be open for 72 hours.
>
> Here is my +1.
>
>
>
> --
> Daniel Kulp
> dk...@apache.org
> http://dankulp.com/blog
>

Re: [VOTE] Colm O hEigeartaigh for CXF committer

[David Bosschaert]

+1

David

On 2 December 2010 12:01, Daniel Kulp  wrote:
>
> In the last 2 years, Colm has logged 11 issues with CXF.  Every single one of
> them came with a patch file to fix the issue:
>
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&reporterSelect=specificuser&reporter=coheigea
>
> 11 patches is quite a lot.   If they were not spread out over 2 years, I think
> he would have been noticed much sooner and been granted committership.
> However, it does show a long term commitment to the project and I feel
> becoming a committer is long overdue.
>
> He knows the WS-Sec and XML-Sec things inside and out and is a leading
> driver of the WSS4J and Santuario (xml-sec) libraries that we rely on.
>
> He's currently working in our sandbox and on the WSS4J trunk to update WSS4J
> to Java5 level and clean up the WSS4J API's and such.
>
> Basically, he's been an invaluable contributor to the WS-Security stuff and
> having him as a committer would be a big addition, IMO.
>
>
> Here is my  +1.
>
> --
> Daniel Kulp
> dk...@apache.org
> http://dankulp.com/blog
>
>

Re: [VOTE] Release CXF 2.3.1

[David Bosschaert]

+1

David

On 2 December 2010 09:54, Daniel Kulp  wrote:
>
>
> Once again, there have been a bunch of bug fixes and enhancements that
> have been done compared to the 2.3.0 release.   Over 55 JIRA issues
> are resolved for 2.3.1.
>
> Note:  this vote also includes a release of the cxf-buildutils to fix some 
> compatibility issues with the build and the latest Eclipse plugins.
>
>
> List of issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315385&styleName=Html&projectId=12310511&Create=Create
>
> The Maven staging area is at:
> https://repository.apache.org/content/repositories/orgapachecxf-036/
>
> The distributions are in:
> https://repository.apache.org/content/repositories/orgapachecxf-036/org/apache/cxf/apache-cxf/2.3.1/
>
> This release is tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.1
> http://svn.apache.org/repos/asf/cxf/build-utils/tags/cxf-build-utils-2.3.1/
>
> The vote will be open for 72 hours.
>
> Here is my +1.
>
>
> --
> Daniel Kulp
> dk...@apache.org
> http://dankulp.com/blog
>

Re: [VOTE] Release CXF 2.2.12

[David Bosschaert]

+1

David

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

Re: Łukasz Moreń for CXF Committer

[David Bosschaert]

+1

David

On 16 November 2010 23:35, Sergey Beryozkin  wrote:
> Hi
>
> I'd like to initiate a vote for Łukasz Moreń to become a CXF committer.
>
> You may recall that Łukasz came forward and proposed to have OAuth 1.0
> implemented in CXF as part of GSOC 2010.
>
> During GSOC 2010 Łukasz tried his best to complete this complex project in
> time and he was very good at keeping the CXF dev community in the loop
> regarding the actual progress. Having had some limited exposure to OAuth
> related projects, I can tell that working with OAuth can be daunting and the
> amount of information to filter through can be overwhelming and thus I was
> really happy seeing Łukasz persevering and doing a very good effort as part
> of his project.
>
> One thing I'd like to highlight is that even though OAuth does not seem to
> be the most popular technology among CXF users today, it is really just a
> matter of time before OAuth starts hitting the mainstream. Today OAuth is
> associated with social networking, web-based user accounts, etc, but it does
> seem it is sooner rather than later when us, CXF users, will want to build a
> local OAuth-aware application  inside the enterprise and integrate with
> their STS stores, etc given the amount of attention big players are giving
> to OAuth today.
>
> Łukasz is an OAuth expert and he is working with OAuth and I do believe
> having him on board will benefit CXF going forward. We do want CXF featuring
> in the OAuth game one way or the other.
>
> Finally, it is worth mentioning Łukasz has continued working on his project
> after GSOC 2010 ended which shows his commitment.
>
> Thus I'd like to start a vote
>
> Here is my +1
>
> Sergey
>

Re: Tomasz Opanovicz for CXF committer

[David Bosschaert]

+1

David

On 30 October 2010 17:20, Sergey Beryozkin  wrote:
> Hi
>
> I'd like to initiate a vote for Tomasz Opanovicz to become a CXF committer.
>
> As you may recall, Tomasz became known in the CXF community after starting
> to work on the Log Browser project
> as part of the GSOC 2010. During the project Tomasz showed some real
> enthusiasm and his commitment to completing it in time
> was second to none.
>
> The other thing I'd like to mention about his contribution is that it is
> really the first of its kind. We have learnt to appreciate that some good UI
> tooling
> adds a touch of quality to whatever that is shipped to the end user and what
> Tomasz does is really a big step forward for CXF IMHO, in that users will be
> able to view logs using the nice log browser. Hopefully, Tomasz won't stop
> once this project has been complete and move on to adding more UI features
> to CXF.
>
> Finally, Tomasz has continued developing after the GSOC ended few months ago
> thus showing he would really like to finish what he started working upon.
>
> Thus the time has come for him to become the CXF committer.
>
> Here's my +1
>
> Sergey
>

Re: Advanced Configuration in DOSGI

[David Bosschaert]

Hi Sergey,

Just seeing your other thread regarding making it easy to migrate
existing CXF users who already have cxf.xml configuration after
replying to this one.
Yes - I see your point. It would make sense to easily migrate from
plain CXF to DOSGi.
An alternative could be to abandon the intent-map.xml altogether and
allow intents to be configured in the cxf.xml file.

Cheers,

David

On 14 October 2010 13:06, David Bosschaert  wrote:
> Hi Sergey,
>
> I see nothing wrong with
>  "org.apache.cxf.ws.external.config" : "classpath:/config/http.xml"
>
> but am wondering, why could you not to do this
>  "service.exported.intents.extra" : "http_proxy"
> and then put the "http_proxy" configuration in the
> OSGi-INF/cxf/intents/intent-map.xml file. I don't really see a
> fundamental difference between the two. Whether or not the client-side
> sees the 'http_proxy" intent on then remote service reference is
> pretty harmless IMHO, but you could think of a mechanism to filter out
> certain intents from the remote publication if this is absolutely
> needed.
>
> Note that I'm using service.exported.intents.extra instead of
> service.exported.intents. Although the values of these properties get
> merged at runtime they serve different purposes.
> service.exported.intents is for intents that are crucial to the
> *behaviour* of the service. For instance the fact that a transaction
> context is available. service.exported.intents.extra is for additional
> configuration that might be needed for some users, and proxy
> configuration is a perfect example of that. The idea is that
> developers who use these properties would make the
> service.exported.intents.extra property configurable externally, e.g.
> through Configuration Admin or some other mechanism (see [1] for more
> information).
>
> Just my thoughts,
>
> David
>
> [1] Table 13.1 in the OSGi 4.2 Enterprise Release
> (http://www.osgi.org/Download/Release4V42)
>
> On 14 October 2010 12:36, Sergey Beryozkin  wrote:
>> Hi
>>
>> DOSGI (RI) offers two options for users to configure the providers and
>> consumers
>>
>> 1. Intents - short policy-like statements
>> 2. Properties
>>
>> In some cases these options may not be sufficient.
>> For example, consider a requirement to configure a DOSGI consumer with TLS
>> properties or HTTP proxy properties.
>>
>> Templated intents might be used in principle - however it seems a difficult
>> thing to achieve.
>> Ex, on the server side, the DOSGI would need to figure out which individual
>> properties needs to be blocked from the publication (ex, the location of the
>> key store, etc). Application bundles would need to import concrete
>> implementations of such templated intents and depend on DOSGI RI. Also I'm
>> not sure if intents can be used for a pure client-side configuration (ex,
>> http proxies). Finally, perhaps intents are not really usable for some
>> low-level configuration or customization.
>>
>> Properties may always be used - but this is problematic for two reasons. In
>> complex cases we may have a lot of complex properties. Of more concern to me
>> is that we currently have not agreed on using a shared set of properties for
>> SOAP and REST services thus we'd have many duplicated properties for say
>> configuring HTTPS or HTTP proxies for either SOAP clients or proxy-based
>> JAXRS clients.
>>
>> So one way here is to figure out how to let users configure easily consumers
>> to work with HTTP proxies. Here is the concrete example taken from the
>> recent email on the users list :
>>
>> > ProxyServerType="SOCKS" />
>>  
>>   asdf
>>   qwer
>>  > proxyAuthorization>
>>
>> lets try to figure out how we can configure in DOSGI.
>>
>> One option is to let users just reuse such configurations.
>>
>> So here's one concrete proposal.
>>
>> Introduce "org.apache.cxf.ws/rs.external.config" (or similar).
>> Ex,
>>
>> "org.apache.cxf.ws.external.config" : "classpath:/config/http.xml"
>>
>>
>> Thus users will be able to reuse some existing configuration which they may
>> also be relying upon in non-DOSGI environments but they will use the DOSGI
>> properties mechanism (at the cost of introducing one extra property per
>> ws/rs) to bootstrap those existing CXF config beans.
>>
>> Comments, any other ideas ?
>>
>> thanks, Sergey
>>
>

Re: Advanced Configuration in DOSGI

[David Bosschaert]

Hi Sergey,

I see nothing wrong with
  "org.apache.cxf.ws.external.config" : "classpath:/config/http.xml"

but am wondering, why could you not to do this
  "service.exported.intents.extra" : "http_proxy"
and then put the "http_proxy" configuration in the
OSGi-INF/cxf/intents/intent-map.xml file. I don't really see a
fundamental difference between the two. Whether or not the client-side
sees the 'http_proxy" intent on then remote service reference is
pretty harmless IMHO, but you could think of a mechanism to filter out
certain intents from the remote publication if this is absolutely
needed.

Note that I'm using service.exported.intents.extra instead of
service.exported.intents. Although the values of these properties get
merged at runtime they serve different purposes.
service.exported.intents is for intents that are crucial to the
*behaviour* of the service. For instance the fact that a transaction
context is available. service.exported.intents.extra is for additional
configuration that might be needed for some users, and proxy
configuration is a perfect example of that. The idea is that
developers who use these properties would make the
service.exported.intents.extra property configurable externally, e.g.
through Configuration Admin or some other mechanism (see [1] for more
information).

Just my thoughts,

David

[1] Table 13.1 in the OSGi 4.2 Enterprise Release
(http://www.osgi.org/Download/Release4V42)

On 14 October 2010 12:36, Sergey Beryozkin  wrote:
> Hi
>
> DOSGI (RI) offers two options for users to configure the providers and
> consumers
>
> 1. Intents - short policy-like statements
> 2. Properties
>
> In some cases these options may not be sufficient.
> For example, consider a requirement to configure a DOSGI consumer with TLS
> properties or HTTP proxy properties.
>
> Templated intents might be used in principle - however it seems a difficult
> thing to achieve.
> Ex, on the server side, the DOSGI would need to figure out which individual
> properties needs to be blocked from the publication (ex, the location of the
> key store, etc). Application bundles would need to import concrete
> implementations of such templated intents and depend on DOSGI RI. Also I'm
> not sure if intents can be used for a pure client-side configuration (ex,
> http proxies). Finally, perhaps intents are not really usable for some
> low-level configuration or customization.
>
> Properties may always be used - but this is problematic for two reasons. In
> complex cases we may have a lot of complex properties. Of more concern to me
> is that we currently have not agreed on using a shared set of properties for
> SOAP and REST services thus we'd have many duplicated properties for say
> configuring HTTPS or HTTP proxies for either SOAP clients or proxy-based
> JAXRS clients.
>
> So one way here is to figure out how to let users configure easily consumers
> to work with HTTP proxies. Here is the concrete example taken from the
> recent email on the users list :
>
>  ProxyServerType="SOCKS" />
>  
>   asdf
>   qwer
>   proxyAuthorization>
>
> lets try to figure out how we can configure in DOSGI.
>
> One option is to let users just reuse such configurations.
>
> So here's one concrete proposal.
>
> Introduce "org.apache.cxf.ws/rs.external.config" (or similar).
> Ex,
>
> "org.apache.cxf.ws.external.config" : "classpath:/config/http.xml"
>
>
> Thus users will be able to reuse some existing configuration which they may
> also be relying upon in non-DOSGI environments but they will use the DOSGI
> properties mechanism (at the cost of introducing one extra property per
> ws/rs) to bootstrap those existing CXF config beans.
>
> Comments, any other ideas ?
>
> thanks, Sergey
>

Re: [VOTE] Release CXF 2.2.11

[David Bosschaert]

+1

David

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

Re: [VOTE] Release CXF 2.3.0

[David Bosschaert]

+1

David

On 7 October 2010 23:51, Daniel Kulp  wrote:
>
> OK.. it staged faster than I expected.   :-)
>
> Probably LONG overdue, but I think it's time to finally release CXF 2.3.0!
>
>
> The Maven staging area is at:
> https://repository.apache.org/content/repositories/orgapachecxf-005/
>
> The distributions are in:
> https://repository.apache.org/content/repositories/orgapachecxf-005/org/apache/cxf/apache-
> cxf/2.3.0/
>
> This release is tagged at:
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.0
>
> This vote also  emcompasses the xcjutils and buildutils tagged at:
> http://svn.apache.org/repos/asf/cxf/xjc-utils/tags/xjc-utils-2.3.0/
> http://svn.apache.org/repos/asf/cxf/build-utils/tags/cxf-build-utils-2.3.0/
>
> The vote will be open for 72 hours.
>
> (I'm not voting yet, need to test it a bit first)
>
> --
> Daniel Kulp
> dk...@apache.org
> http://dankulp.com/blog
>

Re: [RESULT][VOTE] Release CXF dOSGi 1.2

[David Bosschaert]

Excellent!
I'll update this links on the cxf-dosgi wiki
(http://cxf.apache.org/distributed-osgi.html).

Best regards,

David

On 25 July 2010 17:04, Eoghan Glynn  wrote:
> 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
>

Re: [VOTE] Release CXF dOSGi 1.2 - Take 2

[David Bosschaert]

+1

David

On 21 July 2010 07:45, Eoghan Glynn  wrote:
> 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

[David Bosschaert]

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:
>> >
>> >   -   *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

[David Bosschaert]

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
>
> 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: Board report time.....

[David Bosschaert]

Looks good to me!

David

On 16 July 2010 15:20, Daniel Kulp  wrote:
>
> I almost forgot the board report is due.   Shame on me.   This is what I plan
> to submit on Sunday.   Let me know ASAP if there are any additions/changes:
>
>
> Releases:
> 2.0.13* was released
> 2.1.10* was released
> 2.2.8 and 2.2.9* were released
>
> Note:  2.0.13, 2.1.10, and 2.2.9 were primarily released as a patch for a
> severe security issue reported to secur...@.     There were no plans to
> release any further 2.0.x and 2.1.x versions, but the community thought that
> the security issue warranted another release.
>
>
> New committers:
> We had "temporary" accounts created for two of our three Google Summer of Code
> students and granted them access to our sandbox.   This has been a success
> and the students have been doing quite a bit of work there.
>
> Issues requiring board attention:
> In our last report, we complained about the JCP TCK access process.   I'm
> happy to report that the new process seems to be going much better.   CXF is
> getting patches and TCK's much quicker.    I think other projects are also
> much happier with the responses.   Consider that issue resolved.
>
> Community update:
> With access to the JAX-WS 2.2 TCK, we were able to really start tackling the
> 2.2 features.   We're happy to report that the code on trunk now passes the
> TCK.    We still have quite a bit of cleanup work before 2.3 is ready to be
> released, but a major feature is now done.
>
> All three Google Summer of Code projects are going VERY well and are on track
> to be completed successfully.   We're all excited about the new features these
> projects will bring to CXF.
>
> On the Distributed OSGi front, 1.2 should be released shortly.   The last
> couple of issues targeted for the release were resolved this week so final
> preps are being made to roll the release.
>
>
>
>
> --
> Daniel Kulp
> dk...@apache.org
> http://dankulp.com/blog
>

Re: DOSGI: Update to CXF 2.2.9

[David Bosschaert]

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 what version you will get. In OSGi this dependency means: take
>> any version available!
>
> Depending on ANY version range it dangerous.  The same problem could pop up
> with the old version range "[2.1,3.0)".   For example, lets say the system was
> properly configured to export the system packages as 2.1 (assuming Java 6
> update 4 or later).     However, the user wants to use JAX-WS 2.2.   (also
> assume the 2.3 version of CXF that will support both 2.1 and 2.2).    With the
> current ordering, CXF would start, get version 2.1, then spec/api bundle would
> start, then the client  bundle would start and get 2.2, but then not be able
> to use CXF due to the JAX-WS API version mismatch things.  JAXB apis would be
> the same way.  Really, anything in the JDK could be an issue.
>
> JAXB is really a "could be an issue now" type thing.   2.2.9 supports the new
> placements of @XmlElement on the method parameters to control the required and
> nillable and such.   This was added in JAXB 2.2 and required for JAX-WS 2.1,
> but easily ported back to CXF 2.2.9, but only active if using JAXB 2.2.  Thus,
> there is a case where someone would WANT to use JAXB 2.2 with CXF today.   In
> the above scenario, CXF could pick up 2.1 from the system, but the user bundle
> could want 2.2.   Mismatch failure.
>
>>
>> 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 think this is the best option.   I would think all the "spec"/"api" jars
> should be pretty much the first things started up.
>
>
>> 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...
>
> Not sure on that.
>
> Dan
>
>
>>
>> Cheers,
>>
>> David
>
> --
> Daniel Kulp
> dk...@apache.org
> http://dankulp.com/blog
>

Re: DOSGI: Update to CXF 2.2.9

[David Bosschaert]

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

[David Bosschaert]

Hi Sergey,

I think you need to dive a little deeper to see what the actual problem is.
Let me know if you need help with this.

Cheers,

David

On 28 June 2010 12:31, Sergey Beryozkin  wrote:
> Hi David
>
> So
> (version>=2.1.0)
>
> does not intersect with
>
> (version>=0.0.0)(!(version>=3.0.0)
>
> ?
>
> cheers, Sergey
>
> On Mon, Jun 28, 2010 at 10:34 AM, David Bosschaert <
> david.bosscha...@gmail.com> 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.

Re: DOSGI: Update to CXF 2.2.9

[David Bosschaert]

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.ws BLAMED 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.cxf.jaxrs.provid
er)(version>=2.2.0)), [17.0] package; (&(package=javax.xml.ws)(version>=0.0.0)(!
(version>=3.0.0)))]

On 26 June 2010 17:19, Sergey Beryozkin  wrote:
> Hi
>
> I've attached a patch to [1] which I've tried locally, things looks ok after
> updating to 2.2.9, i.e, I run two demos manually, greeter & greeter_rest,
>
> but the build itself is hanging in systests2/multi bundle tests.
>
> Can someone please try the patch as well and confirm it's building ok or
> hanging ? DOSGI 1.1 uses 2.5 and moving to 2.2.9 need to be done IMHO
>
> cheers, Sergey
>
> [1] https://issues.apache.org/jira/browse/DOSGI-74
>

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

[David Bosschaert]

On 11 June 2010 16:53, David Bosschaert  wrote:
> * Make sure all the demos work (and update the docs) - this is
> something I would be happy to help out with.

I went through all the demos this morning and made a few small updates
so that they all work again. I also updated the demo documentation
alongside and updated the installation instructions in the docs to use
Felix 3.0.1 and Equinox 3.6.
I'm not completely finished with all the docs as the URLs need to be
updated to point to the 1.2 release once its out.

I also applied Juliens patch for DOSGI-62.
I didn't apply DOSGI-72 yet as it was missing unit tests. Hopefully
Julien can provide some coverage :)

Best regards,

David

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

[David Bosschaert]

Hi Julien,

I will have a look at your patches.

David

On 25 June 2010 13:58, Julien Vey  wrote:
>
>>> Tasks left would be:
>>> * When the above is done, cut the actual release candidate(s).
>>>
>>
>> I can help cutting the release when you're ready to go.
>>
>
> Is it possible to review and apply (if they are acceptable) DOSGI-62 and
> DOSGI-72 patches before the next release ?
>
> Cheers,
>
> Julien
>>
>> Cheers,
>> Eoghan
>>
>>
>> On 11 June 2010 16:53, David Bosschaert
>>  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
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

[DOSGi] TopologyManagerImportTest failure

[David Bosschaert]

Hi all,

This test is currently failing in Hudson. Could someone knowledgeable
(Marc?) please have a look?
org.apache.cxf.dosgi.topologymanager.TopologyManagerImportTest.testImportForNewlyAddedRSA

http://hudson.zones.apache.org/hudson/view/CXF/job/CXF-DOSGi/172/testReport/

Thanks!

David

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

[David Bosschaert]

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: CXF-DOSGi passing the OSGi Remote Services and Remote Service Admin CT

[David Bosschaert]

Yes, if the configuration type was called org.apache.cxf then the
configuration for it is allowed to be called org.apache.cxf.something.

I guess I'm wondering whether this is worth the effort though.
Originally the configuration type was called 'pojo'. When we moved to
org.apache.cxf.ws we made sure 'pojo' continued to work as
backward-compatibility measure in case people were using it. I think
if we move to org.apache.cxf instead of org.apache.cxf.ws we should
again keep backward compatibility, which in itself means a lot of
duplication...

Cheers,

David

On 4 June 2010 13:26, Julien Vey  wrote:
> Le 04/06/2010 14:20, Sergey Beryozkin a écrit :
>>
>> Well, actually it does break compliance as the spec says that the
>>
>>
>>>
>>> properties should be called:
>>> .something
>>>
>>> Given that the configuration type is called org.apache.cxf.ws the
>>> property should be called org.apache.cxf.ws.
>>>
>>> Yeah, I understand that. See, I was trying to explore if we could avoid
>>>
>>
>> adding the properties which are not specific to a given type, given that
>> we
>> are still in an org.apache.cfx space - it's hard to see any practical
>> negative side-effects...But I'm sorted...
>>
>> Generally speaking, I agree the compliance has to be a top priority. But
>> even RI can benefit from adding extensions.
>>
>> thanks, Sergey
>>
>
> Isn't it possible to call the configuration-type  org.apache.cxf
> and then add a property such as "org.apache.cxf.type = rs | ws"
>
> So it would be possible to have properties org.apache.cxf.port,
> org.apache.cxf.address which wouldn't break compliance
>
> Cheers,
>
> Julien
>>
>>
>>>
>>> Cheers,
>>>
>>> David
>>>
>>>
>>
>>
>
>

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

[David Bosschaert]

On 4 June 2010 12:55, Sergey Beryozkin  wrote:
>>>
>
>> >Having some properties in the CXF space "org.apache.cxf" seems to be
>> > totally compliant ? Then they can be 'inherited' by cxf.ws, cxf.rs.
>>
>> Not entirely sure what you mean here, but a 'reverse domain' name is
>> used here to avoid overlap between two technologies that are unaware
>> of each other. Just like in Java Package names. So using just 'cxf.ws'
>> is a shorter but not entirely compliant.
>>
>Well, I just was lazy typing 'org.apache'. Basically what I meant was that
> using a property such
> as 'org.apache.cxf.something' when configuring the service (soap/rest) using
> does not seem like breaking the compliance rules

Well, actually it does break compliance as the spec says that the
properties should be called:
.something

Given that the configuration type is called org.apache.cxf.ws the
property should be called org.apache.cxf.ws.

Cheers,

David

Postpone Discovery System tests for CXF-DOSGi

[David Bosschaert]

In preparation for a CXF-DOSGi release, I started looking into
re-enabling some discovery roundtrip tests that I never quite finished
some time ago.

The tests currently run within a single OSGi framework where they try
to force going through discovery by specifying service.imported=* on
the ServiceTracker in the client.
There is a problem with this testing approach, however. The remote
discovery code excludes looking in discovery for services coming from
the current framework - by specifying
!(endpoint.framework.uuid=the_current_framework_uuid). I think this is
actually the right behaviour for the discovery code.

So... this kind of functionality can only really properly be tested if
you have multiple frameworks. Unfortunately Pax-Exam currently doesn't
support that, but apparently that's planned for Pax-Exam 2.

Fortunately this functionality is actually already tested by the OSGi
TCK test suites for Remote Services and Remote Service Admin, so we
have coverage there...

Therefore I would like to propose to postpone re-enabling this system
test until we can use Pax-Exam to launch multiple frameworks for us.

Everyone ok with this?

Cheers,

David