You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by easternwahoo <ja...@siemens.com> on 2010/02/25 16:30:07 UTC
How to remove ws-security tokens from message, on provider side?
When using ws-security headers with CXF, it is easy to configure logging
interceptors to log the complete message. Unfortunately, this means the
ws-security headers are displayed in the log. Once we have authenticated
the user's credentials, could we remove the ws-security headers from the
message, and would this solve the problem?
--
View this message in context: http://old.nabble.com/How-to-remove-ws-security-tokens-from-message%2C-on-provider-side--tp27714462p27714462.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: How to remove ws-security tokens from message, on provider
side?
Posted by Glen Mazza <gl...@gmail.com>.
If you can find the CXF source code for the LoggingInterceptor, you can
probably create your own variant of it that does not log the SOAP header
portion. I think that would be a cleaner solution for you.
Glen
easternwahoo wrote:
>
> When using ws-security headers with CXF, it is easy to configure logging
> interceptors to log the complete message. Unfortunately, this means the
> ws-security headers are displayed in the log. Once we have
> authenticated the user's credentials, could we remove the ws-security
> headers from the message, and would this solve the problem?
>
--
View this message in context: http://old.nabble.com/How-to-remove-ws-security-tokens-from-message%2C-on-provider-side--tp27714462p27715162.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: Services provided by DOSGi
Posted by "Clark, Chris" <ch...@hp.com>.
OK, thanks David :-)
I'll do some more reading on those config types then ...
Thanks all for your feedback :-D
Chris Clark
"Audio, Video, Disco"
-----Original Message-----
From: David Bosschaert [mailto:david.bosschaert@gmail.com]
Sent: Monday, March 01, 2010 4:39 PM
To: users@cxf.apache.org
Subject: Re: Services provided by DOSGi
Hi Chris,
Not sure about the learning curve but yeah, the underlying data
binding and protocol are dynamically configured using OSGi Service
Properties. If you put the the following service property on your
service it will use SOAP/HTTP:
service.exported.configs=org.apache.cxf.ws
whereas if you put this one on it will use REST/HTTP:
service.exported.configs=org.apache.cxf.rs
no restarts needed :)
so for any other databinding/protocol that we would support in the
future, it would be a matter of defining a config type for it too.
Best regards,
David
On 27 February 2010 16:16, Clark, Chris <ch...@hp.com> wrote:
> Hi
>
> Thx for the reply :-)
>
> So currently SOAP/HTTP and REST/HTTP is supported, I was just wondering about the learning curve involved to support Hessian/Burlap, which also work over HTTP (sure I saw an article bouncing around the internet about it, but can't remember where I saw it).
>
> One thing I was considering was having the exposures dynamically activated, and preconfigured base URLs (so you could for instance via a config service tell DOSGi to turn on one or more of SOAP/HTTP, Hessian/HTTP, Burlap/HTTP, and REST/HTTP bindings, without any restarts or file editing).
>
> Anything I have missed in the current CXF implementation that might be heading in this direction, or are there some big plans for the future ;-)
> Don't want to be reinventing the wheel (even though I seem to be veering
> towards the realms of ESB solutions)
>
> I'm not too crazy about the support for RMI/JMS/etc..., these were just examples, and probably bad ones to supply because of their nature (not based on HTTP), but I can see you know what I generally mean...
>
> Chris Clark
>
> "Audio, Video, Disco"
>
>
> -----Original Message-----
> From: David Bosschaert [mailto:david.bosschaert@gmail.com]
> Sent: Friday, February 26, 2010 11:28 AM
> To: users@cxf.apache.org
> Subject: Re: Services provided by DOSGi
>
> Hi Chris,
>
> Yes, this should be possible. The idea of using OSGi services and then
> distribute them without having to worry about the protocol is exactly
> what we had in mind when developing DOSGi!
> The CXF-DOSGi implementation currently supports: SOAP/HTTP and
> REST/HTTP. They can be configured by setting the org.apache.cxf.ws or
> org.apache.cxf.rs configuration type. If you don't specify a
> configuration type it defaults to org.apache.cxf.ws (SOAP).
>
> Currently these two are supported, there are people talking about
> supporting JMS as well, but it should be possible to add something
> completely different as well... For more information see:
> http://cxf.apache.org/distributed-osgi-reference.html
>
> Best regards,
>
> David
>
> On 25 February 2010 22:09, Clark, Chris <ch...@hp.com> wrote:
>> Hi there,
>>
>> I was just wondering, after struggling to incorporate CXF DOSGI into a long-running 'playground' project of mine, whether it is possible to use the DOSGI system provided with CXF for other front protocols - so can OSGi services be exposed via Hessian/Burlap/RMI/XML-RPC/etc... using this system.
>>
>> The whole idea that I had was that we had a load of OSGi services, but would like to be able to expose them dynamically, without any worry about the front-end protocol (whether it be SOAP/JSON/XML-RPC/Hessian/whatever).
>>
>> Does CXF DOSGI support this? and is there any documentation about it?
>>
>> Chris Clark
>>
>> "Audio, Video, Disco"
>
Re: Services provided by DOSGi
Posted by David Bosschaert <da...@gmail.com>.
Hi Chris,
Not sure about the learning curve but yeah, the underlying data
binding and protocol are dynamically configured using OSGi Service
Properties. If you put the the following service property on your
service it will use SOAP/HTTP:
service.exported.configs=org.apache.cxf.ws
whereas if you put this one on it will use REST/HTTP:
service.exported.configs=org.apache.cxf.rs
no restarts needed :)
so for any other databinding/protocol that we would support in the
future, it would be a matter of defining a config type for it too.
Best regards,
David
On 27 February 2010 16:16, Clark, Chris <ch...@hp.com> wrote:
> Hi
>
> Thx for the reply :-)
>
> So currently SOAP/HTTP and REST/HTTP is supported, I was just wondering about the learning curve involved to support Hessian/Burlap, which also work over HTTP (sure I saw an article bouncing around the internet about it, but can't remember where I saw it).
>
> One thing I was considering was having the exposures dynamically activated, and preconfigured base URLs (so you could for instance via a config service tell DOSGi to turn on one or more of SOAP/HTTP, Hessian/HTTP, Burlap/HTTP, and REST/HTTP bindings, without any restarts or file editing).
>
> Anything I have missed in the current CXF implementation that might be heading in this direction, or are there some big plans for the future ;-)
> Don't want to be reinventing the wheel (even though I seem to be veering
> towards the realms of ESB solutions)
>
> I'm not too crazy about the support for RMI/JMS/etc..., these were just examples, and probably bad ones to supply because of their nature (not based on HTTP), but I can see you know what I generally mean...
>
> Chris Clark
>
> "Audio, Video, Disco"
>
>
> -----Original Message-----
> From: David Bosschaert [mailto:david.bosschaert@gmail.com]
> Sent: Friday, February 26, 2010 11:28 AM
> To: users@cxf.apache.org
> Subject: Re: Services provided by DOSGi
>
> Hi Chris,
>
> Yes, this should be possible. The idea of using OSGi services and then
> distribute them without having to worry about the protocol is exactly
> what we had in mind when developing DOSGi!
> The CXF-DOSGi implementation currently supports: SOAP/HTTP and
> REST/HTTP. They can be configured by setting the org.apache.cxf.ws or
> org.apache.cxf.rs configuration type. If you don't specify a
> configuration type it defaults to org.apache.cxf.ws (SOAP).
>
> Currently these two are supported, there are people talking about
> supporting JMS as well, but it should be possible to add something
> completely different as well... For more information see:
> http://cxf.apache.org/distributed-osgi-reference.html
>
> Best regards,
>
> David
>
> On 25 February 2010 22:09, Clark, Chris <ch...@hp.com> wrote:
>> Hi there,
>>
>> I was just wondering, after struggling to incorporate CXF DOSGI into a long-running 'playground' project of mine, whether it is possible to use the DOSGI system provided with CXF for other front protocols - so can OSGi services be exposed via Hessian/Burlap/RMI/XML-RPC/etc... using this system.
>>
>> The whole idea that I had was that we had a load of OSGi services, but would like to be able to expose them dynamically, without any worry about the front-end protocol (whether it be SOAP/JSON/XML-RPC/Hessian/whatever).
>>
>> Does CXF DOSGI support this? and is there any documentation about it?
>>
>> Chris Clark
>>
>> "Audio, Video, Disco"
>
RE: Services provided by DOSGi
Posted by "Nist, Todd (IHG)" <To...@ihg.com>.
Hi Chris,
FWIW I think the article(s) you are referring to about Hessian are the following:
http://java.dzone.com/articles/hessian-extender-osgi-containe
http://java.dzone.com/articles/hessian-declarative-extender
http://eclipse.dzone.com/tips/hessian-client-extender
HTH.
Regards,
Todd
-----Original Message-----
From: Clark, Chris [mailto:chris.clark3@hp.com]
Sent: Sat 2/27/2010 11:16 AM
To: users@cxf.apache.org
Subject: RE: Services provided by DOSGi
Hi
Thx for the reply :-)
So currently SOAP/HTTP and REST/HTTP is supported, I was just wondering about the learning curve involved to support Hessian/Burlap, which also work over HTTP (sure I saw an article bouncing around the internet about it, but can't remember where I saw it).
One thing I was considering was having the exposures dynamically activated, and preconfigured base URLs (so you could for instance via a config service tell DOSGi to turn on one or more of SOAP/HTTP, Hessian/HTTP, Burlap/HTTP, and REST/HTTP bindings, without any restarts or file editing).
Anything I have missed in the current CXF implementation that might be heading in this direction, or are there some big plans for the future ;-)
Don't want to be reinventing the wheel (even though I seem to be veering
towards the realms of ESB solutions)
I'm not too crazy about the support for RMI/JMS/etc..., these were just examples, and probably bad ones to supply because of their nature (not based on HTTP), but I can see you know what I generally mean...
Chris Clark
"Audio, Video, Disco"
-----Original Message-----
From: David Bosschaert [mailto:david.bosschaert@gmail.com]
Sent: Friday, February 26, 2010 11:28 AM
To: users@cxf.apache.org
Subject: Re: Services provided by DOSGi
Hi Chris,
Yes, this should be possible. The idea of using OSGi services and then
distribute them without having to worry about the protocol is exactly
what we had in mind when developing DOSGi!
The CXF-DOSGi implementation currently supports: SOAP/HTTP and
REST/HTTP. They can be configured by setting the org.apache.cxf.ws or
org.apache.cxf.rs configuration type. If you don't specify a
configuration type it defaults to org.apache.cxf.ws (SOAP).
Currently these two are supported, there are people talking about
supporting JMS as well, but it should be possible to add something
completely different as well... For more information see:
http://cxf.apache.org/distributed-osgi-reference.html
Best regards,
David
On 25 February 2010 22:09, Clark, Chris <ch...@hp.com> wrote:
> Hi there,
>
> I was just wondering, after struggling to incorporate CXF DOSGI into a long-running 'playground' project of mine, whether it is possible to use the DOSGI system provided with CXF for other front protocols - so can OSGi services be exposed via Hessian/Burlap/RMI/XML-RPC/etc... using this system.
>
> The whole idea that I had was that we had a load of OSGi services, but would like to be able to expose them dynamically, without any worry about the front-end protocol (whether it be SOAP/JSON/XML-RPC/Hessian/whatever).
>
> Does CXF DOSGI support this? and is there any documentation about it?
>
> Chris Clark
>
> "Audio, Video, Disco"
RE: Services provided by DOSGi
Posted by "Clark, Chris" <ch...@hp.com>.
Hi
Thx for the reply :-)
So currently SOAP/HTTP and REST/HTTP is supported, I was just wondering about the learning curve involved to support Hessian/Burlap, which also work over HTTP (sure I saw an article bouncing around the internet about it, but can't remember where I saw it).
One thing I was considering was having the exposures dynamically activated, and preconfigured base URLs (so you could for instance via a config service tell DOSGi to turn on one or more of SOAP/HTTP, Hessian/HTTP, Burlap/HTTP, and REST/HTTP bindings, without any restarts or file editing).
Anything I have missed in the current CXF implementation that might be heading in this direction, or are there some big plans for the future ;-)
Don't want to be reinventing the wheel (even though I seem to be veering
towards the realms of ESB solutions)
I'm not too crazy about the support for RMI/JMS/etc..., these were just examples, and probably bad ones to supply because of their nature (not based on HTTP), but I can see you know what I generally mean...
Chris Clark
"Audio, Video, Disco"
-----Original Message-----
From: David Bosschaert [mailto:david.bosschaert@gmail.com]
Sent: Friday, February 26, 2010 11:28 AM
To: users@cxf.apache.org
Subject: Re: Services provided by DOSGi
Hi Chris,
Yes, this should be possible. The idea of using OSGi services and then
distribute them without having to worry about the protocol is exactly
what we had in mind when developing DOSGi!
The CXF-DOSGi implementation currently supports: SOAP/HTTP and
REST/HTTP. They can be configured by setting the org.apache.cxf.ws or
org.apache.cxf.rs configuration type. If you don't specify a
configuration type it defaults to org.apache.cxf.ws (SOAP).
Currently these two are supported, there are people talking about
supporting JMS as well, but it should be possible to add something
completely different as well... For more information see:
http://cxf.apache.org/distributed-osgi-reference.html
Best regards,
David
On 25 February 2010 22:09, Clark, Chris <ch...@hp.com> wrote:
> Hi there,
>
> I was just wondering, after struggling to incorporate CXF DOSGI into a long-running 'playground' project of mine, whether it is possible to use the DOSGI system provided with CXF for other front protocols - so can OSGi services be exposed via Hessian/Burlap/RMI/XML-RPC/etc... using this system.
>
> The whole idea that I had was that we had a load of OSGi services, but would like to be able to expose them dynamically, without any worry about the front-end protocol (whether it be SOAP/JSON/XML-RPC/Hessian/whatever).
>
> Does CXF DOSGI support this? and is there any documentation about it?
>
> Chris Clark
>
> "Audio, Video, Disco"
Re: Services provided by DOSGi
Posted by Sergey Beryozkin <sb...@progress.com>.
Hi
We'll just need to ensure that DOSGI 1.2 makes it possible to configure jms conduits and destinations for JMS be supported.
The number of supported protocols is bound by CXF to HTTP and JMS. Now to support other possible protocols such as RMI or XML-RPC
etc we have two options to choose from :
- have DOSGI integrated into higher-level container which support RMI/etc
- have DSW refactored such that CXF could act as a default discoverable engine but also for users be able to plug in whatever other
implementation they need.
I'd favor the 2nd approach
Sergey
----- Original Message -----
From: "David Bosschaert" <da...@gmail.com>
To: <us...@cxf.apache.org>
Sent: Friday, February 26, 2010 10:28 AM
Subject: Re: Services provided by DOSGi
Hi Chris,
Yes, this should be possible. The idea of using OSGi services and then
distribute them without having to worry about the protocol is exactly
what we had in mind when developing DOSGi!
The CXF-DOSGi implementation currently supports: SOAP/HTTP and
REST/HTTP. They can be configured by setting the org.apache.cxf.ws or
org.apache.cxf.rs configuration type. If you don't specify a
configuration type it defaults to org.apache.cxf.ws (SOAP).
Currently these two are supported, there are people talking about
supporting JMS as well, but it should be possible to add something
completely different as well... For more information see:
http://cxf.apache.org/distributed-osgi-reference.html
Best regards,
David
On 25 February 2010 22:09, Clark, Chris <ch...@hp.com> wrote:
> Hi there,
>
> I was just wondering, after struggling to incorporate CXF DOSGI into a long-running 'playground' project of mine, whether it is
> possible to use the DOSGI system provided with CXF for other front protocols - so can OSGi services be exposed via
> Hessian/Burlap/RMI/XML-RPC/etc... using this system.
>
> The whole idea that I had was that we had a load of OSGi services, but would like to be able to expose them dynamically, without
> any worry about the front-end protocol (whether it be SOAP/JSON/XML-RPC/Hessian/whatever).
>
> Does CXF DOSGI support this? and is there any documentation about it?
>
> Chris Clark
>
> "Audio, Video, Disco"
Re: Services provided by DOSGi
Posted by David Bosschaert <da...@gmail.com>.
Hi Chris,
Yes, this should be possible. The idea of using OSGi services and then
distribute them without having to worry about the protocol is exactly
what we had in mind when developing DOSGi!
The CXF-DOSGi implementation currently supports: SOAP/HTTP and
REST/HTTP. They can be configured by setting the org.apache.cxf.ws or
org.apache.cxf.rs configuration type. If you don't specify a
configuration type it defaults to org.apache.cxf.ws (SOAP).
Currently these two are supported, there are people talking about
supporting JMS as well, but it should be possible to add something
completely different as well... For more information see:
http://cxf.apache.org/distributed-osgi-reference.html
Best regards,
David
On 25 February 2010 22:09, Clark, Chris <ch...@hp.com> wrote:
> Hi there,
>
> I was just wondering, after struggling to incorporate CXF DOSGI into a long-running 'playground' project of mine, whether it is possible to use the DOSGI system provided with CXF for other front protocols - so can OSGi services be exposed via Hessian/Burlap/RMI/XML-RPC/etc... using this system.
>
> The whole idea that I had was that we had a load of OSGi services, but would like to be able to expose them dynamically, without any worry about the front-end protocol (whether it be SOAP/JSON/XML-RPC/Hessian/whatever).
>
> Does CXF DOSGI support this? and is there any documentation about it?
>
> Chris Clark
>
> "Audio, Video, Disco"
Services provided by DOSGi
Posted by "Clark, Chris" <ch...@hp.com>.
Hi there,
I was just wondering, after struggling to incorporate CXF DOSGI into a long-running 'playground' project of mine, whether it is possible to use the DOSGI system provided with CXF for other front protocols - so can OSGi services be exposed via Hessian/Burlap/RMI/XML-RPC/etc... using this system.
The whole idea that I had was that we had a load of OSGi services, but would like to be able to expose them dynamically, without any worry about the front-end protocol (whether it be SOAP/JSON/XML-RPC/Hessian/whatever).
Does CXF DOSGI support this? and is there any documentation about it?
Chris Clark
"Audio, Video, Disco"
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org]
Sent: Thursday, February 25, 2010 10:51 PM
To: users@cxf.apache.org
Cc: easternwahoo
Subject: Re: How to remove ws-security tokens from message, on provider side?
On Thu February 25 2010 10:30:07 am easternwahoo wrote:
> When using ws-security headers with CXF, it is easy to configure logging
> interceptors to log the complete message. Unfortunately, this means the
> ws-security headers are displayed in the log. Once we have
> authenticated the user's credentials, could we remove the ws-security
> headers from the message, and would this solve the problem?
You would need to write a "different" set of logging interceptors, but that's
probably not a big deal. The current logging interceptors operate at the
stream level which is way before any processing is done. Since the security
stuff operates on an SAAJ model, this wouldn't be too hard. You could write
an interceptor that lives immediately after the WSS4JInInterceptor stuff,
grabs the SAAJ object from the message, pulls off the Security header, and
then calls saaj.writeTo(...) or similar to have it write itself to a log. Not
a huge amount of work.
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: How to remove ws-security tokens from message, on provider side?
Posted by Daniel Kulp <dk...@apache.org>.
On Thu February 25 2010 10:30:07 am easternwahoo wrote:
> When using ws-security headers with CXF, it is easy to configure logging
> interceptors to log the complete message. Unfortunately, this means the
> ws-security headers are displayed in the log. Once we have
> authenticated the user's credentials, could we remove the ws-security
> headers from the message, and would this solve the problem?
You would need to write a "different" set of logging interceptors, but that's
probably not a big deal. The current logging interceptors operate at the
stream level which is way before any processing is done. Since the security
stuff operates on an SAAJ model, this wouldn't be too hard. You could write
an interceptor that lives immediately after the WSS4JInInterceptor stuff,
grabs the SAAJ object from the message, pulls off the Security header, and
then calls saaj.writeTo(...) or similar to have it write itself to a log. Not
a huge amount of work.
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog