Re: [VOTE] Release Apache CXF 2.0.11

[Eoghan Glynn]

+1

/Eoghan

Re: [VOTE] Release CXF 2.1.5

[Eoghan Glynn]

+1

/Eoghan

Re: [VOTE] Release CXF 2.2.1

[Eoghan Glynn]

+1

/Eoghan

Re: A rather crazy idea for a feature

[Eoghan Glynn]

Hi Benson,

Do you mean using an NIO MappedByteBuffer?

That would be an interesting thing to look at doing.

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

Cheers,
Eoghan


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

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

[Eoghan Glynn]

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

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

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

Cheers,
Eoghan

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

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

[Eoghan Glynn]

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

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

Cheers,
Eoghan

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

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

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

[Eoghan Glynn]

What sort of failure are you seeing?


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

[VOTE] Release CXF dOSGi 1.0

[Eoghan Glynn]

Folks,

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

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

The staging area can be found at:

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

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

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

The vote will remain open for at least 72 hours.

Please consider this call to vote as my +1.

Cheers,
Eoghan

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

Fwd: [VOTE] Release CXF dOSGi 1.0

[Eoghan Glynn]

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

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


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


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

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

Cheers,
Eoghan

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

Re: [VOTE] Release CXF dOSGi 1.0

[Eoghan Glynn]

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


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

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

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

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

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

Cheers,
Eoghan


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

Re: [VOTE] Release CXF dOSGi 1.0

[Eoghan Glynn]

Thanks Dan, should be sorted in this latest commit:

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

/Eoghan

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

[VOTE] Release CXF dOSGi 1.0 (take 2)

[Eoghan Glynn]

Folks,

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

The main differences between this and the first take are:

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

The distributions are staged at:

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

and the maven artifacts at:

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

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

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

The vote will remain open for at least 72 hours.

Please consider this call to vote as my +1.

Cheers,
Eoghan

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

[Eoghan Glynn]

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


Yeah, sure it could.

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

I'll replace it with something more maintainable.

/Eoghan

[VOTE][RESULT] Release CXF dOSGi 1.0

[Eoghan Glynn]

Hi Folks,

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

For the record, the aye-sayers were:

  eglynn, davidb, sberyozkin, ubhole, dkulp, jgenender

Cheers,
Eoghan

[ANN] Apache CXF dOSGi 1.0 released

[Eoghan Glynn]

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

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

Download information may be found here[2]

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

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

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

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

Regards,
The CXF dOSGi team.


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

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

[Eoghan Glynn]

Sorry that should be 7 aye-sayers:

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

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

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

For the record, the aye-sayers were:

  eglynn, davidb, sberyozkin, ubhole, dkulp, jgenender

Cheers,
Eoghan

Re: [VOTE] Release CXF 2.2.2

[Eoghan Glynn]

+1

/Eoghan

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

Re: [VOTE] Alessio Soldano for committer

[Eoghan Glynn]

+1

/Eoghan

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

Re: Integrating JAX-RS runtime into DOSGi

[Eoghan Glynn]

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

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

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

Cheers,
Eoghan

Re: CXF Roadmap

[Eoghan Glynn]

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

Is that something that would be of interest to you?

Cheers,
Eoghan

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

Re: Questions about CXF WS-RM

[Eoghan Glynn]

Hi Richard,

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

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

See below.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

No, unfortunately.

Hope this helps,
Eoghan

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

Re: Questions about CXF WS-RM

[Eoghan Glynn]

Hi Richard, further comments in-line ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cheers,
Eoghan

2009/6/18 Richard Opalka 

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

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

[Eoghan Glynn]

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

See [1] for details.

Cheers,
Eoghan

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


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

Re: [VOTE] Release CXF 2.0.12

[Eoghan Glynn]

 +1

/Eoghan

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

Re: [VOTE] Release CXF 2.1.6

[Eoghan Glynn]

+1

/Eoghan

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

Re: [VOTE] Release CXF 2.2.3

[Eoghan Glynn]

+1

/Eoghan

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

Re: Reliable messaging: Connecting to Oracle

[Eoghan Glynn]

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

I've committed the fix just now in r809738.

Cheers,
Eoghan

2009/8/27 Daniel Kulp 

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

Re: [VOTE] Release CXF 2.2.4

[Eoghan Glynn]

+1

/Eoghan

2009/10/8 Daniel Kulp 

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

Re: [VOTE] Release CXF 2.1.7

[Eoghan Glynn]

+1

/Eoghan

2009/10/8 Daniel Kulp 

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

Re: [VOTE] Release CXF 2.2.5

[Eoghan Glynn]

+1

2009/11/15 Daniel Kulp 

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

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

[Eoghan Glynn]

+1

/Eoghan

2009/11/15 Daniel Kulp 

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

[VOTE] Release CXF dOSGi 1.1

[Eoghan Glynn]

Folks,

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

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

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


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

The staging area is at:

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

The various distributions can be downloaded as follows:

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

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

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

The vote will remain open for at least 72 hours.

Please consider this call to vote as my +1.

Cheers,
Eoghan

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

[RESULT][VOTE] Release CXF dOSGi 1.1

[Eoghan Glynn]

Folks,

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

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

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

Cheers,
Eoghan

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

[Eoghan Glynn]

+1

Cheers,
Eoghan

2009/12/3 Daniel Kulp 

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

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

[Eoghan Glynn]

> Hope everyone is ok with this.

Go for it!

And welcome to the project, Marc.

Cheers,
Eoghan

Re: DOSGi deploy failing on Hudson

[Eoghan Glynn]

Hmmm ... smells like a Nexus issue.

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

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

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

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

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

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

Cheers,
Eoghan


2009/12/18 

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

Re: [VOTE] Release CXF 2.2.6

[Eoghan Glynn]

+1

Cheers,
Eoghan

2010/1/20 Freeman Fang 

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

Re: [VOTE] Release CXF 2.1.9

[Eoghan Glynn]

+1

Cheers,
Eoghan

2010/1/20 Daniel Kulp 

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

Re: [DOSGi] Reworking the system tests

[Eoghan Glynn]

David,

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

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

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

Cheers,
Eoghan


2010/1/22 

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

Re: [DOSGi] Reworking the system tests

[Eoghan Glynn]

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

Cheers,
Eoghan

2010/1/22 

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

Re: Apache Licensed JAX-RS Spec API JAR

[Eoghan Glynn]

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

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

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

These are Apache licensed.

Cheers,
Eoghan

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

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

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

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

 -Nick



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

 Davanum Srinivas

 02/10/2010 02:40 PM

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

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

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

 -- dims

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


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


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



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

Re: [VOTE] Marc Schaaf for committer

[Eoghan Glynn]

+1

Cheers,
Eoghan

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

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

Re: [VOTE] David Valeri for committer

[Eoghan Glynn]

+1

/Eoghan

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

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

Re: JMX enabling in CXF 2.2.6

[Eoghan Glynn]

Ulhas,

How are you picking up the config file?

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





to:





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

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

Cheers,
Eoghan


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

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

Re: JMX enabling in CXF 2.2.6

[Eoghan Glynn]

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

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

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


 
 
 
 
 
 

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

/Eoghan

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

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

Re: [VOTE] Release CXF 2.2.7

[Eoghan Glynn]

+1

/Eoghan

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

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

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

[Eoghan Glynn]

> Tasks left would be:
> * When the above is done, cut the actual release candidate(s).

I can help cutting the release when you're ready to go.

Cheers,
Eoghan


On 11 June 2010 16:53, David Bosschaert  wrote:

