[VOTE] Release CXF dOSGi 1.0 (take 2)
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,
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
On Thu May 7 2009 10:04:10 am egl...@apache.org wrote:
> Author: eglynn
> Date: Thu May 7 14:04:09 2009
> New Revision: 772651
>
> URL: http://svn.apache.org/viewvc?rev=772651&view=rev
> Log:
> [dOSGi] Update version in distro xslt files
>
> Modified:
>
> cxf/dosgi/trunk/distribution/multi-bundle/src/main/xsl/equinox_distro_confi
>g.xslt
> cxf/dosgi/trunk/distribution/multi-bundle/src/main/xsl/felix_distro_config.
>xslt
>
> Modified:
> cxf/dosgi/trunk/distribution/multi-bundle/src/main/xsl/equinox_distro_confi
>g.xslt URL:
> http://svn.apache.org/viewvc/cxf/dosgi/trunk/distribution/multi-bundle/src/
>main/xsl/equinox_distro_config.xslt?rev=772651&r1=772650&r2=772651&view=diff
> ===
>=== ---
> cxf/dosgi/trunk/distribution/multi-bundle/src/main/xsl/equinox_distro_confi
>g.xslt (original) +++
> cxf/dosgi/trunk/distribution/multi-bundle/src/main/xsl/equinox_distro_confi
>g.xslt Thu May 7 14:04:09 2009 @@ -5,7 +5,7 @@
> org.ops4j.pax.web.session.timeout=30
>
> osgi.bundles=org.eclipse.osgi.servi...@start, \
> - select="//bundles/bundle">../apache-cxf-dosgi-ri-1.0/dosgi_bundles/ue-of select="substring-after(text(),
> '.dir/apache-cxf-dosgi-ri-1.0/dosgi_bundles/')"/> select="string('@start, ')"/> + select="//bundles/bundle">../apache-cxf-dosgi-ri-1.1-SNAPSHOT/dosgi_bundles
>/ select="string('@start, ')"/>
>
>
>
> Modified:
> cxf/dosgi/trunk/distribution/multi-bundle/src/main/xsl/felix_distro_config.
>xslt URL:
> http://svn.apache.org/viewvc/cxf/dosgi/trunk/distribution/multi-bundle/src/
>main/xsl/felix_distro_config.xslt?rev=772651&r1=772650&r2=772651&view=diff
> ===
>=== ---
> cxf/dosgi/trunk/distribution/multi-bundle/src/main/xsl/felix_distro_config.
>xslt (original) +++
> cxf/dosgi/trunk/distribution/multi-bundle/src/main/xsl/felix_distro_config.
>xslt Thu May 7 14:04:09 2009 @@ -7,7 +7,7 @@
>
> felix.auto.start.2=http://www.apache.org/dist/felix/org.osgi.compendium-1.2
>.0.jar
> -felix.auto.start. select="$i"/>=file:apache-cxf-dosgi-ri-1.0/dosgi_bundles/ select="substring-after(text(),
> '.dir/apache-cxf-dosgi-ri-1.0/dosgi_bundles/')"/>
> +felix.auto.start. select="$i"/>=file:apache-cxf-dosgi-ri-1.1-SNAPSHOT/dosgi_bundles/e-of select="substring-after(text(),
> '.dir/apache-cxf-dosgi-ri-1.1-SNAPSHOT/dosgi_bundles/')"/>
>
>
--
Daniel Kulp
dk...@apache.org
http://www.dankulp.com/blog
Re: [VOTE] Release CXF dOSGi 1.0 (take 2)
+1 David 2009/5/7 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
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
Re: svn commit: r772651 - in /cxf/dosgi/trunk/distribution/multi-bundle/src/main/xsl: equinox_distro_config.xslt felix_distro_config.xslt
2009/5/7 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 > You could probably take a similar approach to what is done with http://svn.apache.org/repos/asf/cxf/dosgi/trunk/distribution/multi-bundle/src/main/resources/distro_bundles.xml It uses Maven filtering to put in versions... David
Re: [VOTE] Release CXF dOSGi 1.0 (take 2)
+1 - Original Message - From: "Eoghan Glynn" To: Sent: Thursday, May 07, 2009 3:01 PM Subject: [VOTE] Release CXF dOSGi 1.0 (take 2) 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: Writing my own transport
Hi Dan, Long story short, I got this working yesterday. This concept of Local Transport in CXF is very useful for custom transports. I think there should be more documentation on how to use this. I also think that Interceptors is another very useful thing for customizing, more documentation would be very helpful. I had the following working before, LocalConduit.prepare() sets up the Message's OutputStream (this is on the server side). LocalConduit's MessageObserver gets the response from the Endpoint object reference. On the Client Side, I could intercept the messages from the Service's Client side proxy/Dispatch in the LocalDestination's MessageObserver. The problem was this, How do I send back the response from the LocalDestination's MessageObserver, back to the Caller of the Client Proxy or Dispatch.invoke() ? After a few days of trial and error I found out, that I can get the OutputStream of a Message in the Destination's Observer as follows: Conduit c = message.getDestination().getBackChannel(message, null, null); Then it was fairly simple as before, call the Conduit.prepare(Message) to get the OutputStream, write to this and this will automatically send the response back to the Caller of the Dispatch.invoke() or ClientProxy. Thank you very much for following this up. Thanks for all the help. Regards Bharath. dkulp wrote: > > > Bharath, > > Did you get this working? > > Basically, the Conduit extends Observable and the client registers a > MessageObserver with the conduit via the setMessageObserver call. On the > incoming message, you would need to setup a Message and just call the > onMessage call of that observer.That should be it. > > Basically, in code: > > Message inMessage = new MessageImpl(); > exchange.setInMessage(inMessage); > > //set things like protocol headers and stuff here > > inMessage.setContent(InputStream.class, is); > > incomingObserver.onMessage(inMessage); > > > > Dan > > > On Sat April 25 2009 2:09:44 am Bharath Gargesh wrote: >> Hi Dan and Ulhas, >> >> Thanks to you two, now I can publish messages to Local Transport and >> intercept them. >> >> Now I am able to intercept the messages in the MessageObservers of the >> LocalDestination and the LocalConduit. >> >> I work on a platform which provides Java API for IPC. The API allows >> transfer of bytes from one process to another. >> My plan is as follows: >> >> 1.) Publish a JAX-WS endpoint on a local Transport, Get the LocalConduit >> and register a MessageObserver in it. Wait for IPC messages here, when >> any >> message is got, convert this to SOAP message and send it to the Local >> JAX-WS Endpoint Impl, get the response and Reply back. >> >> 2.) Now the Client (JAX-WS Client). Get the LocalDestination (register a >> dummy local Endpoint here) and register the MessageObserver. Intercept >> the >> messages from the Client here and post the messages to the Step 1.) >> through >> IPC. I can get the response from the JAX-WS Service. >> >> But now I am stuck here. How do I reply the response to the caller/JAX-WS >> Client. >> >> Where should I look into (Interceptors and Phases ?). Kindly provide a >> brief outline of how do I acheive the above. Or simply put, How can I >> propagate the message from LocalDestination's MessageObserver back to the >> caller ? >> >> Kindly reply. >> >> Regards >> Bharath >> >> dkulp wrote: >> > Bharath, >> > >> > It's relatively simple. >> > >> > Service service = new Service(seviceName); >> > service.addPort(portName, >> > "http://schemas.xmlsoap.org/soap/";, >> > "local://localhost:9090/hello"); >> > HelloInterface proxy = service.getPort(portName, HelloInterface.class); >> > >> > Basically, use the same URL as you did for the server side publish. >> > >> > >> > Dan >> > >> > On Fri April 24 2009 6:29:07 am Bharath Gargesh wrote: >> >> Hi Dan, >> >> I wanted to write my own transport, but then I saw your reply to this >> >> thread and found out a way to do this. >> >> But only that I was able to go half way through. >> >> On the Server side I did the following: >> >> 1.) Develop a JAX-WS and publish it to a local address. >> >> 2.) Got a handle to the LocalConduit through the Default Bus >> >> 3.) Registered a Listener to the Conduit. >> >> 4.) Prepare a SOAP Message for calling the JAX-WS, publish it >> >> to the Conduit.close() and the reply SOAP Message from the JAX-WS >> >> was got in the Listener. >> >> >> >> This is absolutely fine, the only thing that I need to do is, >> construct >> >> a SOAP Message to invoke the JAX-WS. >> >> But I want to use the JAX-WS Client generated to be able to publish >> the >> >> message to the Local transport. >> >> How can I force/use the JAX-WS client to put the message into the >> Local >> >> transport ? >> >> >> >> Can you please give me an Idea on how to do this for the JAX-WS client >> >> too. >> >> >> >> Regards >> >> Bharath >> >> >> >> dkulp wrote: >> >> > Marcel, >> >> > >> >> >
