You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Holger Stolzenberg <h....@ewerk.com> on 2007/08/24 10:50:58 UTC
Logging the received generated SOAP Messages
What is the easiest way to log the received and generated SOAP messages. Currently I have an incoming/outgoing interceptor with phases receive/send that simply log some properties of the SoapMessage interceptor method param. What I want to log is the raw message data (<soap:envelope> ... </soap:envelope>).
Mit lieben Grüßen aus dem eWerk
| Holger Stolzenberg
| Softwareentwickler
|
| Geschäftsführer:
| Frank Richter, Erik Wende, Hendrik Schubert
|
| eWerk IT GmbH
| Markt 16
| Leipzig 04109
| http://www.ewerk.com
| HRB 9065, AG Leipzig
| Hauptniederlassung Leipzig
|
| fon +49.341.4 26 49-0
| fax +49.341.4 26 49-88
| mailto:h.stolzenberg@ewerk.com
|
| Support:
| fon 0700 CALLME24 (0700 22556324)
| fax 0700 CALLME24 (0700 22556324)
|
| Auskünfte und Angebote per Mail
| sind freibleibend und unverbindlich.
Re: Bus Features [was: Logging ...]
Posted by Sergey Beryozkin <se...@iona.com>.
Hi,
"I wonder can this be done through WS-Policy? I.e., I can make some assertions like this: " I want to apply this feature to endpoint
A and B" or "I want this feature applied to all my endpoints by default if there is no overridden feature defined for the individual
endpoint". Thoughts?"
CXF supports an external WS-Policy attachment mechanism, which should suffice...
It's briefly described here :
http://cwiki.apache.org/CXF20DOC/how-it-works.html
Using this approach you can apply a policy expression to one or more domain expressions, for ex, to EndpointReferences...There's an
rm_external.xml file in a ws_policy system test, it shows how WS-Addresing and WS-RM policies are applied to a given endpoint...
Cheers, Sergey
----- Original Message -----
From: "Liu, Jervis" <jl...@iona.com>
To: <cx...@incubator.apache.org>
Sent: Wednesday, August 29, 2007 7:17 AM
Subject: RE: Bus Features [was: Logging ...]
Hi Fred, I recalled we had a similar discussion before. In your code snippet below, the logging interceptors will be installed
twice. I wont say <cxf:bus> is a root scope configuration as there is no hierarchy relationships among bus, endpoints and bindings.
Bus, endpoints and bindings are just individual components that can contribute interceptors, some times a same bus instance can be
shared by multiple services but this wont necessarily make it a root configuration. Bindings can be shared by multiple services as
well. What you required, "if a feature is defined at endpoint granularity, that feature is the effective feature in config,
whereas if there is no such config at endpoint granularity, the runtime would fall back to the Bus config", is really a scope-based
configuration. This is no such thing existing yet in CXF. I wonder can this be done through WS-Policy? I.e., I can make some
assertions like this: " I want to apply this feature to endpoint A and B" or "I want this feature applied to all my endpoints by
default if there is no overridden feature defined for the individual endpoint". Thoughts?
Jervis
> -----Original Message-----
> From: Fred Dushin [mailto:fred@dushin.net]
> Sent: 2007?8?29? 2:52
> To: cxf-user@incubator.apache.org
> Subject: Bus Features [was: Logging ...]
>
>
>
> On Aug 24, 2007, at 11:36 AM, Daniel Kulp wrote:
>
> > <cxf:bus>
> > <cxf:features>
> > <cxf:logging/>
> > </cxf:features>
> > </cxf:bus>
>
> How do Bus-level features interact with endpoint- or client-level
> features? For example, if I have
>
> {{{
> <cxf:bus>
> <cxf:features>
> <cxf:foo/>
> </cxf:features>
> </cxf:bus>
>
> <jaxws:endpoint name="{http://foo.bar.com}FUBAR">
> <cxf:features>
> <cxf:foo/>
> </cxf:features>
> </jaxws:endpoint>
> }}}
>
> and a servant is instantiated under the WSDL Port
> {http://foo.bar.com}
> FUBAR, is a feature instantiated twice, once for the Bus, qua
> InterceptorProvider, and once for the Endpoint, qua
> InterceptorProvider?
>
> If it's instantiated twice, is there any way a feature
> implementor to
> traverse the interceptors on each InterceptorProvider, to see if a
> feature has been installed, or are these interceptor lists
> independent of one another?
>
> (The reason I ask is, there might be a tendency to think of the
> feature config on the Bus as a kind of default, such that if a
> feature is defined at endpoint granularity, that feature is the
> effective feature in config, whereas if there is no such config at
> endpoint granularity, the runtime would fall back to the Bus
> config.
> But I'm guessing that's really not the behavior here, is it?)
>
> Thanks!
> -Fred
>
----------------------------
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: Bus Features [was: Logging ...]
Posted by "Liu, Jervis" <jl...@iona.com>.
Hi Fred, I recalled we had a similar discussion before. In your code snippet below, the logging interceptors will be installed twice. I wont say <cxf:bus> is a root scope configuration as there is no hierarchy relationships among bus, endpoints and bindings. Bus, endpoints and bindings are just individual components that can contribute interceptors, some times a same bus instance can be shared by multiple services but this wont necessarily make it a root configuration. Bindings can be shared by multiple services as well. What you required, "if a feature is defined at endpoint granularity, that feature is the effective feature in config, whereas if there is no such config at endpoint granularity, the runtime would fall back to the Bus config", is really a scope-based configuration. This is no such thing existing yet in CXF. I wonder can this be done through WS-Policy? I.e., I can make some assertions like this: " I want to apply this feature to endpoint A and B" or "I want this feature applied to all my endpoints by default if there is no overridden feature defined for the individual endpoint". Thoughts?
Jervis
> -----Original Message-----
> From: Fred Dushin [mailto:fred@dushin.net]
> Sent: 2007?8?29? 2:52
> To: cxf-user@incubator.apache.org
> Subject: Bus Features [was: Logging ...]
>
>
>
> On Aug 24, 2007, at 11:36 AM, Daniel Kulp wrote:
>
> > <cxf:bus>
> > <cxf:features>
> > <cxf:logging/>
> > </cxf:features>
> > </cxf:bus>
>
> How do Bus-level features interact with endpoint- or client-level
> features? For example, if I have
>
> {{{
> <cxf:bus>
> <cxf:features>
> <cxf:foo/>
> </cxf:features>
> </cxf:bus>
>
> <jaxws:endpoint name="{http://foo.bar.com}FUBAR">
> <cxf:features>
> <cxf:foo/>
> </cxf:features>
> </jaxws:endpoint>
> }}}
>
> and a servant is instantiated under the WSDL Port
> {http://foo.bar.com}
> FUBAR, is a feature instantiated twice, once for the Bus, qua
> InterceptorProvider, and once for the Endpoint, qua
> InterceptorProvider?
>
> If it's instantiated twice, is there any way a feature
> implementor to
> traverse the interceptors on each InterceptorProvider, to see if a
> feature has been installed, or are these interceptor lists
> independent of one another?
>
> (The reason I ask is, there might be a tendency to think of the
> feature config on the Bus as a kind of default, such that if a
> feature is defined at endpoint granularity, that feature is the
> effective feature in config, whereas if there is no such config at
> endpoint granularity, the runtime would fall back to the Bus
> config.
> But I'm guessing that's really not the behavior here, is it?)
>
> Thanks!
> -Fred
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Bus Features [was: Logging ...]
Posted by Fred Dushin <fr...@dushin.net>.
On Aug 24, 2007, at 11:36 AM, Daniel Kulp wrote:
> <cxf:bus>
> <cxf:features>
> <cxf:logging/>
> </cxf:features>
> </cxf:bus>
How do Bus-level features interact with endpoint- or client-level
features? For example, if I have
{{{
<cxf:bus>
<cxf:features>
<cxf:foo/>
</cxf:features>
</cxf:bus>
<jaxws:endpoint name="{http://foo.bar.com}FUBAR">
<cxf:features>
<cxf:foo/>
</cxf:features>
</jaxws:endpoint>
}}}
and a servant is instantiated under the WSDL Port {http://foo.bar.com}
FUBAR, is a feature instantiated twice, once for the Bus, qua
InterceptorProvider, and once for the Endpoint, qua InterceptorProvider?
If it's instantiated twice, is there any way a feature implementor to
traverse the interceptors on each InterceptorProvider, to see if a
feature has been installed, or are these interceptor lists
independent of one another?
(The reason I ask is, there might be a tendency to think of the
feature config on the Bus as a kind of default, such that if a
feature is defined at endpoint granularity, that feature is the
effective feature in config, whereas if there is no such config at
endpoint granularity, the runtime would fall back to the Bus config.
But I'm guessing that's really not the behavior here, is it?)
Thanks!
-Fred
Re: Logging the received generated SOAP Messages
Posted by Daniel Kulp <dk...@apache.org>.
You can configure it on the bus as well. Via Spring:
<cxf:bus>
<cxf:features>
<cxf:logging/>
</cxf:features>
</cxf:bus>
or you can get the Bus object and do the bus.getInInterceptors().add(...)
calls to add the interceptors manually.
Those interceptors would apply to all the clients and services that the
bus hosts.
Dan
On Friday 24 August 2007, Jacob Marcus wrote:
> Hi,
>
> I have a related question.
>
> Suppose, you have a lot of end points and you want to perform a common
> logging/auditing across all of them. Is there a way you can intercept
> at a higher level than for each service? Something like at the
> ServletDestination level?
>
> This would be useful and a bit more easier than having to set up
> interceptors for each end point?
>
> Thanks,
> Jacob
>
> On 8/24/07, Freeman Fang <fr...@iona.com> wrote:
> > Hi Holger,
> >
> > Actually we have LoggingInInterceptor and LoggingOutInterceptor for
> > that purpose.
> > You can add it two your endpoint on server side
> > EndpointImpl e = (EndpointImpl)Endpoint.publish(address,
> > implementor);
> > e.getServer().getEndpoint().getInInterceptors().add(new
> > LoggingInInterceptor());
> > e.getServer().getEndpoint().getOutInterceptors().add(new
> > LoggingOutInterceptor());
> >
> > For client side, you can do it like
> > HelloPortType port = helloService.getHelloPort();
> > Client client = ClientProxy.getClient(port);
> > client.getInInterceptors().add(new LoggingInInterceptor());
> > client.getInOutterceptors().add(new LoggingOutInterceptor());
> >
> > Also you can configure log features in spring file, you can refer to
> >
> > https://svn.apache.org/repos/asf/incubator/cxf/trunk/distribution/sr
> >c/main/release/samples/wsdl_first/wsdl/cxf-servlet.xml
> >
> > Best Regards
> >
> > Freeman
> >
> > Holger Stolzenberg wrote:
> > > What is the easiest way to log the received and generated SOAP
> > > messages.
> >
> > Currently I have an incoming/outgoing interceptor with phases
> > receive/send that simply log some properties of the SoapMessage
> > interceptor method param. What I want to log is the raw message data
> > (<soap:envelope> ... </soap:envelope>).
> >
> > > Mit lieben Grüßen aus dem eWerk
> > >
> > > | Holger Stolzenberg
> > > | Softwareentwickler
> > > |
> > > | Geschäftsführer:
> > > | Frank Richter, Erik Wende, Hendrik Schubert
> > > |
> > > | eWerk IT GmbH
> > > | Markt 16
> > > | Leipzig 04109
> > > | http://www.ewerk.com
> > > | HRB 9065, AG Leipzig
> > > | Hauptniederlassung Leipzig
> > > |
> > > | fon +49.341.4 26 49-0
> > > | fax +49.341.4 26 49-88
> > > | mailto:h.stolzenberg@ewerk.com
> > > |
> > > | Support:
> > > | fon 0700 CALLME24 (0700 22556324)
> > > | fax 0700 CALLME24 (0700 22556324)
> > > |
> > > | Auskünfte und Angebote per Mail
> > > | sind freibleibend und unverbindlich.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: Logging the received generated SOAP Messages
Posted by Jacob Marcus <ja...@gmail.com>.
Hi,
I have a related question.
Suppose, you have a lot of end points and you want to perform a common
logging/auditing across all of them. Is there a way you can intercept at a
higher level than for each service? Something like at the ServletDestination
level?
This would be useful and a bit more easier than having to set up
interceptors for each end point?
Thanks,
Jacob
On 8/24/07, Freeman Fang <fr...@iona.com> wrote:
>
> Hi Holger,
>
> Actually we have LoggingInInterceptor and LoggingOutInterceptor for that
> purpose.
> You can add it two your endpoint on server side
> EndpointImpl e = (EndpointImpl)Endpoint.publish(address, implementor);
> e.getServer().getEndpoint().getInInterceptors().add(new
> LoggingInInterceptor());
> e.getServer().getEndpoint().getOutInterceptors().add(new
> LoggingOutInterceptor());
>
> For client side, you can do it like
> HelloPortType port = helloService.getHelloPort();
> Client client = ClientProxy.getClient(port);
> client.getInInterceptors().add(new LoggingInInterceptor());
> client.getInOutterceptors().add(new LoggingOutInterceptor());
>
> Also you can configure log features in spring file, you can refer to
>
> https://svn.apache.org/repos/asf/incubator/cxf/trunk/distribution/src/main/release/samples/wsdl_first/wsdl/cxf-servlet.xml
>
> Best Regards
>
> Freeman
>
> Holger Stolzenberg wrote:
> > What is the easiest way to log the received and generated SOAP messages.
> Currently I have an incoming/outgoing interceptor with phases receive/send
> that simply log some properties of the SoapMessage interceptor method param.
> What I want to log is the raw message data (<soap:envelope> ...
> </soap:envelope>).
> >
> > Mit lieben Grüßen aus dem eWerk
> >
> > | Holger Stolzenberg
> > | Softwareentwickler
> > |
> > | Geschäftsführer:
> > | Frank Richter, Erik Wende, Hendrik Schubert
> > |
> > | eWerk IT GmbH
> > | Markt 16
> > | Leipzig 04109
> > | http://www.ewerk.com
> > | HRB 9065, AG Leipzig
> > | Hauptniederlassung Leipzig
> > |
> > | fon +49.341.4 26 49-0
> > | fax +49.341.4 26 49-88
> > | mailto:h.stolzenberg@ewerk.com
> > |
> > | Support:
> > | fon 0700 CALLME24 (0700 22556324)
> > | fax 0700 CALLME24 (0700 22556324)
> > |
> > | Auskünfte und Angebote per Mail
> > | sind freibleibend und unverbindlich.
> >
> >
>
Re: Logging the received generated SOAP Messages
Posted by Freeman Fang <fr...@iona.com>.
Hi Holger,
Actually we have LoggingInInterceptor and LoggingOutInterceptor for that
purpose.
You can add it two your endpoint on server side
EndpointImpl e = (EndpointImpl)Endpoint.publish(address, implementor);
e.getServer().getEndpoint().getInInterceptors().add(new
LoggingInInterceptor());
e.getServer().getEndpoint().getOutInterceptors().add(new
LoggingOutInterceptor());
For client side, you can do it like
HelloPortType port = helloService.getHelloPort();
Client client = ClientProxy.getClient(port);
client.getInInterceptors().add(new LoggingInInterceptor());
client.getInOutterceptors().add(new LoggingOutInterceptor());
Also you can configure log features in spring file, you can refer to
https://svn.apache.org/repos/asf/incubator/cxf/trunk/distribution/src/main/release/samples/wsdl_first/wsdl/cxf-servlet.xml
Best Regards
Freeman
Holger Stolzenberg wrote:
> What is the easiest way to log the received and generated SOAP messages. Currently I have an incoming/outgoing interceptor with phases receive/send that simply log some properties of the SoapMessage interceptor method param. What I want to log is the raw message data (<soap:envelope> ... </soap:envelope>).
>
> Mit lieben Grüßen aus dem eWerk
>
> | Holger Stolzenberg
> | Softwareentwickler
> |
> | Geschäftsführer:
> | Frank Richter, Erik Wende, Hendrik Schubert
> |
> | eWerk IT GmbH
> | Markt 16
> | Leipzig 04109
> | http://www.ewerk.com
> | HRB 9065, AG Leipzig
> | Hauptniederlassung Leipzig
> |
> | fon +49.341.4 26 49-0
> | fax +49.341.4 26 49-88
> | mailto:h.stolzenberg@ewerk.com
> |
> | Support:
> | fon 0700 CALLME24 (0700 22556324)
> | fax 0700 CALLME24 (0700 22556324)
> |
> | Auskünfte und Angebote per Mail
> | sind freibleibend und unverbindlich.
>
>