> Great, thanks Marc!
>
> I think we're getting close to something that is releasable.
>
> Tasks left would be:
> * Add a configuration item org.apache.cxf.rs.port. Sergey is this
> something that you might have time for? Or maybe we can do this
> together?
> * Make sure all the demos work (and update the docs) - this is
> something I would be happy to help out with.
> * When the above is done, cut the actual release candidate(s).
>
> Cheers,
>
> David
>
> On 11 June 2010 15:32, Marc Schaaf  wrote:
> > Hi,
> >
> > I just committed some changes which remove the "severe" messages that
> > where produced during the normal operation of the Topology Manager. Two
> > of them where obsolete by now and one concerned some missing
> > functionality of the Topology Manager that I've now added. This
> > concerned in particular the behaviour of the Topology Manager regarding
> > the import of services when the DSW is detected/added after the service
> > to be imported was found which is supported now.
> >
> > Cheers,
> > Marc
> >
> > On 05/12/2010 06:40 PM, David Bosschaert wrote:
> >> Hi all,
> >>
> >> Earlier this week the OSGi Alliance has approved the OSGi 4.2
> >> Enterprise Conformance Tests and Reference Implementations. The
> >> CXF-DOSGi project [1] is the Reference Implementation for the
> >> following OSGi 4.2 specs [2]:
> >>
> >> * Chapter 13 - Remote Services
> >> This spec describes Distributed OSGi from a user's point of view. It
> >> standardizes the properties that can be put on an OSGi service to make
> >> it available remotely and how a consumer can find out whether it's
> >> dealing with a local service or a remote one.
> >>
> >> * Chapter 122 - Remote Services Admin
> >> This spec standardizes the interfaces between internal components
> >> Remote Services implementations typically have. A Distribution
> >> Provider, Topology Manager and Discovery System. This makes it
> >> possible to mix&match these components from various implementations.
> >> For more information see slides 6-8 at [3].
> >>
> >> Many kudos to Marc Schaaf as he did a lot of the recent RI work.
> >> Also many kudos to Tim Diekmann from TIBCO who wrote the actual CT
> >> tests despite his busy schedule.
> >>
> >> So now that we have a passing RI I think it would make sense to start
> >> planning a CXF-DOSGi release. I'm wondering what we should do before
> >> that...
> >> 1. There are some SEVERE 'warnings' coming up, I believe from the
> >> Topology Manager. We should probably take a look at those.
> >> 2. I once added some Discovery system tests, which I ended up not
> >> enabling because of memory issues. I might want to try and get them
> >> working on all platforms.
> >> 3. Anything else?
> >>
> >> Best regards,
> >>
> >> David
> >>
> >> [1] http://cxf.apache.org/distributed-osgi.html
> >> [2] http://www.osgi.org/Download/Release4V42
> >> [3] http://www.slideshare.net/bosschaert/whats-newinos-gi42enterprise
> >>
> >
> >
>

Re: DOSGI: Update to CXF 2.2.9

[Eoghan Glynn]

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

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

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

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

Cheers,
Eoghan

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

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

Re: DOSGI: Update to CXF 2.2.9

[Eoghan Glynn]

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

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

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

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

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

Cheers,
Eoghan

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

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

Re: DOSGI: Update to CXF 2.2.9

[Eoghan Glynn]

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

Cheers,
Eoghan

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

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

Re: DOSGI: Update to CXF 2.2.9

[Eoghan Glynn]

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

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

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

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

Yeah.

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

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

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

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

Cheers,
Eoghan


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

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

Re: DOSGI: Update to CXF 2.2.9

[Eoghan Glynn]

> I think we're ready for a release!

Great!

> Eoghan would you have some cycles?

Yeah.

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

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

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

Cheers,
Eoghan


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

[2]

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


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

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

Re: DOSGI: Update to CXF 2.2.9

[Eoghan Glynn]

Hi David,

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

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

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

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

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

Cheers,
Eoghan


On 19 July 2010 10:30,  wrote:

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

Re: DOSGI: Update to CXF 2.2.9

[Eoghan Glynn]

OK, fair enough.

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

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

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

/Eoghan


On 19 July 2010 17:33,  wrote:

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

[VOTE] Release CXF dOSGi 1.2

[Eoghan Glynn]

Folks,

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

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

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


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

The staging area is at:

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

The various distributions can be downloaded as follows:

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

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

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

The vote will remain open for at least 72 hours.

Please consider this call to vote as my +1.

Cheers,
Eoghan

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

Re: [VOTE] Release CXF dOSGi 1.2

[Eoghan Glynn]

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


Folks,

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

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

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


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

The staging area is at:

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

The various distributions can be downloaded as follows:

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

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

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

The vote will remain open for at least 72 hours.

Please consider this call to vote as my +1.

Cheers,
Eoghan

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



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

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

Re: [VOTE] Release CXF dOSGi 1.2

[Eoghan Glynn]

Hi Sergey,

Do you want that info added to the release notes?

Cheers,
Eoghan

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

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

Re: [VOTE] Release CXF dOSGi 1.2

[Eoghan Glynn]

Folks,

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

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

Cheers,
Eoghan

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

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

[VOTE] Release CXF dOSGi 1.2 - Take 2

[Eoghan Glynn]

Folks,

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

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


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

The new staging area is:

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

The various distributions can be downloaded as follows:

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

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

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

The vote will remain open for at least 72 hours.

Please consider this call to vote as my +1.

Cheers,
Eoghan

[RESULT][VOTE] Release CXF dOSGi 1.2

[Eoghan Glynn]

Folks,

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

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

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

Cheers,
Eoghan

Re: [VOTE] Release CXF 2.1

[Eoghan Glynn]

+1

/Eoghan

Daniel Kulp wrote:
This is a vote to release CXF 2.1. 

Obviously, this is a pretty big release with a bunch of new things like 
JAX-WS 2.1 support, the JAX-RS stuff, the javascripts stuff, the CORBA 
binding from yoko, etc 

Of course, the other MAJOR new feature: it's no longer 
labeled "incubator"!



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


The distributions are in the "dist" directory. The "maven" directory 
contains the stuff that will by pushed to the maven repository. (the REAL 
maven repository, not the incubating one this time!!!)


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



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






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

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

[Eoghan Glynn]

+1 (take 2)

Daniel Kulp wrote:
This is a vote to release CXF 2.1. 

Obviously, this is a pretty big release with a bunch of new things like 
JAX-WS 2.1 support, the JAX-RS stuff, the javascripts stuff, the CORBA 
binding from yoko, etc 

Of course, the other MAJOR new feature: it's no longer 
labeled "incubator"!


The changes between this and the first take are:
1) Fixed version (removed beta) in release notes
2) Fixed urls in poms to new location (since the new site is now live)
3) Moved one of the obscure schemas (object.xsd) into /schemas so it will 
match the others and be "live" with the others.



The staging area is at:
http://people.apache.org/~dkulp/stage_cxf/2.1-take2


The distributions are in the "dist" directory. The "maven" directory 
contains the stuff that will by pushed to the maven repository. (the REAL 
maven repository, not the incubating one this time!!!)


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



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






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

Re: [VOTE] Release CXF 2.0.6

[Eoghan Glynn]

+1

/Eoghan

Daniel Kulp wrote:

This is a vote to release CXF 2.0.6

Once again, there have been a bunch of bug fixes and enhancements that 
have been done compared to the 2.0.5 release.   Over 20 JIRA issues are 
marked as resolved for 2.0.6.


Of course, the other MAJOR new feature: it's no longer 
labeled "incubator"!


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

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


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


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




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

System tests failing with AbstractMethodError on DeferredDocumentImpl.getInputEncoding()

[Eoghan Glynn]

Folks,

