THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
| unmigrated-inline-wiki-markup |
|---|
{span:style=font-size:2em;font-weight:bold} Debugging and Logging {span} |
| Table of Contents |
|---|
Logging Messages
CXF uses Java SE Logging for both client- and server-side logging of SOAP requests and responses. Logging is activated by use of separate in/out interceptors that can be attached to the client and/or service as required. These interceptors can be specified either programmatically (via Java code and/or annotations) or via use of configuration files.
Configuration files are probably best. They offer two benefits over programmatic configuration:
- Logging requirements can be altered without needing to recompile the code
- No Apache CXF-specific APIs need to be added to your code, which helps it remain interoperable with other JAX-WS compliant web service stacks
Enabling message logging through configuration files is shown here.
For programmatic configuration, the logging interceptors can be added to your service endpoint as follows:
| Code Block |
|---|
{toc} h1. Logging Messages CXF uses [Java SE Logging|http://www.oracle.com/technology/pub/articles/hunter_logging.html] for both client- and server-side logging of SOAP requests and responses. Logging is activated by use of separate in/out interceptors that can be attached to the client and/or service as required. These interceptors can be specified either programmatically (via Java code and/or annotations) or via use of configuration files. Configuration files are probably best. They offer two benefits over programmatic configuration: # Logging requirements can be altered without needing to recompile the code # No Apache CXF-specific APIs need to be added to your code, which helps it remain interoperable with other JAX-WS compliant web service stacks Enabling message logging through configuration files is shown [here|http://cxf.apache.org/docs/configuration.html]. For programmatic configuration, the logging interceptors can be added to your service endpoint as follows: {code} import javax.xml.ws.Endpoint; import org.apache.cxf.interceptor.LoggingInInterceptor; import org.apache.cxf.interceptor.LoggingOutInterceptor; import org.apache.cxf.jaxws.EndpointImpl; Object implementor = new GreeterImpl(); EndpointImpl ep = (EndpointImpl) Endpoint.publish("http://localhost/service", implementor); ep.getServer().getEndpoint().getInInterceptors().add(new LoggingInInterceptor()); ep.getServer().getEndpoint().getOutInterceptors().add(new LoggingOutInterceptor()); {code} For web services running on CXFServlet, the below annotations can be used on either the SEI or the SEI implementation class. If placed on the SEI, they activate logging both for client and server; if on the SEI implementation class, they are relevant just for server-side logging. {code} |
For web services running on CXFServlet, the below annotations can be used on either the SEI or the SEI implementation class. If placed on the SEI, they activate logging both for client and server; if on the SEI implementation class, they are relevant just for server-side logging.
| Code Block |
|---|
import org.apache.cxf.feature.Features;
@javax.jws.WebService(portName = "MyWebServicePort", serviceName = "MyWebService", ...)
@Features(features = "org.apache.cxf.feature.LoggingFeature")
public class MyWebServicePortTypeImpl implements MyWebServicePortType {
{code}
|
or
...
(equivalent)
| Code Block |
|---|
} import org.apache.cxf.interceptor.InInterceptors; import org.apache.cxf.interceptor.OutInterceptors; @javax.jws.WebService(portName = "WebServicePort", serviceName = "WebServiceService", ...) @InInterceptors(interceptors = "org.apache.cxf.interceptor.LoggingInInterceptor") @OutInterceptors(interceptors = "org.apache.cxf.interceptor.LoggingOutInterceptor") public class WebServicePortTypeImpl implements WebServicePortType { {code} For programmatic |
For programmatic client-side
...
logging,
...
the
...
following
...
code
...
snippet
...
can
...
be
...
used
...
as
...
an
...
example:
| Code Block |
|---|
} import org.apache.cxf.endpoint.Client; import org.apache.cxf.frontend.ClientProxy; import org.apache.cxf.interceptor.LoggingInInterceptor; import org.apache.cxf.interceptor.LoggingOutInterceptor; public class WSClient { public static void main (String[] args) { MyService ws = new MyService(); MyPortType port = ws.getPort(); Client client = ClientProxy.getClient(port); client.getInInterceptors().add(new LoggingInInterceptor()); client.getOutInterceptors().add(new LoggingOutInterceptor()); // make WS calls... {code} h2. Configure logging levels. In the [/etc folder|http://svn.apache.org/viewvc/cxf/trunk/distribution/src/main/release/etc/] of the CXF distribution there is a sample Java SE logging.properties file you can use to configure logging. For example, if you want to change the console logging level from WARNING to FINE, you need to update two properties |
Configure logging levels.
In the /etc folder of the CXF distribution there is a sample Java SE logging.properties file you can use to configure logging. For example, if you want to change the console logging level from WARNING to FINE, you need to update two properties in this logging.properties file as below:
| Code Block | ||||
|---|---|---|---|---|
| ||||
in this logging.properties file as below: {code:xml} .level= FINE java.util.logging.ConsoleHandler.level = FINE {code} |
Once
...
this
...
is
...
done,
...
you
...
will
...
need
...
to
...
set
...
the
...
-Djava.util.logging.config.file
...
property
...
to
...
the
...
location
...
of
...
the
...
logging.properties
...
file.
...
As
...
an
...
example,
...
the
...
Ant
...
target
...
below
...
has
...
this
...
property
...
set:
| Code Block | ||||
|---|---|---|---|---|
| ||||
{code:xml} <target name="runClient"> <java classname="client.WSClient" fork="true"> <classpath> <pathelement location="${build.classes.dir}"/> <fileset dir="${env.CXF_HOME}/lib"> <include name="*.jar"/> </fileset> </classpath> <jvmarg value="-Djava.util.logging.config.file=/usr/myclientapp/logging.properties"/> </java> </target> {code} |
Alternatively,
...
for
...
SOAP
...
clients,
...
you
...
can
...
modify
...
the
...
Java-wide
...
logging.properties
...
file
...
in
...
the
...
JDK_HOME/jre/lib
...
folder,
...
or
...
for
...
servlet-hosted
...
web
...
service
...
providers,
...
placing
...
a
...
logging.properties
...
file
...
in
...
the
...
WEB-INF/classes
...
folder
...
(see
...
...
for
...
more
...
details.)
...
Using
...
Log4j
...
Instead
...
of
...
java.util.logging
...
As
...
noted
...
above,
...
CXF
...
uses
...
the
...
java.util.logging
...
package
...
by
...
default.
...
But
...
it
...
is
...
possible
...
to
...
switch
...
CXF
...
to
...
instead
...
use
...
...
.
...
This
...
is
...
achieved
...
through
...
the
...
use
...
of
...
configuration
...
files.
...
There
...
are
...
two
...
options
...
to
...
bootstrapping
...
CXF
...
logging
...
and
...
each
...
is
...
listed
...
below:
...
- Add
...
- the
...
- following
...
- system
...
- property
...
- to
...
- the
...
- classpath
...
- from
...
- which
...
- CXF
...
- is
...
- initialized:
| Code Block |
|---|
{code} -Dorg.apache.cxf.Logger=org.apache.cxf.common.logging.Log4jLogger {code} * Add the file {{ |
- Add the file
META-INF/cxf/org.apache.cxf.Logger
...
- to
...
- the
...
- classpath
...
- and
...
- make
...
- sure
...
- it
...
- contains
...
- the
...
- following
...
- content:
| Code Block |
|---|
{code} org.apache.cxf.common.logging.Log4jLogger {code} h2. Using SLF4J Instead of |
Using SLF4J Instead of java.util.logging
...
(since
...
2.2.8)
...
As
...
noted
...
above,
...
CXF
...
uses
...
the
...
java.util.logging
...
package
...
by
...
default.
...
But
...
it
...
is
...
possible
...
to
...
switch
...
CXF
...
to
...
instead
...
use
...
...
.
...
This
...
is
...
achieved
...
through
...
the
...
use
...
of
...
configuration
...
files.
...
There
...
are
...
two
...
options
...
to
...
bootstrapping
...
CXF
...
logging
...
and
...
each
...
is
...
listed
...
below:
...
- Add
...
- the
...
- following
...
- system
...
- property
...
- to
...
- the
...
- classpath
...
- from
...
- which
...
- CXF
...
- is
...
- initialized:
| Code Block |
|---|
{code} -Dorg.apache.cxf.Logger=org.apache.cxf.common.logging.Slf4jLogger {code} * Add the file {{ |
- Add the file
META-INF/cxf/org.apache.cxf.Logger
...
- to
...
- the
...
- classpath
...
- and
...
- make
...
- sure
...
- it
...
- contains
...
- the
...
- following
...
- content:
| Code Block |
|---|
{code} org.apache.cxf.common.logging.Slf4jLogger {code} h1. Debugging Tools h2. Eclipse IDE See this [blog entry|http://www.jroller.com/gmazza/entry/eclipse_debug_web_services] for information on debugging web services using Eclipse. Note this is primarily for tracing/debugging source code; you will probably still want to use one of the tools below to capture network traffic, view SOAP requests and responses, etc. h2. NetBeans IDE NetBeans include a [debugger|http://www.netbeans.org/features/java/debugger.html], [profiler|http://www.netbeans.org/features/java/profiler.html] and an HTTP monitor that can assist in troubleshooting SOA applications. h2. tcpmon and tcptrace [tcpmon|http://tcpmon.dev.java.net] allows you to easily view messages as they go back and forth on the wire. The companion utility [tcptrace|http://www.tcptrace.org] can be used for analysis of the dump. h2. WSMonitor [WSMonitor|https://wsmonitor.dev.java.net/] in another option to Tcpmon with slightly more functionality. h2. NetSniffer [NetSniffer|http://www.miray.de/products/sat.netsniffer.html] makes it possible to track the network traffic between arbitrary devices within a LAN segment. h2. Wireshark [Wireshark|http://www.wireshark.org/], a network packet analyzer, is useful for following the routing of SOAP messages. It can also help when you are getting an HTML error message from the server that your CXF client cannot normally process, by allowing you to see the non-SOAP error message. See this [blog entry|http://www.jroller.com/gmazza/entry/soap_calls_over_wireshark] for more information. h2. SOAP UI [SOAP UI|http://soapui.org] can also be used for debugging. In addition to viewing messages, it allows |
Debugging Tools
Eclipse IDE
See this blog entry for information on debugging web services using Eclipse. Note this is primarily for tracing/debugging source code; you will probably still want to use one of the tools below to capture network traffic, view SOAP requests and responses, etc.
NetBeans IDE
NetBeans include a debugger, profiler and an HTTP monitor that can assist in troubleshooting SOA applications.
tcpmon and tcptrace
tcpmon allows you to easily view messages as they go back and forth on the wire. The companion utility tcptrace can be used for analysis of the dump.
WSMonitor
WSMonitor in another option to Tcpmon with slightly more functionality.
NetSniffer
NetSniffer makes it possible to track the network traffic between arbitrary devices within a LAN segment.
Wireshark
Wireshark, a network packet analyzer, is useful for following the routing of SOAP messages. It can also help when you are getting an HTML error message from the server that your CXF client cannot normally process, by allowing you to see the non-SOAP error message. See this blog entry for more information.
SOAP UI
SOAP UI can also be used for debugging. In addition to viewing messages, it allows you send messages and load test your services. It also has plugins for the Eclipse IDE, NetBeans IDE and IntelliJ IDEA.
Other Helpful Tools
WSDL Viewer
WSDL Viewer is a small tool to visualize web-services in a more intuitive way.
SOAP Fault for debugging
This feature is available since CXF 2.3.4
Stack trace in fault details
CXF supports the ability to put server stack trace information into the fault message fault details, if you enable the option of 'faultStackTraceEnabled'. It is useful for debugging if the soap fault message is not defined in the WSDL operation.
| Code Block |
|---|
you send messages and load test your services. It also has plugins for the [Eclipse IDE|http://soapui.org/IDE-Plugins/eclipse-plugin.html], [NetBeans IDE|http://www.soapui.org/IDE-Plugins/netbean.html] and [IntelliJ IDEA|http://www.soapui.org/IDE-Plugins/intellij.html]. h1. Other Helpful Tools h2. WSDL Viewer [WSDL Viewer|http://tomi.vanek.sk/index.php?page=wsdl-viewer] is a small tool to visualize web-services in a more intuitive way. h1. SOAP Fault for debugging *This feature is available since CXF 2.3.4* h2. Stack trace in fault details CXF supports the ability to put server stack trace information into the fault message fault details, if you enable the option of 'faultStackTraceEnabled'. It is useful for debugging if the soap fault message is not defined in the WSDL operation. {code} <jaxws:endpoint id="server" address="http://localhost:9002/TestMessage" wsdlURL="ship.wsdl" endpointName="s:TestSoapEndpoint" serviceName="s:TestService" xmlns:s="http://test" > <jaxws:properties> <entry key="faultStackTraceEnabled" value="true" /> </jaxws:properties> </jaxws:endpoint> {code} h2. Showing the cause exception message CXF |
Showing the cause exception message
CXF doesn't
...
show
...
the
...
cause
...
exception
...
message
...
in
...
the
...
fault
...
message
...
due
...
to
...
security
...
consideration.
...
However,
...
this
...
could
...
potentially
...
cause
...
some
...
trouble
...
on
...
the
...
client
...
side,
...
as
...
the
...
client
...
will
...
not
...
be
...
able
...
to
...
see
...
what
...
the
...
real
...
cause
...
of
...
the
...
exception
...
is.
...
You
...
can
...
let
...
the
...
CXF
...
server
...
return
...
the
...
fault
...
message
...
with
...
the
...
embedded
...
cause
...
exception
...
message
...
by
...
enabling
...
the
...
option
...
of
...
'exceptionMessageCauseEnabled'
...
like
...
this:
| Code Block |
|---|
} <jaxws:endpoint id="server" address="http://localhost:9002/TestMessage" wsdlURL="ship.wsdl" endpointName="s:TestSoapEndpoint" serviceName="s:TestService" xmlns:s="http://test" > <jaxws:properties> <entry key="exceptionMessageCauseEnabled" value="true" /> </jaxws:properties> </jaxws:endpoint> {code} h1. ATOM logging *This feature is available since CXF |
ATOM logging
This feature is available since CXF 2.3.0,
...
as
...
part
...
of
...
the
...
cxf-rt-management-web
...
component
...
CXF
...
supports
...
collecting
...
log
...
events,
...
converting
...
them
...
to
...
...
...
...
and
...
either
...
pushing
...
them
...
to
...
the
...
Atom-aware
...
consumers
...
or
...
making
...
them
...
available
...
for
...
polling.
...
Logging
...
is
...
based
...
on
...
a
...
custom
...
java.util.logging
...
(JUL)
...
handler
...
that
...
can
...
be
...
registered
...
with
...
loggers
...
extending
...
today's
...
publishing
...
protocols.
...
CXF
...
JAXRS
...
and
...
JAXWS
...
endpoints
...
can
...
avail
...
of
...
this
...
feature.
...
Push
...
Style
...
Push-style
...
handler
...
enqueues
...
log
...
records
...
as
...
they
...
are
...
published
...
from
...
loggers.
...
After
...
the
...
queue
...
size
...
exceeds
...
configurable
...
"batch
...
size",
...
processing
...
of
...
collection
...
of
...
these
...
records
...
(in
...
size
...
of
...
batch
...
size)
...
is
...
triggered.
...
Batch
...
of
...
log
...
events
...
is
...
transformed
...
by
...
converter
...
to
...
ATOM
...
element
...
and
...
then
...
it
...
is
...
pushed
...
out
...
by
...
deliverer
...
to
...
client.
...
Both
...
converter
...
and
...
deliverer
...
are
...
configurable
...
units
...
that
...
allow
...
to
...
change
...
transformation
...
and
...
transportation
...
strategies.
...
Next
...
to
...
predefined
...
own
...
custom
...
implementations
...
can
...
be
...
used
...
when
...
necessary
...
– see
...
examples.
...
Batches
...
are
...
processed
...
sequentially
...
to
...
allow
...
client
...
side
...
to
...
recreate
...
stream
...
of
...
events.
...
Limitations:
...
Reliability
...
is
...
not
...
supported
...
out
...
of
...
the
...
box,
...
however
...
there
...
is
...
predefined
...
retrying
...
delivery
...
strategy.
...
Persistence
...
is
...
also
...
not
...
supported,
...
any
...
enqueued
...
and
...
undelivered
...
log
...
events
...
are
...
lost
...
on
...
shutdown.
...
Definitions
...
of
...
delivery
...
endpoints
...
is
...
static,
...
subscription
...
of
...
callback
...
URIs
...
is
...
not
...
yet
...
supported.
Spring configuration
In simplest case pushing ATOM Feeds can be declared this way:
| Code Block | ||||
|---|---|---|---|---|
| ||||
h3. Spring configuration In simplest case pushing ATOM Feeds can be declared this way: {code:xml} <bean class="org.apache.cxf.management.web.logging.atom.AtomPushBean" init-method="init"> <property name="url" value="http://somewhere.com/foo/bar"/> <property name="level" value="ALL" /> </bean> {code} |
Spring
...
bean
...
creates
...
ATOM
...
push
...
handler
...
and
...
registers
...
it
...
with
...
root
...
logger
...
for
...
all
...
log
...
levels.
...
This
...
setup
...
leads
...
to
...
logging
...
everything
...
CXF,
...
Spring
...
and
...
others
...
included.
...
Since
...
batch
...
size
...
is
...
not
...
specified
...
default
...
value
...
of
...
one
...
is
...
used
...
-
...
each
...
event
...
is
...
packed
...
up
...
as
...
single
...
feed
...
pushed
...
out
...
to
...
specified
...
URL.
...
Default
...
conversion
...
strategy
...
and
...
default
...
WebClient-based
...
deliver
...
are
...
used.
...
More
...
complex
...
example
...
shows
...
how
...
to
...
specify
...
non-root
...
logger
...
and
...
define
...
batch
...
size:
| Code Block | ||||
|---|---|---|---|---|
| ||||
{code:xml} <bean class="org.apache.cxf.management.web.logging.atom.AtomPushBean" init-method="init"> <property name="url" value="http://somewhere.com/foo/bar"/> <property name="logger" value="org.apache.cxf.jaxrs" /> <property name="level" value="INFO" /> <property name="batchSize" value="10" /> </bean> {code} |
To
...
push
...
to
...
client
...
events
...
generated
...
by
...
different
...
loggers
...
on
...
different
...
levels,
...
"loggers"
...
property
...
must
...
be
...
used
...
instead
...
of
...
pair
...
"logger"
...
and
...
"level":
| Code Block | ||||
|---|---|---|---|---|
| ||||
{code:xml} <bean class="org.apache.cxf.jaxrs.management.web.atom.AtomPushBean" init-method="init"> <property name="url" value="http://somewhere.com/foo/bar"/> <property name="loggers" value=" org.apache.cxf:DEBUG, org.apache.cxf.jaxrs, org.apache.cxf.bus:ERROR, myNamedLogger:INFO" /> </bean> {code} |
In
...
example
...
above,
...
second
...
logger
...
does
...
not
...
have
...
specified
...
level,
...
in
...
such
...
case
...
default
...
level
...
of
...
"INFO"
...
is
...
used.
...
In
...
all
...
above
...
cases,
...
when
...
first
...
delivery
...
fails
...
engine
...
of
...
ATOM
...
push
...
handler
...
is
...
shutdown
...
and
...
no
...
events
...
will
...
be
...
processed
...
and
...
pushed
...
until
...
configuration
...
reload.
...
To
...
avoid
...
this
...
frequent
...
case,
...
retrial
...
can
...
be
...
enabled:
| Code Block | ||||
|---|---|---|---|---|
| ||||
{code:xml} <bean class="org.apache.cxf.management.web.logging.atom.AtomPushBean" init-method="init"> <property name="url" value="http://somewhere.com/foo/bar"/> <property name="logger" value="org.apache.cxf.jaxrs" /> <property name="level" value="INFO" /> <property name="retryPause" value="linear" /> <property name="retryPauseTime" value="60" /> <property name="retryTimeout" value="300" /> </bean> {code} |
In
...
this
...
case
...
for
...
5
...
minutes
...
("retryTimeout")
...
after
...
delivery
...
failure
...
there
...
will
...
be
...
1
...
minute
...
pause
...
("retryPauseTime")
...
repeated
...
every
...
time
...
with
...
same
...
value
...
("retryPause"
...
as
...
"linear").
...
Instead
...
of
...
same
...
pause
...
time,
...
"exponential"
...
value
...
of
...
"retryPause"
...
can
...
be
...
used
...
-
...
each
...
next
...
time
...
pause
...
time
...
doubles.
...
When
...
timeout
...
value
...
is
...
set
...
to
...
0
...
retrying
...
is
...
infinite.
...
In
...
case
...
of
...
invalid
...
or
...
missing
...
values
...
defaults
...
are
...
used:
...
for
...
pause
...
time
...
30
...
seconds
...
and
...
for
...
timeout
...
0
...
(infinite).
...
Instead
...
of
...
same
...
pause
...
time,
...
"exponential"
...
value
...
of
...
"retryPauseType"
...
can
...
be
...
used
...
-
...
each
...
next
...
time
...
pause
...
time
...
doubles.
...
When
...
timeout
...
value
...
is
...
set
...
to
...
0
...
retrying
...
is
...
infinite.
...
In
...
case
...
of
...
invalid
...
or
...
missing
...
values
...
defaults
...
are
...
used:
...
for
...
pause
...
time
...
30
...
seconds
...
and
...
for
...
timeout
...
0
...
(infinite).
...
Ultimate
...
control
...
is
...
given
...
by
...
"converter"
...
and
...
"deliverer"
...
properties.
...
Either
...
beans
...
of
...
predefined
...
or
...
custom
...
classes
...
can
...
be
...
used
...
(see
...
"Programming
...
syle"
...
chapter
...
for
...
more
...
details).
...
Example
...
below
...
shows
...
custom
...
class
...
using
...
different
...
transport
...
protocol
...
than
...
default:
| Code Block | ||||
|---|---|---|---|---|
| ||||
{code:xml} <bean id="soapDeliverer" ... ... <bean class="org.apache.cxf.management.web.logging.atom.AtomPushBean" init-method="init"> <property name="deliverer"> <ref bean="soapDeliverer"/> </property> <property name="loggers" ... /> </bean> {code} |
Note
...
that
...
specifying
...
custom
...
deliverer
...
cause
...
ignoring
...
"url"
...
and
...
"retryXxx"
...
because
...
underneath
...
configuration
...
replaces
...
employed
...
tandem
...
of
...
RetryingDeliverer
...
and
...
WebClientDeliverer
...
with
...
provided
...
one.
...
When
...
ATOM
...
feeds
...
must
...
be
...
delivered
...
to
...
more
...
than
...
one
...
endpoint
...
and
...
additionally
...
each
...
endpoint
...
is
...
fed
...
by
...
different
...
loggers
...
simply
...
use
...
multiple
...
ATOM
...
push
...
beans
...
in
...
Spring
...
config:
| Code Block | ||||
|---|---|---|---|---|
| ||||
{code:xml} <bean id="atom1" class="org.apache.cxf.management.web.logging.atom.AtomPushBean" init-method="init"> <property name="url" value="http://someplace.com/foo/bar"/> ... </bean> <bean id="atom2" class="org.apache.cxf.jaxrs.management.web.atom.AtomPushBean" init-method="init"> <property name="url" value="http://otherplace.com/baz/blah"/> ... </bean> .... {code} h3. Properties file When CXF is used either without Spring or logging is configured with properties file, support for this type of configuration becomes handy. ATOM push handler supports "simple configuration" with properties file; simple means aligned to expressiveness of JUL configuration that is limited to cases, where each type of handler can be used only once and registered with root logger. Set of properties is very similar to Spring configuration with following exceptions: * Properties specify classes of custom deliverers and converters, instead of instances. * Custom deliverer must have public constructor with the only String parameters; created instance will have passed URL of client. * Multiple client endpoints is not supported out of the box (cannot instantiate multiple handlers as in Spring) Example: {code} |
Properties file
When CXF is used either without Spring or logging is configured with properties file, support for this type of configuration becomes handy. ATOM push handler supports "simple configuration" with properties file; simple means aligned to expressiveness of JUL configuration that is limited to cases, where each type of handler can be used only once and registered with root logger.
Set of properties is very similar to Spring configuration with following exceptions:
- Properties specify classes of custom deliverers and converters, instead of instances.
- Custom deliverer must have public constructor with the only String parameters; created instance will have passed URL of client.
- Multiple client endpoints is not supported out of the box (cannot instantiate multiple handlers as in Spring)
Example:
| Code Block |
|---|
handlers = org.apache.cxf.management.web.logging.atom.AtomPushHandler, java.util.logging.ConsoleHandler
.level = INFO
...
org.apache.cxf.jaxrs.ext.management.web.AtomPushHandler.url = http://localhost:9080
org.apache.cxf.jaxrs.ext.management.web.AtomPushHandler.batchSize = 10
org.apache.cxf.jaxrs.ext.management.web.AtomPushHandler.deliverer = WebClientDeliverer
org.apache.cxf.jaxrs.ext.management.web.AtomPushHandler.converter = foo.bar.MyConverter
org.apache.cxf.jaxrs.ext.management.web.AtomPushHandler.retry.pause = linear
org.apache.cxf.jaxrs.ext.management.web.AtomPushHandler.retry.pause.time = 10
org.apache.cxf.jaxrs.ext.management.web.AtomPushHandler.retry.timeout = 360
...
{code}
h3. Programming style
In most complex cases direct programming using {{[ |
Programming style
In most complex cases direct programming using org.apache.cxf.jaxrs.ext
...
.logging.atom package may be necessary. In this case AtomPushHandler class is main artifact and Deliverer and Converter interfaces and their implementations are necessary components.
Following example:
| Code Block |
|---|
org/javadoc/latest/org/apache/cxf/management/web/logging/atom/package-summary.html]}} package may be necessary. In this case AtomPushHandler class is main artifact and Deliverer and Converter interfaces and their implementations are necessary components. Following example: {code} Deliverer d = new WebClientDeliverer("http://somewhere.com/foo/bar"); d = new RetryingDeliverer(d, 300, 60, true); Converter c = new SingleEntryContentConverter(); AtomPushHandler h = new AtomPushHandler(1, c, d); Logger l = Logger.getLogger("org.apache.cxf.jaxrs"); l.setLevel(Level.INFO); l.addHandler(h); {code} |
is
...
equivalent
...
to
...
Spring
...
configuration:
| Code Block |
|---|
} <bean class="org.apache.cxf.management.web.logging.atom.AtomPushBean" init-method="init"> <property name="url" value="http://somewhere.com/foo/bar"/> <property name="logger" value="org.apache.cxf.jaxrs" /> <property name="levellogger" value="INFOorg.apache.cxf.jaxrs" /> <property name="retryPauselevel" value="linearINFO" /> <property name="retryPauseTimeretryPause" value="60linear" /> <property name="retryTimeout" valueretryPauseTime" value="60" /> <property name="retryTimeout" value="300" /> </bean> |
Poll Style
AtomPullServer acts as an Atom feed endpoint and makes all log events it has accumulated or read from some external storage available for polling.
Log events are made available in pages, that is a feed instance will list up to a configurable maximum number of entries and will also include atom links of types 'prev', 'next', 'first' and 'last', thus making it possible to browse through all the log records.
Spring configuration
When configuring AtomPullServer endpoints, one can set the 'loggers' property the same way as it is done for AtomPushBeans, for example :
| Code Block | ||||
|---|---|---|---|---|
| ||||
="300" /> </bean> {code} h2. Poll Style [AtomPullServer|http://svn.apache.org/repos/asf/cxf/trunk/rt/management-web/src/main/java/org/apache/cxf/management/web/logging/atom/AtomPullServer.java] acts as an Atom feed endpoint and makes all log events it has accumulated or read from some external storage available for polling. Log events are made available in pages, that is a feed instance will list up to a configurable maximum number of entries and will also include atom links of types 'prev', 'next', 'first' and 'last', thus making it possible to browse through all the log records. h3. Spring configuration When configuring AtomPullServer endpoints, one can set the 'loggers' property the same way as it is done for AtomPushBeans, for example : {code:xml} <bean class="org.apache.cxf.management.web.logging.atom.AtomPullServer" init-method="init"> <property name="loggers" value=" org.apache.cxf:DEBUG, org.apache.cxf.jaxrs, org.apache.cxf.bus:ERROR, myNamedLogger:INFO" /> <property name="pageSize" value="30"/> </bean> {code} |
In
...
addition
...
to
...
the
...
'loggers'
...
property,
...
a
...
'pageSize'
...
property
...
limiting
...
a
...
number
...
of
...
entries
...
per
...
page
...
to
...
30
...
is
...
also
...
set
...
(default
...
is
...
40).
...
One
...
can
...
have
...
a
...
...
bean
...
injected
...
into
...
AtomPushBean
...
if
...
the
...
log
...
records
...
have
...
to
...
be
...
periodically
...
offloaded
...
from
...
memory
...
and
...
persisted
...
across
...
restarts
...
:
| Code Block | ||||
|---|---|---|---|---|
| ||||
{code:xml} <bean id="storage" class="org.apache.cxf.systest.jaxrs.JAXRSLoggingAtomPullSpringTest$Storage"/> <bean class="org.apache.cxf.management.web.logging.atom.AtomPullServer" init-method="init"> <property name="loggers" value="org.apache.cxf.jaxrs" /> <property name="maxInMemorySize" value="400"/> <property name="storage"> <ref bean="storage"/> </property> </bean> {code} |
When
...
a
...
number
...
of
...
records
...
in
...
memory
...
reaches
...
400
...
(default
...
is
...
500)
...
then
...
the
...
records
...
will
...
be
...
offloaded
...
into
...
a
...
provided
...
storage
...
and
...
will
...
be
...
read
...
from
...
it
...
after
...
the
...
restart
...
or
...
when
...
a
...
client
...
has
...
requested
...
a
...
relevant
...
page.
...
If
...
no
...
storage
...
is
...
available
...
then
...
after
...
an
...
in-memory
...
limit
...
is
...
reached
...
the
...
oldest
...
records
...
will
...
be
...
discarded,
...
one
...
can
...
set
...
a
...
maxInMemorySize
...
property
...
to
...
a
...
large
...
enough
...
value
...
if
...
needed.
...
Another
...
option
...
is
...
to
...
require
...
a
...
given
...
AtomPullServer
...
to
...
read
...
from
...
the
...
external
...
read-only
...
storage
...
by
...
registering
...
a
...
...
bean.
...
For
...
example,
...
very
...
often,
...
the
...
runtime
...
is
...
already
...
logging
...
to
...
some
...
external
...
file,
...
thus
...
AtomPullServer
...
can
...
be
...
asked
...
to
...
read
...
from
...
this
...
file
...
only
...
with
...
the
...
help
...
of
...
ReadableLogStorage,
...
without
...
AtomPullServer
...
having
...
to
...
catch
...
log
...
events
...
too.
...
Once
...
AtomPullServer
...
has
...
been
...
configured,
...
it
...
has
...
to
...
be
...
registered
...
as
...
a
...
service
...
bean
...
with
...
the
...
jaxrs
...
endpoint
...
so
...
that
...
Atom
...
aware
...
clients
...
(blog
...
readers,
...
etc)
...
can
...
start
...
polling
...
it
...
:
| Code Block | ||||
|---|---|---|---|---|
| ||||
{code:xml}
<jaxrs:server id="atomServer" address="/atom">
<jaxrs:serviceBeans>
<ref bean="atomPullServer"/>
</jaxrs:serviceBeans>
<jaxrs:providers>
<ref bean="feed"/>
<ref bean="entry"/>
</jaxrs:providers>
</jaxrs:server>
<bean id="feed" class="org.apache.cxf.jaxrs.provider.AtomFeedProvider"/>
<bean id="entry" class="org.apache.cxf.jaxrs.provider.AtomEntryProvider"/>
|
Linking to Atom endpoints from CXF Services page
If you would like your users to find about the Atom feeds which are collecting log events from your endpoints then AtomPullServers will need to have a CXF bus injected, as well as be told about the address of the corresponding atom feed endpoint and of the jaxrs or jaxws endpoint :
| Code Block | ||||
|---|---|---|---|---|
| ||||
{code} h3. Linking to Atom endpoints from CXF Services page If you would like your users to find about the Atom feeds which are collecting log events from your endpoints then AtomPullServers will need to have a CXF bus injected, as well as be told about the address of the corresponding atom feed endpoint and of the jaxrs or jaxws endpoint : {code:java} <bean id="atomPullServer" class="org.apache.cxf.management.web.logging.atom.AtomPullServer" init-method="init"> <property name="loggers" value="org.apache.cxf.systest.jaxrs.JAXRSLoggingAtomPullSpringTest$Resource:ALL"/> <property name="bus"> <ref bean="cxf"/> </property> <!-- this is a jaxrs:server/@adrress or jaxws:endpoint/@address of the endpoint generating the log events --> <property name="endpointAddress" value="/resource"/> <!-- this is a jaxrs:server/@address of the endpoint for which this atomPullServer bean is registered as a service bean --> <property name="serverAddress" value="/atom"/> </bean> {code} |