Re: CXF-DOSGi passing the OSGi Remote Services and Remote Service Admin CT
> 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: [GSOC] OAuth Resource Owner Authorization implementation
Hi On Mon, Jun 21, 2010 at 11:20 PM, Łukasz Moreń wrote: > Hi, > > I'm going to implement the second OAuth endpoint called: Resource Owner > Authorization. > I will explain briefly this endpoint to make my question more clear. > > Client (third-party app) make request to mentioned endpoint in order to > obtain approval for accessing user (resource owner) resources. > example request uri: > > https://www.server-with-cool-pictures.com/authorize?oauth_token=hh5s93j4hdidpola > > As the response authorization server: > 1. requests user (resource owner) to sign in using his username and > password, > 2. if successful ask user to approve granting client (third-party app) > access to protected resources. > 3. redirect resource owner to client's callback url with unique > verification > code (or display it in case callback url is not provided) > > I am not sure how should this endpoint implementation looks like. It > requires UI to authenticate user and confirm third-party app access, so > some > generic solution is needed. > When client make request on Resource Owner Authorization URI with > oauth_token I can validate that request and redirect to UI login page. > I don't know how after user actions (login and client confirmation), go > back > to my service and redirect to the client (third-party app) callback url > with > generated validation code. > > The client starts from redirecting the end user to the Resource Owner Authorization (ROA) URI . So the endpoint is dealing with ROA URI is having an end user's agent (browser, the client code) awaiting. Now as you said the end user will need to be presented with a consumer/request token authorization form. This form will need to have a URI pointing back to the server, to yet another endpoint, the ROA Confirmation URI so that when the end user presses OK in his browser the server can get the confirmation. Once the server gets the confirmation it will just need to redirect the end user back to the consumer, using the callback URI the consumer provided earlier on, I've been using 303 in my own work but I was looking at the OAuth 2.0 recently and they use 302. You can set this status on the JAXRS Response, and Location header to the callback URI. Hope it helps, Sergey > Any help on that? > > Cheers, > Lukasz Moren >
Re: Endorse jaxws 2.2 API jar
Hi Dan, Looks nice,especially the jaxws 2.2 Providerimpl. Can we also use this profile to publish jaxws2.2 jar with different artifact id into maven repository? Jim On Jun 22, 2010, at 2:20, Daniel Kulp wrote: Jim, I just committed some changes that I think should work for us. Can you give it a look? Basically, in jaxws module, I've separated out the jaxws 2.2 specific stuff into a separate source tree. I've added a "jaxws22" profile that will add the 2.2 stuff into the build and setup the endorsed stuff (for compile only right now, would need to add surefire as well if/when we need it) as well as include a different META-INF/services/... file that points at the 2.2 provider. By default, "mvn install" or whatever will be jaxws 2.1.With - Pjaxws22, it will create the jar with the 2.2 stuff.Since the jaxws22 profile isn't normally active, if you -Psetup.eclipse or intellij or whatever, it will be setup as jaxws 2.1 and the 2.2 stuff won't be visible in eclipse. Thus, normal development won't break. What's good is that the 2.2 Provider will detect if 2.2 api jar is not available and will return the 2.1 Endpoint if not. Thus, it should work fine with 2.1 (non-endorsed) type stuff as well.You can easily test this by building jaxws with -Pjaxws22 and going to the system tests and run them. Since they don't bring in 2.2 at all, and they still run completely fine, it's looking pretty good. Anyway, I would need to update the release profiles to add the jaxws22 profile stuff and I still need to update the distribution to somehow take it into account and create the new jaxws22-endorsed lib dir as well. But I wanted you to look at this so far. Dan On Friday 18 June 2010 11:11:16 am jim ma wrote: Possibly not. It would end up as a classpath ordering issue more than anything else. The 2.2 jar would just need to be in front of the other jar on the classpath or in the classloader.For the distribution, we can easily setup the manifest jar to put the 2.2 jar first, but not put it in lib. To use 2.2, it would just be a matter of copying the jar into lib and the manifest would automatically pick it up first. This can only fix the use case which uses manifest jar to pick up all cxf jars. It does not work for the other projects which explicitly add specific cxf jars to integrate cxf as their web service server . Using the classpath ordering is not easy for other projects embeds cxf to switch jaxws2.2 implementation . Cheers, Jim -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
Re: Endorse jaxws 2.2 API jar
On Tuesday 22 June 2010 9:39:43 am Jim Ma wrote: > Hi Dan, > Looks nice,especially the jaxws 2.2 Providerimpl. Can we also use this > profile to publish jaxws2.2 jar with different artifact id into maven > repository? Shouldn't need a new artifactId or anything. I just need to update hudson to add the -Pjaxws22 profile onto the maven command line. I'll do that now. I may try and see if I can get this to be the default when run from maven, but not when the setup eclipse stuff is done. I'll need to play a bit more. The other thing I'm thinking of trying is when using Java5, make the default be jaxb2.2 and jaxws 2.2 across the board since we don't need to endorse anything. That will probably screw up the kits a bit. Not really sure though. Must play a bit with it. :-) Dan > Jim > > On Jun 22, 2010, at 2:20, Daniel Kulp wrote: > > Jim, > > > > I just committed some changes that I think should work for us. Can > > you give > > it a look? > > > > Basically, in jaxws module, I've separated out the jaxws 2.2 > > specific stuff > > into a separate source tree. I've added a "jaxws22" profile that > > will add > > the 2.2 stuff into the build and setup the endorsed stuff (for > > compile only > > right now, would need to add surefire as well if/when we need it) as > > well as > > include a different META-INF/services/... file that points at the 2.2 > > provider. > > > > By default, "mvn install" or whatever will be jaxws 2.1.With - > > Pjaxws22, > > it will create the jar with the 2.2 stuff.Since the jaxws22 > > profile isn't > > normally active, if you -Psetup.eclipse or intellij or whatever, it > > will be > > setup as jaxws 2.1 and the 2.2 stuff won't be visible in eclipse. > > Thus, > > normal development won't break. > > > > What's good is that the 2.2 Provider will detect if 2.2 api jar is not > > available and will return the 2.1 Endpoint if not. Thus, it should > > work fine > > with 2.1 (non-endorsed) type stuff as well.You can easily test > > this by > > building jaxws with -Pjaxws22 and going to the system tests and run > > them. > > Since they don't bring in 2.2 at all, and they still run completely > > fine, it's > > looking pretty good. > > > > Anyway, I would need to update the release profiles to add the > > jaxws22 profile > > stuff and I still need to update the distribution to somehow take it > > into > > account and create the new jaxws22-endorsed lib dir as well. But I > > wanted > > you to look at this so far. > > > > Dan > > > > On Friday 18 June 2010 11:11:16 am jim ma wrote: > >>> Possibly not. It would end up as a classpath ordering issue more > >>> than > >>> anything else. The 2.2 jar would just need to be in front of the > >>> other > >>> jar on the classpath or in the classloader.For the > >>> distribution, we > >>> can easily setup the manifest jar to put the 2.2 jar first, but > >>> not put > >>> it in lib. To use 2.2, it would just be a matter of copying the > >>> jar > >>> into lib and the manifest would automatically pick it up first. > >> > >> This can only fix the use case which uses manifest jar to pick up > >> all cxf > >> jars. It does not work for the other projects which explicitly add > >> specific cxf jars to > >> integrate cxf as their web service server . Using the classpath > >> ordering is not easy for > >> other projects embeds cxf to switch jaxws2.2 implementation . > >> > >> Cheers, > >> Jim -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
Redirect requests from one server to another server
Hi All, I am using cxf-2.2.7 version. I want to redirect one request from one web services server to another server. I want to thsi redirection on the web services server side. Can any one please help to understand how to do that. I am running my web services servers as stand alone applications ( using jetty server, not using servlets). If some one can point me to the example that would be good. Please help me to resolve this issue. Any help would be really appreciated. Thank you, Naresh.