Does this error ring a bell with anyone?

"java.lang.AbstractMethodError: 
org.apache.xerces.dom.DeferredDocumentImpl.getInputEncoding()Ljava/lang/String;"


On a clean checkout of CXF trunk, I'm seeing a bunch of system tests 
fail with this error, seemingly triggered by a call into the WSDLToIDL 
tool. I'm confused as to why the CORBA stuff is even getting involved, 
as it looks like a common-or-garden SOAP over HTTP scenario in the test.


Output copied below if anyone cares to take a look.

Thanks,
Eoghan


$ java -version
java version "1.5.0_15"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
Java HotSpot(TM) Client VM (build 1.5.0_15-b04, mixed mode, sharing)
$ mvn -version
Maven version: 2.0.9
Java version: 1.5.0_15
OS name: "linux" version: "2.6.9-5.elsmp" arch: "i386" Family: "unix"
$ cd /work/cxf/work_23May2008/trunk/systests/
$ mvn test -Dtest=HTTPClientPolicyTest
[INFO] Scanning for projects...
[INFO] 


[INFO] Building Apache CXF System Tests
[INFO]task-segment: [test]
[INFO] 

[INFO] Setting property: classpath.resource.loader.class => 
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.

[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO] **
[INFO] Starting Jakarta Velocity v1.4
[INFO] RuntimeInstance initializing.
[INFO] Default Properties File: 
org/apache/velocity/runtime/defaults/velocity.properties
[INFO] Default ResourceManager initializing. (class 
org.apache.velocity.runtime.resource.ResourceManagerImpl)
[INFO] Resource Loader Instantiated: 
org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader

[INFO] ClasspathResourceLoader : initialization starting.
[INFO] ClasspathResourceLoader : initialization complete.
[INFO] ResourceCache : initialized. (class 
org.apache.velocity.runtime.resource.ResourceCacheImpl)

[INFO] Default ResourceManager initialization complete.
[INFO] Loaded System Directive: 
org.apache.velocity.runtime.directive.Literal

[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
[INFO] Loaded System Directive: 
org.apache.velocity.runtime.directive.Include
[INFO] Loaded System Directive: 
org.apache.velocity.runtime.directive.Foreach

[INFO] Created: 20 parsers.
[INFO] Velocimacro : initialization starting.
[INFO] Velocimacro : adding VMs from VM library template : 
VM_global_library.vm
[ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' 
in any resource loader.
[INFO] Velocimacro : error using  VM library template 
VM_global_library.vm : 
org.apache.velocity.exception.ResourceNotFoundException: Unable to find 
resource 'VM_global_library.vm'

[INFO] Velocimacro :  VM library template macro registration complete.
[INFO] Velocimacro : allowInline = true : VMs can be defined inline in 
templates
[INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline 
may NOT replace previous VM definitions
[INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will 
be  global in scope if allowed.

[INFO] Velocimacro : initialization complete.
[INFO] Velocity successfully started.
[INFO] [checkstyle:checkstyle {execution: validate}]
[INFO] Starting audit...
Audit done.

[INFO] Preparing pmd:check
[INFO] [pmd:pmd]
[INFO] [pmd:check {execution: validate}]
[INFO]
[INFO] [cxf-xml2fastinfoset:xml2fastinfoset {execution: xml2fastinfoset}]
[INFO] Resource directory does not exist: 
/work/cxf/work_23May2008/trunk/systests/src/main/java
[INFO] Resource directory does not exist: 
/work/cxf/work_23May2008/trunk/systests/src/main/resources
[INFO] Resource directory does not exist: 
/work/cxf/work_23May2008/trunk/systests/src/main/resources-filtered
[INFO] Resource directory does not exist: 
/work/cxf/work_23May2008/trunk/systests/target/generated/src/main/resources

[INFO] [build-helper:add-source {execution: add-source}]
[INFO] Source directory: 
/work/cxf/work_23May2008/trunk/systests/src/test/generated added.
Downloading: 
http://maven-repo/maven-proxy-javanet/repository/org.apache.ws.security/poms/wss4j-1.5.2.pom
Downloading: 
http://maven-repo/maven-proxy-release/repository/org/apache/ws/security/wss4j/1.5.2/wss4j-1.5.2.pom

[INFO] [cxf-corbatools:wsdl2idl {execution: generate-sources}]
May 23, 2008 4:34:20 PM 
org.apache.cxf.tools.corba.processors.wsdl.WSDLToCorbaProcessor 
setOutputFile

WARNING: Using default wsdl/idl filenames...
May 23, 2008 4:34:21 PM 
org.springframework.context.support.AbstractApplicationContext 
prepareRefresh
INFO: Refreshing 
[EMAIL PROTECTED]: display name 
[EMAIL PROTECTED]; startup date 
[Fri May 23 16:34:21 EDT 2008]; root 

Re: System tests failing with AbstractMethodError on DeferredDocumentImpl.getInputEncoding()

[Eoghan Glynn]

Thanks for the response Peter,

I'm seeing the problem in a fresh checkout of CXF trunk, where the 
parent pom explicitly depends on XmlSchema 1.4.2.


I've tried rolling that dependency back to 1.3.1 but no joy, as the 
version of Spring used by CXF latest doesn't likeXmlSchema 1.3.1:


Caused by: 
org.springframework.beans.factory.BeanDefinitionStoreException: 
Unexpected exception parsing XML document from class path 
resource[org/apache/cxf/systest/ws/policy/http.xml]; nested exception is 
java.lang.AbstractMethodError: 
javax.xml.parsers.DocumentBuilderFactory.setFeature(Ljava/lang/String;Z)V
at 
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:385)
at 
org.apache.cxf.bus.spring.ControlledValidationXmlBeanDefinitionReader.doLoadBeanDefinitions(ControlledValidationXmlBeanDefinitionReader.java:108)
at 
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:313)
at 
org.apache.cxf.bus.spring.ControlledValidationXmlBeanDefinitionReader.loadBeanDefinitions(ControlledValidationXmlBeanDefinitionReader.java:128)
at 
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBea

nDefinitions(XmlBeanDefinitionReader.java:290)
at 
org.springframework.beans.factory.support.AbstractBeanDefinitionReade

r.loadBeanDefinitions(AbstractBeanDefinitionReader.java:131)
at 
org.springframework.context.support.AbstractXmlApplicationContext.loa

dBeanDefinitions(AbstractXmlApplicationContext.java:108)
at 
org.apache.cxf.bus.spring.BusApplicationContext.loadBeanDefinitions(B

usApplicationContext.java:229)
at 
org.springframework.context.support.AbstractRefreshableApplicationCon

text.refreshBeanFactory(AbstractRefreshableApplicationContext.java:101)
at 
org.springframework.context.support.AbstractApplicationContext.obtain

FreshBeanFactory(AbstractApplicationContext.java:394)
at 
org.springframework.context.support.AbstractApplicationContext.refres

h(AbstractApplicationContext.java:324)
at 
org.apache.cxf.bus.spring.BusApplicationContext.(BusApplication

Context.java:86)
at 
org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory

..java:93)
... 27 more
Caused by: java.lang.AbstractMethodError: 
javax.xml.parsers.DocumentBuilderFactory.setFeature(Ljava/lang/String;Z)V
at 
org.apache.cxf.bus.spring.TunedDocumentLoader.createDocumentBuilderFa

ctory(TunedDocumentLoader.java:128)
at 
org.springframework.beans.factory.xml.DefaultDocumentLoader.loadDocum

ent(DefaultDocumentLoader.java:68)
at 
org.apache.cxf.bus.spring.TunedDocumentLoader.loadDocument(TunedDocum

entLoader.java:118)
at 
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadB

eanDefinitions(XmlBeanDefinitionReader.java:361)
... 39 more


Results :

Tests in error:

testUsingHTTPClientPolicies(org.apache.cxf.systest.ws.policy.HTTPClientPolicyTest)

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0

[INFO] 


[ERROR] BUILD FAILURE
[INFO] 



Peter Jones wrote:

Hi Eoghan,

On Fri, May 23, 2008 at 04:51:01PM +0100, Eoghan Glynn wrote:

Folks,

Does this error ring a bell with anyone?

"java.lang.AbstractMethodError: 
org.apache.xerces.dom.DeferredDocumentImpl.getInputEncoding()Ljava/lang/String;"


I saw this error recently with a project which had a cxf dependency.
In that case, several of the dependencies were bringing in different
versions of XmlSchema.  When creating a cxf server proxy, I was tripping on
this error.  I worked around the issue by depending specifically on
XmlSchema 1.3.1 in the project pom.  That version didn't try to invoke the
getInputEncoding() method as the later versions of XmlSchema seem to.
Maybe XmlSchema should be catching this error?  Anyway, I hope that helps
a little bit at least.

Cheers,
Peter

On a clean checkout of CXF trunk, I'm seeing a bunch of system tests 
fail with this error, seemingly triggered by a call into the WSDLToIDL 
tool. I'm confused as to why the CORBA stuff is even getting involved, 
as it looks like a common-or-garden SOAP over HTTP scenario in the test.


Output copied below if anyone cares to take a look.

Thanks,
Eoghan


$ java -version
java version "1.5.0_15"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
Java HotSpot(TM) Client VM (build 1.5.0_15-b04, mixed mode, sharing)
$ mvn -version
Maven version: 2.0.9
Java version: 1.5.0_15
OS name: "linux" version: "2.6.9-5.elsmp" arch: "i386" Family: "unix"
$ cd /work/cxf/work_23May2008/trunk/systests/
$ mvn test -Dtest=HTTPClientPolicyTest
[INFO] Scanning for projects...
[INFO] 
---

Re: System tests failing with AbstractMethodError on DeferredDocumentImpl.getInputEncoding()

[Eoghan Glynn]

Thanks for the tip Benson, but I don't think that's my problem.

My JDK (1.5.0_15) install is brand new, installed just a couple of hours 
ago, and doesn't even seem to have an endorsed dir (maybe this lives 
outside the JDK install tree these days?)


Cheers,
Eoghan

Benson Margulies wrote:

Have you been redecorating your 'endorsed' directory, or has your
distro been doing that behind your back? Do you have some specific
Xerces version in a POM someplace?

On Fri, May 23, 2008 at 11:51 AM, Eoghan Glynn <[EMAIL PROTECTED]> wrote:

Folks,

Does this error ring a bell with anyone?

"java.lang.AbstractMethodError:
org.apache.xerces.dom.DeferredDocumentImpl.getInputEncoding()Ljava/lang/String;"

On a clean checkout of CXF trunk, I'm seeing a bunch of system tests fail
with this error, seemingly triggered by a call into the WSDLToIDL tool. I'm
confused as to why the CORBA stuff is even getting involved, as it looks
like a common-or-garden SOAP over HTTP scenario in the test.

Output copied below if anyone cares to take a look.

Thanks,
Eoghan


$ java -version
java version "1.5.0_15"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
Java HotSpot(TM) Client VM (build 1.5.0_15-b04, mixed mode, sharing)
$ mvn -version
Maven version: 2.0.9
Java version: 1.5.0_15
OS name: "linux" version: "2.6.9-5.elsmp" arch: "i386" Family: "unix"
$ cd /work/cxf/work_23May2008/trunk/systests/
$ mvn test -Dtest=HTTPClientPolicyTest
[INFO] Scanning for projects...
[INFO]

[INFO] Building Apache CXF System Tests
[INFO]task-segment: [test]
[INFO]

[INFO] Setting property: classpath.resource.loader.class =>
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO] **
[INFO] Starting Jakarta Velocity v1.4
[INFO] RuntimeInstance initializing.
[INFO] Default Properties File:
org/apache/velocity/runtime/defaults/velocity.properties
[INFO] Default ResourceManager initializing. (class
org.apache.velocity.runtime.resource.ResourceManagerImpl)
[INFO] Resource Loader Instantiated:
org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader
[INFO] ClasspathResourceLoader : initialization starting.
[INFO] ClasspathResourceLoader : initialization complete.
[INFO] ResourceCache : initialized. (class
org.apache.velocity.runtime.resource.ResourceCacheImpl)
[INFO] Default ResourceManager initialization complete.
[INFO] Loaded System Directive:
org.apache.velocity.runtime.directive.Literal
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
[INFO] Loaded System Directive:
org.apache.velocity.runtime.directive.Include
[INFO] Loaded System Directive:
org.apache.velocity.runtime.directive.Foreach
[INFO] Created: 20 parsers.
[INFO] Velocimacro : initialization starting.
[INFO] Velocimacro : adding VMs from VM library template :
VM_global_library.vm
[ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in
any resource loader.
[INFO] Velocimacro : error using  VM library template VM_global_library.vm :
org.apache.velocity.exception.ResourceNotFoundException: Unable to find
resource 'VM_global_library.vm'
[INFO] Velocimacro :  VM library template macro registration complete.
[INFO] Velocimacro : allowInline = true : VMs can be defined inline in
templates
[INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may
NOT replace previous VM definitions
[INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be
 global in scope if allowed.
[INFO] Velocimacro : initialization complete.
[INFO] Velocity successfully started.
[INFO] [checkstyle:checkstyle {execution: validate}]
[INFO] Starting audit...
Audit done.

[INFO] Preparing pmd:check
[INFO] [pmd:pmd]
[INFO] [pmd:check {execution: validate}]
[INFO]
[INFO] [cxf-xml2fastinfoset:xml2fastinfoset {execution: xml2fastinfoset}]
[INFO] Resource directory does not exist:
/work/cxf/work_23May2008/trunk/systests/src/main/java
[INFO] Resource directory does not exist:
/work/cxf/work_23May2008/trunk/systests/src/main/resources
[INFO] Resource directory does not exist:
/work/cxf/work_23May2008/trunk/systests/src/main/resources-filtered
[INFO] Resource directory does not exist:
/work/cxf/work_23May2008/trunk/systests/target/generated/src/main/resources
[INFO] [build-helper:add-source {execution: add-source}]
[INFO] Source directory:
/work/cxf/work_23May2008/trunk/systests/src/test/

Re: System tests failing with AbstractMethodError on DeferredDocumentImpl.getInputEncoding()

[Eoghan Glynn]

Benson Margulies wrote:
Are you sure you got this on the trunk? 


Yep, I think so ...

/work/cxf/work_23May2008/trunk> svn info .
Path: .
URL: http://svn.apache.org/repos/asf/cxf/trunk
Repository Root: http://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 659539
Node Kind: directory
Schedule: normal
Last Changed Author: gawor
Last Changed Rev: 659419
Last Changed Date: 2008-05-23 00:34:12 -0400 (Fri, 23 May 2008)
Properties Last Updated: 2008-05-23 14:52:16 -0400 (Fri, 23 May 2008)



The setFeature error is a
dependency on a recent Xerces that Dan and I fixed up some weeks ago.
It's not related to XmlSchema or Spring.



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

Re: System tests failing with AbstractMethodError on DeferredDocumentImpl.getInputEncoding()

[Eoghan Glynn]

Benson Margulies wrote:

Fix committed on trunk.




Thanks Benson, I just picked up your change.

Slight tweak required, as the catch clause on Exception that you added 
around the factory.setBuilder() call doesn't catch AbstractMethodError.


But switching to a more generic catch Throwable and I'm back in 
business, the problematic test no longer blows up :)


Thanks again!

/Eoghan



On Fri, May 23, 2008 at 4:23 PM, Benson Margulies <[EMAIL PROTECTED]> wrote:

Hmm. Bug still there. I'll make a fix.

On Fri, May 23, 2008 at 4:21 PM, Benson Margulies <[EMAIL PROTECTED]> wrote:

Are you sure you got this on the trunk? The setFeature error is a
dependency on a recent Xerces that Dan and I fixed up some weeks ago.
It's not related to XmlSchema or Spring.




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

Re: Deploying a new 2.0.7-SNAPSHOT

[Eoghan Glynn]

Daniel Kulp wrote:


On May 27, 2008, at 12:26 PM, Eoghan Glynn wrote:



Thanks Dan,

Following the instructions on [1] I've run into an authentication 
failure after only a few modules are deployed to the repo.


Is there a way of rolling back the partially deployed artifacts, do 
you know?


Just redeploy.   Not a big deal.

For the most part, follow the "HIGHLY RECOMMENDED" section on that page 
to get the master mode stuff working.   By default, maven creates 3 
connections for each file being deployed which is:

1) slow as it's got to authenticate each time
2) unreliable - that many connections eats the entropy on both sides 
very quickly and may be the source of the authentication issues.


Makes sense.

BTW what's the deal on getting the PKI set up, to avoid keyboard 
interactive auth?


Cheers,
Eoghan

Another option is to change the protocol used from scpexe to just scp 
(top level pom, just change in you working copy, deploy, and then reset 
back).   On some OS's, I've had better luck with scp instead of 
scpexe.   Windows works best with scpexe.   Linux without master mode 
works best with scp.   I've only done scpexe+master mode on OSX so I'm 
not sure there.   However, master mode with scpexe is the most reliable.


Dan





Cheers,
Eoghan

[1] http://cxf.apache.org/release-management.html

Daniel Kulp wrote:

Eoghan,
It's pretty much "ad hoc" when someone needs one or if one of us has 
a fix in place that they want a user to test out.   If you need one, 
you should feel free to deploy one.
That said, I'll try and get a new one out later tonight if you don't 
get to it first.

Dan
On May 27, 2008, at 5:54 AM, Eoghan Glynn wrote:


Hi folks,

What would I need to do to arrange for an up-to-date 2.0.7-SNAPSHOT 
to be be deployed to the maven repo?


Is this normally done regularly or on an ad-hoc basis?

The timestamps on the 2.0.7-SNAPSHOT dir[1] in the maven repo 
suggest approximately once a week, but with a gap last week.


Cheers,
Eoghan

[1] 
http://people.apache.org/repo/m2-snapshot-repository/org/apache/cxf/cxf/2.0.7-SNAPSHOT/ 




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

---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog



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


---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog






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

Re: Deploying a new 2.0.7-SNAPSHOT

[Eoghan Glynn]

Benson Margulies wrote:

PKI already works. Just put your ssh key into your people.apache.org .ssh
dir.




Thanks Benson ... I was sure I'd copied over my public key ages ago, but 
  just checked my home dir on people.apache.org and I didn't even have 
a ~/.ssh dir, never mind an authorized_keys file.


Maybe my apache home dir was blown away at some point, or more likely I 
was thinking of some other host. Either way, all working now :)


Cheers,
Eoghan






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

opensaml-1.1 dependency [was: svn commit: r663146 - in /cxf/branches/2.0.x-fixes: ...]

[Eoghan Glynn]

Hi Dan,

I had to do an manual install of opensaml-1.1.jar in my local repo in 
order to get a 2.0.x build to work.


Is the opensaml stuff up on some obscure maven-repo that I need to add 
to my ~/.m2/settings.xml?


Cheers,
Eoghan


[EMAIL PROTECTED] wrote:

Author: dkulp
Date: Wed Jun  4 07:58:47 2008
New Revision: 663146

URL: http://svn.apache.org/viewvc?rev=663146&view=rev
Log:
Merged revisions 662883 via svnmerge from 
https://svn.apache.org/repos/asf/cxf/trunk



  r662883 | dkulp | 2008-06-03 16:55:58 -0400 (Tue, 03 Jun 2008) | 3 lines
  
  [CXF-1627] Update to latest wss4j to remove hacks needed to workaround bugs in the older version.

  Note: wss4j 1.5.4 requires the opensaml library to work at all.   Thus, that 
is added.


Modified:
cxf/branches/2.0.x-fixes/   (props changed)

cxf/branches/2.0.x-fixes/buildtools/src/main/resources/notice-supplements.xml
cxf/branches/2.0.x-fixes/rt/ws/security/pom.xml

cxf/branches/2.0.x-fixes/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/WSS4JInInterceptor.java

cxf/branches/2.0.x-fixes/rt/ws/security/src/test/java/org/apache/cxf/ws/security/wss4j/WSS4JInOutTest.java

Propchange: cxf/branches/2.0.x-fixes/
--
Binary property 'svnmerge-integrated' - no diff available.

Modified: 
cxf/branches/2.0.x-fixes/buildtools/src/main/resources/notice-supplements.xml
URL: 
http://svn.apache.org/viewvc/cxf/branches/2.0.x-fixes/buildtools/src/main/resources/notice-supplements.xml?rev=663146&r1=663145&r2=663146&view=diff
==
--- 
cxf/branches/2.0.x-fixes/buildtools/src/main/resources/notice-supplements.xml 
(original)
+++ 
cxf/branches/2.0.x-fixes/buildtools/src/main/resources/notice-supplements.xml 
Wed Jun  4 07:58:47 2008
@@ -162,7 +162,7 @@
   
   
 
-  xml-security
+  org.apache.santuario
   xmlsec
   XML Security
   
@@ -177,6 +177,23 @@
   
 
   
+
+
+  opensaml
+  opensaml
+  OpenSAML
+  
+Internet2
+http://www.opensaml.org
+  
+  
+
+  The Apache Software License, Version 2.0
+  http://www.apache.org/licenses/LICENSE-2.0.txt
+
+  
+
+  
   
 
   xml-apis

Modified: cxf/branches/2.0.x-fixes/rt/ws/security/pom.xml
URL: 
http://svn.apache.org/viewvc/cxf/branches/2.0.x-fixes/rt/ws/security/pom.xml?rev=663146&r1=663145&r2=663146&view=diff
==
--- cxf/branches/2.0.x-fixes/rt/ws/security/pom.xml (original)
+++ cxf/branches/2.0.x-fixes/rt/ws/security/pom.xml Wed Jun  4 07:58:47 2008
@@ -60,13 +60,29 @@
 
 org.apache.ws.security
 wss4j
-1.5.2
-
-
-xml-security
-xmlsec
-1.3.0
-runtime
+1.5.4
+
+
+axis
+axis
+
+
+axis
+axis-ant
+
+
+bouncycastle
+bcprov-jdk15
+
+
+xerces
+xercesImpl
+
+
+xml-apis
+xml-apis
+
+
 
 
 xalan

Modified: 
cxf/branches/2.0.x-fixes/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/WSS4JInInterceptor.java
URL: 
http://svn.apache.org/viewvc/cxf/branches/2.0.x-fixes/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/WSS4JInInterceptor.java?rev=663146&r1=663145&r2=663146&view=diff
==
--- 
cxf/branches/2.0.x-fixes/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/WSS4JInInterceptor.java
 (original)
+++ 
cxf/branches/2.0.x-fixes/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/WSS4JInInterceptor.java
 Wed Jun  4 07:58:47 2008
@@ -24,8 +24,8 @@
 import java.util.Vector;
 import java.util.logging.Level;
 import java.util.logging.Logger;
-
 import javax.security.auth.callback.CallbackHandler;
+import javax.xml.namespace.QName;
 import javax.xml.soap.SOAPBody;
 import javax.xml.soap.SOAPException;
 import javax.xml.soap.SOAPMessage;
@@ -44,6 +44,8 @@
 import org.apache.cxf.phase.Phase;
 import org.apache.cxf.staxutils.StaxUtils;
 import org.apache.ws.security.WSConstants;
+import org.apache.ws.security.WSSConfig;
+import org.apache.ws.security.WSSecurityEngine;
 import org.apache.ws.security.WSSecurityEngineResult;
 import org.apache.ws.security.WSSecurityException;
 import org.apache.ws.security.handler.RequestData;
@@ -61,12 +63,18 @@
 
 public static final String TIMESTAMP_RESULT = "wss4j.timestamp.result";

  

Re: [VOTE] Release CXF 2.1.1

[Eoghan Glynn]

+1

Daniel Kulp wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


This is a vote to release CXF 2.1.1

Once again, there have been a bunch of bug fixes and enhancements that
have been done compared to the 2.1 release.   Over 74 JIRA issues are
resolved for 2.1.1 which is a large number of fixes.


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

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

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


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


- ---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog




-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4 (Darwin)

iD8DBQFIV80oq8juObtVB0YRAiLyAJ9+HiWq61I9JZ01kRpr4g+L1O7woQCcCHbK
G1xxwnA5MSe77DORVGTRy3o=
=cx57
-END PGP SIGNATURE-



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

Re: [VOTE] Release CXF 2.0.7

[Eoghan Glynn]

+1

Daniel Kulp wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



This is a vote to release CXF 2.0.7

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


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

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

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


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


- ---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog




-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4 (Darwin)

iD8DBQFIV83Qq8juObtVB0YRAk9IAJ94zSGaE98mw4z2UOdcCeX8HzAntACfb4Zv
Px3oDUHzRTC53LDAs2yxIz8=
=fif0
-END PGP SIGNATURE-



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

Re: Ideas for 2.2

[Eoghan Glynn]

Daniel Kulp wrote:


5) OSGi stuff - I know there are some OSGi enhancements in the works 
that could be pulled in:
   a) osgi http transport - this currently lives in ServiceMix, but 
could be pulled into CXF to work with other OSGi runtimes
   b) Distributed OSGi (RFC 119) - there is work being done to implement 
RFC 119 with CXF.   There are some rules about releasing the IP for this 
though that is being investigated.


Sergey and myself have been working on a CXF-based reference 
implementation of RFC 119, and we'd be on for contributing this to CXF 
once the IP is cleared by the OGSi expert group. Hopefuly this will 
happen within the next month or so.


Cheers,
Eoghan


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

Re: Ideas for 2.2

[Eoghan Glynn]

Christian Schneider wrote:
I would really like to see good osgi integration as we plan to rely 
quite heavily on osgi in the future. But as I myself are only starting 
on this I don´t know much about the details. Basically I would like to 
be able  to connect the osgi internal services with cxf to communicate 
with the outside world. So a client should be able to simply use an osgi 
service. The provider of the service could then be simply a local bundle 
or a cxf based kind of binding component that does the remoting. I hope 
somthing like this will come from servicemix.



Christian,

The scenario you mention - client just using OSGi services as it would 
in a purely local case, but with CXF transparently providing the 
remoting capability - is exactly what Distributed OSGi / RFC 119 is all 
about.


So I think you're in luck :)

Cheers,
Eoghan



Daniel Kulp schrieb:


5) OSGi stuff - I know there are some OSGi enhancements in the works 
that could be pulled in:
   a) osgi http transport - this currently lives in ServiceMix, but 
could be pulled into CXF to work with other OSGi runtimes
   b) Distributed OSGi (RFC 119) - there is work being done to 
implement RFC 119 with CXF.   There are some rules about releasing the 
IP for this though that is being investigated.

Tracking trunk commits blocked wrt to the 2.0.x_fixes branch

[Eoghan Glynn]

Folks,

Does anyone know if svnmerge.py can be used to report on the commits to 
trunk that have been "blocked" wrt to merging out to the 2.0.x_fixes branch?


Its sortta like a retrospective "avail" option that I'm after, i.e. 
gimme all the commits that were available for merging, but were selected 
for blocking.


The idea would be to get a definitive list of potentially 
backward-incompatible changes to 2.1 that may cause issues when 
upgrading from 2.0.x.


Cheers,
Eoghan





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

Re: Tracking trunk commits blocked wrt to the 2.0.x_fixes branch

[Eoghan Glynn]

Thanks Dan & Freeman,

Both suggested methods give exactly the same results.

A total of well over blocked 500 commits ... ouch, that's a lot to go 
thru manually.


BTW what's general feeling on the completeness of the 2.1 Migration 
Guide[1] wrt capturing potential compatibility issues?


Cheers,
Eoghan

[1] http://cxf.apache.org/21-migration-guide.html

Daniel Kulp wrote:



It's all stored as properties on the directory.   Thus:

svn propget svnmerge-blocked .

would give you the list of revisions.   THAT said, the stuff gnodet, 
Freeman, and Willem have merged without using svnmerge.py may appear in 
that list.


On a related note:  I'm not using subversion 1.5 and the Apache server 
is using subversion 1.5.   Thus, we probably could stop using 
svnmerge.py and flip over to the tracking support in 1.5.   However, 
that would require all the mergers to use subversion 1.5 which I'm not 
sure if everyone is ready to do or not.



Dan


On Jul 17, 2008, at 8:54 AM, Eoghan Glynn wrote:



Folks,

Does anyone know if svnmerge.py can be used to report on the commits 
to trunk that have been "blocked" wrt to merging out to the 
2.0.x_fixes branch?


Its sortta like a retrospective "avail" option that I'm after, i.e. 
gimme all the commits that were available for merging, but were 
selected for blocking.


The idea would be to get a definitive list of potentially 
backward-incompatible changes to 2.1 that may cause issues when 
upgrading from 2.0.x.


Cheers,
Eoghan





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


---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog






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

Re: [VOTE] Release CXF 2.0.8

[Eoghan Glynn]

+1

Daniel Kulp wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



This is a vote to release CXF 2.0.8

Once again, there have been a bunch of bug fixes and enhancements that 
have been done compared to the 2.0.8 release.   Over 28 JIRA issues are 
resolved for 2.0.8.  Most importantly, this contains a critical fix that 
was preventing Geronimo from being able to upgrade to our recent 
releases.   They need this so they can release Geronimo 2.1.2 which they 
would like to do next week.


List of issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12313269&styleName=Html&projectId=12310511&Create=Create 



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

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

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


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

- ---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog




-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4 (Darwin)

iD8DBQFIhos1q8juObtVB0YRAu+GAJ9wlLmUL603COMNIv52xwvB2+XMgACaA8K2
0OImzd5F9+EtcKeWx+Rf7i0=
=kqY9
-END PGP SIGNATURE-



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

Re: [VOTE] Release Apache CXF 2.1.2

[Eoghan Glynn]

+1

Daniel Kulp wrote:


This is a vote to release CXF 2.1.2

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


List of issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12313268&styleName=Html&projectId=12310511&Create=Create

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

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

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


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





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

Re: Concerns about the Camel / CXF documentation

[Eoghan Glynn]

-1 to decommissioning the CXF JMS transport.

If there are perceived shortcomings in the CXF JMS transport config, 
lets identify these issues, raise corresponding JIRAs, and get them fixed.


/Eoghan

Benson Margulies wrote:

My question is dumber. If Camel, a part of Apache, is a superior
comestible for this purpose, should we consider decommissioning or
deprecating the existing CXF JMS in favor of just using it?

On Thu, Aug 28, 2008 at 6:15 AM, Christian Schneider
<[EMAIL PROTECTED]> wrote:

Glen Mazza schrieb:

Christian,

I have a few concerns about your write up on using Camel as a JMS
alternative with CXF[1]:

1.)  I don't understand why you are duplicating your blog entry on a CXF
confluence page.  Can't you just keep your blog entry up-to-date with your
link to it from our articles[2] page (and perhaps a few sentences on our
JMS
page linking to it, for those who miss the articles page)?  Your article
looks nicer on your blog anyway than it does with Confluence formatting.


Hi Glen,

I also use confluence on my blog. So the duplication effort is at least
quite small. The reason why I duplicated the content is that I on the one
hand wanted
to really contribute the article to cxf so anyone on the wiki can improve it
later. On the other hand I wanted to establish my blog. If I only wrote the
article on my
blog no one would be able to do modifications beside myself. If I only had
written the article on the Wiki I could not establish my blog. Shame on me
for using CXF for this ;-) I can cut the link if you think it is inadequate.

Btw. if the article looks nicer on my blog we could perhaps improve the
design of the cxf confluence pages ;-)

2.)  The quality of the writing on the Confluence page is not very
clean--it
hasn't been spell-checked, capitalization is frequently off ("apache
camel"
instead of "Apache Camel"), detracting from the CXF documentation as a
whole, and the tone reads too informally.  Also, you have too many
references to specific developers and regular usage of the first-person
"I"--it is written like a blog entry instead of actual system
documentation. We really don't have time to be cleaning this documentation
up, you need to
proofread more carefully.


That´s why I started the article on my blog and announced it on the mailing
list. I hoped that some of these problems would be found before I added the
article to the wiki.
But I got no response on the list so I added the article a day later. I will
try to improve the style and naming schemes today if that is ok.

I write blog entries and link them to the articles page, and I also update
the CXF system documentation (sometimes linking to a blog entry, either
mine
or others).  But the writing styles are different, and the types of things
you include are different.  In particular, you are tying your Confluence
article too much to yourself, but Confluence pages are for any team member
to edit, and are normally written without reference to any particular
author.


Thanks for the hints about the style. I will try to do this better in the
future. Perhaps it is a good idea to
write a howto on the project page in a neutral style. Then I could pack an
announcement to the howto together with my personal opinions on my blog in a
personal style. So the two
would be separated nicely. I think I still have to learn a bit aboutt
blogging ;-)

3.)  The tone of the documentation would appear to make it a better
candidate on the Camel site rather than the CXF one, for two reasons.
 (And
I'm sure James Strachan would be happy to give you a place to write
articles.)  For one thing, the criticisms of the CXF product, as in your
entry paragraphs, is unnatural within CXF documentation.


You are right. I think it would be better to add the Howto to the Camel site
and link it from CXF Howtos. I can move the article.
The problem with the current Camel site is that you almost do not find the
Camel CXF Transport although it is
the better solution than the CXF component. For me the main idea behind
publishing this article was that I had many problems configuring
JMS for CXF and that the Camel integration really helped. So I hope to help
others with configuring JMS. If I would only add the article to the Camel
Wiki
the CXF users who do not need Camel but have problems with JMS would not
find it.

As a second intention I would like to help improve the CXF JMS config and
hope that the style Camel uses can be a good pattern for an improved native
JMS
config for CXF.

Quote:  "Configuring JMS in Apache CXF is possible but not really easy or
nice. This article shows how to use Apache Camel to provide a better JMS
Transport for CXF...JMS configuration in Apache CXF is possible but the
configuration is not very flexible and quite error prone. In CXF you have
to
configure a JMSConduit or a JMSDestination for each webservice. The
connection between Conduit and the Service proxy is the endpoint name
which
looks like "{http://service.test\}HelloWorldPort.jms-conduit";. 

Re: WS-RM issue

[Eoghan Glynn]

Dunno if I'd agree with this JIRA, if I've understood it correctly.

For a request-response MEP, WS-RM can be configured so that a "202 
Accepted" response is immediately sent back to the client (possibly 
including an eager ACK) and then whenever it becomes available the real 
response is sent over a separate server->client connection.


/Eoghan


Bharath Ganesh wrote:

https://issues.apache.org/jira/browse/CXF-1156

Look like WS-RM makes more sense for aysncronous invocation and one way
invocation (quite similar to JMS reliability), rather than a standard
request-response pattern.
So the above issue wont be a very valid case. Am I right?




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

Re: WS-RM issue

[Eoghan Glynn]

Well, yes, at the transport-level the interaction is sort of asynchronous.

But from the application-level it would appear to be synchronous.

[Unless of course the JAX-WS async callback/pollable model is used, but 
this is a choice orthogonal to any asynchrony in the transport]


So I would see it as a synchronous request-response MEP.

Cheers,
Eoghan

Bharath Ganesh wrote:

So that is kind of an asynchronous invocation. Not a synchronous
request-response pattern.That again means the JIRA is not a very valid use
case. If convinced, I shall close the JIRA.


On Sat, Sep 6, 2008 at 12:42 AM, Eoghan Glynn <[EMAIL PROTECTED]> wrote:


Dunno if I'd agree with this JIRA, if I've understood it correctly.

For a request-response MEP, WS-RM can be configured so that a "202
Accepted" response is immediately sent back to the client (possibly
including an eager ACK) and then whenever it becomes available the real
response is sent over a separate server->client connection.

/Eoghan



Bharath Ganesh wrote:


https://issues.apache.org/jira/browse/CXF-1156

Look like WS-RM makes more sense for aysncronous invocation and one way
invocation (quite similar to JMS reliability), rather than a standard
request-response pattern.
So the above issue wont be a very valid case. Am I right?




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






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

Re: [DOSGi] Few questions re current DOSGi implementation (sandbox)

[Eoghan Glynn]

David Bosschaert wrote:

Hi all,

I'm trying to get rid of the exception that shows up when you distribute 
a service in a bundle that doesn't provide an intent-map.xml file. 
Currently this seems to work well, but an exception comes up on the 
screen. If a user doesn't provide this map, simply the default 
distribution settings (intents) should be used.

Would simply using a
 new IntentMap()
be enough? or should I try to get a default IntentMap from somewhere else?


The idea was to merge the calling-bundle-specific IntentMap with the 
master map from the DSW bundle, so that the calling bundle could 
override some intent->policy mappings, or add some new ones.


So if the client bundle doesn't require any such overrides, simply 
creating an empty IntentMap as you propose is fine.



Next question.
When I expose a service registered under multiple interfaces, what is it 
supposed to do in today's codebase?
Will it somehow expose both interfaces over the wire or does it just 
pick one?


The intention was to support the multi-interface case mapping to a 
single endpoint by creating a java.lang.reflect.Proxy aggregating the 
interfaces, and using this proxy as the service class on the 
ServerBeanFactory.


However this introduces some complications around the namespace mapping 
used the Aegis binding, particularly in ensuring that the namespace used 
for client-originated payloads match that expected by the server-side.


So this approach will require some core CXF changes in order to work, 
and isn't supported right now.


For the moment, maybe we should just take the simple approach of mapping 
each interface onto a /separate/ endpoint.


/Eoghan


I'm looking at changing the behaviour of the org.osgi.remote.publish 
property with the behaviour in the spec (instead of the value 
'false|true' a list of interfaces or '*' for all published interfaces 
should be provided).


Thanks,

David


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



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

Re: [DOSGi] Few questions re current DOSGi implementation (sandbox)

[Eoghan Glynn]

Daniel Kulp wrote:

Eoghan,

On Thursday 11 September 2008 5:52:20 am Eoghan Glynn wrote:

Next question.
When I expose a service registered under multiple interfaces, what is it
supposed to do in today's codebase?
Will it somehow expose both interfaces over the wire or does it just
pick one?

The intention was to support the multi-interface case mapping to a
single endpoint by creating a java.lang.reflect.Proxy aggregating the
interfaces, and using this proxy as the service class on the
ServerBeanFactory.

However this introduces some complications around the namespace mapping
used the Aegis binding, particularly in ensuring that the namespace used
for client-originated payloads match that expected by the server-side.

So this approach will require some core CXF changes in order to work,
and isn't supported right now.


Actually, you shouldn't need to refactor any core CXF for this I think.  If 
you write your own ServiceConfiguration object, there are methods for getting 
the qnames for the request/response wrappers and such where you can make sure 
you get the correct namespaces from the correct implementation.   Just 
register your version before the default versions.



Nice one, thanks for the heads-up. We'll look at using this approach to 
simplify the multi-interface case.


Due to recent changes to the RFC 119 spec, we're not guaranteed that the 
client is made aware of all the interfaces exposed by the OSGi service, 
or even the fact that its a multi-interface service.


So for a service that exposes two interfaces, say foo.bar.I1 and 
sna.fu.I2, would it make sense to think of a server-side 
ServiceConfiguration that's capable of accepting incoming namespaces 
based on /either/ "foo.bar" or "sna.fu" (depending on which interface 
the client has resolved)?


Or would the correct approach be to use a client-side 
ServiceConfiguration to map onto some agreed namespace decoupled from 
both the foo.bar & sna.fu packages?


Cheers,
Eoghan



Dan




For the moment, maybe we should just take the simple approach of mapping
each interface onto a /separate/ endpoint.

/Eoghan


I'm looking at changing the behaviour of the org.osgi.remote.publish
property with the behaviour in the spec (instead of the value
'false|true' a list of interfaces or '*' for all published interfaces
should be provided).

Thanks,

David


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


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







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

Re: [VOTE] Christian Schneider for committer

[Eoghan Glynn]

+1

/Eoghan

Daniel Kulp wrote:
Christian has been doing quite a bit of very good work doing an almost "ground 
up" re-write of the JMS transport which is a very challenging and complicated 
task.


He's done quite a bit of work documenting various JMS things on the Wiki and 
even wrote an article about how to integrate the Camel transport into CXF.


He's also been very good about talking about his ideas on the dev list, 
responding to user queries about the areas he's familiar with, etc...


Basically, I think he's already been a valuable asset to the project and has 
earned a spot as a committer. 


[  ] +1
[  ] -1 


Vote will remain open for at least 72 hours.




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

Re: [dosgi] Patch for compilation failure (CXF-1830)

[Eoghan Glynn]

Thanks for this David,

I'll apply your patch now.

Cheers,
Eoghan

David Bosschaert wrote:

Hi all,

I attached a patch for a compilation failure of the dosgi code in the 
sandbox to bug https://issues.apache.org/jira/browse/CXF-1830

Would greatly appreciate if someone could apply.

Many thanks,

David


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



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

Re: [DOSGi] Patch for the first portion of CXF-1836

[Eoghan Glynn]

Thanks David,

Just applied the patch.

Cheers,
Eoghan

David Bosschaert wrote:

Hi all,

I've attached a patch that implements the first part of 
https://issues.apache.org/jira/browse/CXF-1836 to this bug.

New unit tests are included too.

Would greatly appreciate if someone could apply the patch.

Thanks,

David


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



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

Re: [DOSGi] patch for second part of CXF-1836

[Eoghan Glynn]

Now applied, thanks ...

/Eoghan

David Bosschaert wrote:

Hi all,

I've attached a patch with the implementation of the 
DistributionProvider.getRemoteServices() API to 
https://issues.apache.org/jira/browse/CXF-1836

New unit tests included too.

Small changes - frequent commits :) If larger patches are preferred, let 
me know!


Thanks,

David


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



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

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

[Eoghan Glynn]

Thanks for the patch David, now applied.

/Eoghan


David Bosschaert wrote:

Hi all,

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

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



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

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

Would greatly appreciate if someone could apply the patch.

Best regards,

David


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



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

Re: Proposal for a new JMS configuration for CXF

[Eoghan Glynn]

Hi Dan,

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


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


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


Possible wrinkles would include things like:

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


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


Cheers,
Eoghan


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






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









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



Dan



On Sunday 05 October 2008, Christian Schneider wrote:

Hi Willem,

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

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

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

Greetings

Christian

Willem Jiang schrieb:

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

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

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

Any thoughts?







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

Re: Proposal for a new JMS configuration for CXF

[Eoghan Glynn]

Daniel Kulp wrote:


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


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


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


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


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


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


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

  

  


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

...
  

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


Cheers,
Eoghan



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

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

[Eoghan Glynn]

Thanks David, patch applied.

/Eoghan

David Bosschaert wrote:

Hi all,

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



It would be great if someone could apply the patch.

Thanks!

David


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



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

Re: [DOSGi] patch for CXF-1851

[Eoghan Glynn]

Thanks David,

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

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


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


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

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


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


Cheers,
Eoghan


David Bosschaert wrote:

Hi all,

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

Would greatly appreciate if someone could apply it.
Thanks!

David


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



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

Re: [DOSGi] patch for CXF-1851

[Eoghan Glynn]

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

mv a b
mv b c


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


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

Cheers,

David

Eoghan Glynn wrote:


Thanks David,

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

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


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


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

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


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


Cheers,
Eoghan


David Bosschaert wrote:

Hi all,

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

Would greatly appreciate if someone could apply it.
Thanks!

David


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



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




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



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

Re: [DOSGi] patch for CXF-1851

[Eoghan Glynn]

Thanks David, patch is applied.

/Eoghan

David Bosschaert wrote:

Hi Eoghan,

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


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


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


Hope this works.

Cheers,

David

Eoghan Glynn wrote:


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

mv a b
mv b c


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


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

Cheers,

David

Eoghan Glynn wrote:


Thanks David,

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

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


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


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

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


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


Cheers,
Eoghan


David Bosschaert wrote:

Hi all,

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

Would greatly appreciate if someone could apply it.
Thanks!

David



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



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

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

[Eoghan Glynn]

Thanks David, patch applied.

David Bosschaert wrote:

Hi all,

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


Would appreciate if someone could apply.

Thanks!

David


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



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

Re: [VOTE] Release CXF 2.0.9

[Eoghan Glynn]

+1

Willem Jiang wrote:

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


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

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

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

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

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


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

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

zWAAn04fkhek/PMlgRHwCeevV45CTwN6
=4dc9
-END PGP SIGNATURE-



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

RE: [DOSGi] Patch for CXF-1876

[Eoghan Glynn]

Thanks David, applied.
Cheers,
Eoghan

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

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

Cheers,

David

RE: Distributed OSGi update

[Eoghan Glynn]

Thanks David for this summary!

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

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

Cheers,
Eoghan 


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

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

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

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

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

Best regards,

David

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

RE: [DOSGi] Patch for CXF-1876

[Eoghan Glynn]

No worries, will do ...

/Eoghan

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

Cheers,

David

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