Re: SOAP Monitoring console for CXF
Looks good to me. :-)
Dan
On Thu February 4 2010 5:57:20 am Sergey Beryozkin wrote:
> Hi Rémi
>
> Thanks...
> Does anyone has any objections to committing the Rémi's patch ?
>
> IMHO it makes sense to have 'helper' interceptors for users be able to
> persist exchange details and kind of 'break free' from JMX, as far as the
> management is concerned. I've nothing against JMX , it is just about
> giving the users an extra choice...Next, we can try to do something in
> rt/management-web for CXF to provide a simple but useful OTB management
> console.
>
> Thoughts ? Objections ?
> Sergey
>
> > Hi,
> >
> > Ok, CXF-2641 updated with a new patch, I hope this time everything is OK
> > :)
> >
> > - Exchange has been renamed to ExchangeData.
> > - ExchangeDAO has been renamed to ExchangeDataDAO and contains only the
> > save() method. - Statistics has been removed.
> > - It gets the service and operation name the way
> > AbstractMessageResponseTimeInterceptor does (but it doesn't add the "
> > around).
> >
> > Regards,
> > Rémi.
> >
> >> Hi R�mi
> >>
> >>> Hi,
> >>>
> >>> I've updated CXF-2641 with a new patch (which can be applied to the
> >>> 2.2.x branch or to the trunk) so that maven dependencies don't need to
> >>> be changed.
> >>
> >> thanks for your effort. I hope you agree the code is getting much better
> >> now. Some more comments :
> >>
> >> - can you update ExchangeDAO to have save() method only ? All other
> >> methods have to do with managing/viewing/searching the
> >> previously persisted exchanges which is not what PersistsIn/Out
> >> interceptors are interested in. Instead we can have a CXF JAXRS
> >> endpoint (see below) in rt/management-web implementing an interface to
> >> do with searching the exchanges.
> >>
> >> - please remove Statistics class, we can introduce it later on, when
> >> working on exposing exchanges over the web. Now, I'm also
> >> thinking that may be we can ensure it can keep the data accumulated in
> >> JMX beans too...
> >>
> >> - I appreciate you'd like to have a SOAP monitoring console but can you
> >> please get the service and operation name the way
> >> AbstractMessageResponseTimeInterceptor does ? This way JAXRS exchanges
> >> will also be properly populated.
> >>
> >>
> >> - should Exchange be a JAXB bean ? (we can worry about it later though).
> >> Should it be renamed ? Say ExchangeData or similar ? It is
> >> just CXF also has Exchange
> >>
> >>> Basically I've removed all the spring-orm/ibatis part and I've added a
> >>> simple implementation of ExchangeDAO which logs to text files.
> >>
> >> I was about to tell you that we can decide later on, when working on
> >> rt/management-web, how exactly the exchanges can be persisted
> >> and how to build the views. Perhaps, by default we can reuse the file
> >> based storage. I'd be keen on relying on xslt to have a bunch
> >> of prepaired html templates merged with XML data (say with the JAXB
> >> serialized Statistics) for nice views be created. May be we can
> >> introduce some other light deps, GWT may be ?
> >>
> >>> Then if I need to log in a database I can use my ibatis implementation
> >>> by changing the spring configuration.
> >>
> >> exactly
> >>
> >>> I'm not familiar at all with OSGI or JAX-RS, so I can't give you any
> >>> thought on this part yet :)
> >>
> >> CXF JAXRS endpoint will just act as a simple controller. It won't matter
> >> it is SOAP or plain XML exchanges which are being
> >> viewed/managed...Please see :
> >> http://cwiki.apache.org/CXF20DOC/jax-rs.html
> >>
> >> ex, you might have :
> >>
> >> @Path("/exchanges")
> >> public class Controller {
> >>
> >>@GET @Path("/stats")
> >>@Produces(text/xml, application/xml)
> >>public Statistics getStats() {
> >>// let JAXB serialize it and then the XSLTProvider will put it
> >> into a nice view return exchangeDaoReader.getStatistics();
> >>}
> >>...
> >> }
> >>
> >> cheers, Sergey
>
--
Daniel Kulp
dk...@apache.org
http://www.dankulp.com/blog
Re: SOAP Monitoring console for CXF
Hi Rémi
Thanks...
Does anyone has any objections to committing the Rémi's patch ?
IMHO it makes sense to have 'helper' interceptors for users be able to persist exchange details and kind of 'break free' from JMX,
as far as the management is concerned. I've nothing against JMX , it is just about giving the users an extra choice...Next, we can
try to do something in rt/management-web for CXF to provide a simple but useful OTB management console.
Thoughts ? Objections ?
Sergey
Hi,
Ok, CXF-2641 updated with a new patch, I hope this time everything is OK :)
- Exchange has been renamed to ExchangeData.
- ExchangeDAO has been renamed to ExchangeDataDAO and contains only the save()
method.
- Statistics has been removed.
- It gets the service and operation name the way
AbstractMessageResponseTimeInterceptor does (but it doesn't add the " around).
Regards,
Rémi.
Hi R�mi
Hi,
I've updated CXF-2641 with a new patch (which can be applied to the
2.2.x branch or to the trunk) so that maven dependencies don't need to
be changed.
thanks for your effort. I hope you agree the code is getting much better now.
Some more comments :
- can you update ExchangeDAO to have save() method only ? All other methods
have to do with
managing/viewing/searching the
previously persisted exchanges which is not what PersistsIn/Out interceptors
are interested
in. Instead we can have a CXF JAXRS
endpoint (see below) in rt/management-web implementing an interface to do with
searching the
exchanges.
- please remove Statistics class, we can introduce it later on, when working on
exposing exchanges
over the web. Now, I'm also
thinking that may be we can ensure it can keep the data accumulated in JMX
beans too...
- I appreciate you'd like to have a SOAP monitoring console but can you please
get the service
and operation name the way
AbstractMessageResponseTimeInterceptor does ? This way JAXRS exchanges will
also be properly
populated.
- should Exchange be a JAXB bean ? (we can worry about it later though). Should
it be renamed
? Say ExchangeData or similar ? It is
just CXF also has Exchange
Basically I've removed all the spring-orm/ibatis part and I've added a
simple implementation of ExchangeDAO which logs to text files.
I was about to tell you that we can decide later on, when working on
rt/management-web, how
exactly the exchanges can be persisted
and how to build the views. Perhaps, by default we can reuse the file based
storage. I'd be
keen on relying on xslt to have a bunch
of prepaired html templates merged with XML data (say with the JAXB serialized
Statistics)
for nice views be created. May be we can
introduce some other light deps, GWT may be ?
Then if I need to log in a database I can use my ibatis implementation
by changing the spring configuration.
exactly
I'm not familiar at all with OSGI or JAX-RS, so I can't give you any
thought on this part yet :)
CXF JAXRS endpoint will just act as a simple controller. It won't matter it is
SOAP or plain
XML exchanges which are being
viewed/managed...Please see :
http://cwiki.apache.org/CXF20DOC/jax-rs.html
ex, you might have :
@Path("/exchanges")
public class Controller {
@GET @Path("/stats")
@Produces(text/xml, application/xml)
public Statistics getStats() {
// let JAXB serialize it and then the XSLTProvider will put it into a
nice view
return exchangeDaoReader.getStatistics();
}
...
}
cheers, Sergey
Re: SOAP Monitoring console for CXF
Hi,
Ok, CXF-2641 updated with a new patch, I hope this time everything is OK :)
- Exchange has been renamed to ExchangeData.
- ExchangeDAO has been renamed to ExchangeDataDAO and contains only the
save() method.
- Statistics has been removed.
- It gets the service and operation name the way
AbstractMessageResponseTimeInterceptor does (but it doesn't add the "
around).
Regards,
Rémi.
Hi R�mi
Hi,
I've updated CXF-2641 with a new patch (which can be applied to the
2.2.x branch or to the trunk) so that maven dependencies don't need to
be changed.
thanks for your effort. I hope you agree the code is getting much
better now.
Some more comments :
- can you update ExchangeDAO to have save() method only ? All other
methods have to do with
managing/viewing/searching the
previously persisted exchanges which is not what PersistsIn/Out
interceptors are interested
in. Instead we can have a CXF JAXRS
endpoint (see below) in rt/management-web implementing an interface to
do with searching the
exchanges.
- please remove Statistics class, we can introduce it later on, when
working on exposing exchanges
over the web. Now, I'm also
thinking that may be we can ensure it can keep the data accumulated in
JMX beans too...
- I appreciate you'd like to have a SOAP monitoring console but can
you please get the service
and operation name the way
AbstractMessageResponseTimeInterceptor does ? This way JAXRS exchanges
will also be properly
populated.
- should Exchange be a JAXB bean ? (we can worry about it later
though). Should it be renamed
? Say ExchangeData or similar ? It is
just CXF also has Exchange
Basically I've removed all the spring-orm/ibatis part and I've added a
simple implementation of ExchangeDAO which logs to text files.
I was about to tell you that we can decide later on, when working on
rt/management-web, how
exactly the exchanges can be persisted
and how to build the views. Perhaps, by default we can reuse the file
based storage. I'd be
keen on relying on xslt to have a bunch
of prepaired html templates merged with XML data (say with the JAXB
serialized Statistics)
for nice views be created. May be we can
introduce some other light deps, GWT may be ?
Then if I need to log in a database I can use my ibatis implementation
by changing the spring configuration.
exactly
I'm not familiar at all with OSGI or JAX-RS, so I can't give you any
thought on this part yet :)
CXF JAXRS endpoint will just act as a simple controller. It won't
matter it is SOAP or plain
XML exchanges which are being
viewed/managed...Please see :
http://cwiki.apache.org/CXF20DOC/jax-rs.html
ex, you might have :
@Path("/exchanges")
public class Controller {
@GET @Path("/stats")
@Produces(text/xml, application/xml)
public Statistics getStats() {
// let JAXB serialize it and then the XSLTProvider will put it
into a nice view
return exchangeDaoReader.getStatistics();
}
...
}
cheers, Sergey
Re: SOAP Monitoring console for CXF
Hi Rémi
Hi,
I've updated CXF-2641 with a new patch (which can be applied to the
2.2.x branch or to the trunk) so that maven dependencies don't need to
be changed.
thanks for your effort. I hope you agree the code is getting much better now.
Some more comments :
- can you update ExchangeDAO to have save() method only ? All other methods have to do with managing/viewing/searching the
previously persisted exchanges which is not what PersistsIn/Out interceptors are interested in. Instead we can have a CXF JAXRS
endpoint (see below) in rt/management-web implementing an interface to do with searching the exchanges.
- please remove Statistics class, we can introduce it later on, when working on exposing exchanges over the web. Now, I'm also
thinking that may be we can ensure it can keep the data accumulated in JMX beans too...
- I appreciate you'd like to have a SOAP monitoring console but can you please
get the service and operation name the way
AbstractMessageResponseTimeInterceptor does ? This way JAXRS exchanges will
also be properly populated.
- should Exchange be a JAXB bean ? (we can worry about it later though). Should it be renamed ? Say ExchangeData or similar ? It is
just CXF also has Exchange
Basically I've removed all the spring-orm/ibatis part and I've added a
simple implementation of ExchangeDAO which logs to text files.
I was about to tell you that we can decide later on, when working on rt/management-web, how exactly the exchanges can be persisted
and how to build the views. Perhaps, by default we can reuse the file based storage. I'd be keen on relying on xslt to have a bunch
of prepaired html templates merged with XML data (say with the JAXB serialized Statistics) for nice views be created. May be we can
introduce some other light deps, GWT may be ?
Then if I need to log in a database I can use my ibatis implementation
by changing the spring configuration.
exactly
I'm not familiar at all with OSGI or JAX-RS, so I can't give you any
thought on this part yet :)
CXF JAXRS endpoint will just act as a simple controller. It won't matter it is SOAP or plain XML exchanges which are being
viewed/managed...Please see :
http://cwiki.apache.org/CXF20DOC/jax-rs.html
ex, you might have :
@Path("/exchanges")
public class Controller {
@GET @Path("/stats")
@Produces(text/xml, application/xml)
public Statistics getStats() {
// let JAXB serialize it and then the XSLTProvider will put it into a
nice view
return exchangeDaoReader.getStatistics();
}
...
}
cheers, Sergey
Regards,
Rémi.
Hi
Hi,
I have submitted the interceptor part as a patch in jira :
https://issues.apache.org/jira/browse/CXF-2641.
thanks. Personally, I'm not sure we can commit it just yet. The
existing response time management
feature is a light weight
component whose goal is to collect some operation statistics and
eventually expose it over
JMX. The idea of persisting exchanges and
ultimately showing them without JMX being involved seems to be
generally useful, but there
are quite a few depedencies/details in
the patch which would require users of the in/out persistence
interceptors to stick to specific
technologies like spring orm, etc,
but they may just want to save exchanges into a text file or push them
over a socket/http.
IMHO it would be useful to have persistence interceptors added to the
management feature but
it would be better to abstract away the
details of how a current exchange can be persisted. Example, I'd only
add say 2 interceptors
(in/out) plus, say, some simple
interface which can be used to save an exchange.
Next, we can have a demo showing one way (as shown in the patch) how
the exchanges can be
persisted.
I also have a question regarding the rt/management-web module : the
packaging is "jar"
in the pom.xml. Does it mean this is a
library that should be included by users in their own webapp or
should the packaging
be "war" instead ?
It will be a jar, but ultimately it will become a 'bundle' which is a
jar with its manifest
updated with few extra OSGI
instructions.
If this module is intended to be the management webapp, is it OK to
add spring-webmvc
dependency in it ?
The idea behind introducing this module is to let users do a number of
useful management-related
tasks over HTTP, by relying on the
existing CXF modules and technologies already available in JDK. Ex,
CXF JAXRS module can be
used to create various endpoints (one
will be used to let users subscribe to atom logging events, the other
one will actually let
users view the statisics amd possibly do
spme management operations, etc). I'd prefer to have a JAXRS endpoint
which could be used
to show the statistics and possibly the
exchanges persisted by various CXF 'working' endpoints.
Thoughts ?
thanks, Sergey
Re: SOAP Monitoring console for CXF
Hi,
I've updated CXF-2641 with a new patch (which can be applied to the
2.2.x branch or to the trunk) so that maven dependencies don't need to
be changed.
Basically I've removed all the spring-orm/ibatis part and I've added a
simple implementation of ExchangeDAO which logs to text files.
Then if I need to log in a database I can use my ibatis implementation
by changing the spring configuration.
I'm not familiar at all with OSGI or JAX-RS, so I can't give you any
thought on this part yet :)
Regards,
Rémi.
Hi
Hi,
I have submitted the interceptor part as a patch in jira :
https://issues.apache.org/jira/browse/CXF-2641.
thanks. Personally, I'm not sure we can commit it just yet. The
existing response time management
feature is a light weight
component whose goal is to collect some operation statistics and
eventually expose it over
JMX. The idea of persisting exchanges and
ultimately showing them without JMX being involved seems to be
generally useful, but there
are quite a few depedencies/details in
the patch which would require users of the in/out persistence
interceptors to stick to specific
technologies like spring orm, etc,
but they may just want to save exchanges into a text file or push them
over a socket/http.
IMHO it would be useful to have persistence interceptors added to the
management feature but
it would be better to abstract away the
details of how a current exchange can be persisted. Example, I'd only
add say 2 interceptors
(in/out) plus, say, some simple
interface which can be used to save an exchange.
Next, we can have a demo showing one way (as shown in the patch) how
the exchanges can be
persisted.
I also have a question regarding the rt/management-web module : the
packaging is "jar"
in the pom.xml. Does it mean this is a
library that should be included by users in their own webapp or
should the packaging
be "war" instead ?
It will be a jar, but ultimately it will become a 'bundle' which is a
jar with its manifest
updated with few extra OSGI
instructions.
If this module is intended to be the management webapp, is it OK to
add spring-webmvc
dependency in it ?
The idea behind introducing this module is to let users do a number of
useful management-related
tasks over HTTP, by relying on the
existing CXF modules and technologies already available in JDK. Ex,
CXF JAXRS module can be
used to create various endpoints (one
will be used to let users subscribe to atom logging events, the other
one will actually let
users view the statisics amd possibly do
spme management operations, etc). I'd prefer to have a JAXRS endpoint
which could be used
to show the statistics and possibly the
exchanges persisted by various CXF 'working' endpoints.
Thoughts ?
thanks, Sergey
Index:
rt/management/src/main/java/org/apache/cxf/management/persistence/Exchange.java
===
---
rt/management/src/main/java/org/apache/cxf/management/persistence/Exchange.java
(révision 0)
+++
rt/management/src/main/java/org/apache/cxf/management/persistence/Exchange.java
(révision 0)
@@ -0,0 +1,186 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.cxf.management.persistence;
+
+import java.util.Date;
+import java.util.List;
+
+public class Exchange {
+
+private String encoding;
+
+private String exceptionType;
+
+private Integer id;
+
+private Date inDate;
+
+private String operation;
+
+private Date outDate;
+
+private List properties;
+
+private String request;
+
+private Integer requestSize;
+
+private String response;
+
+private Integer responseSize;
+
+private String serviceName;
+
+private String stackTrace;
+
+private String status;
+
+private String uri;
+
+private String userAgent;
+
+public String getEncoding() {
+return this.encoding;
+}
+
+public String getExceptionType() {
+return this.exceptionType;
+}
+
+public Integer getId() {
+return this.id;
+}
+
+public Date getInDate() {
+return this.inDate;
+}
+
+public String getOperation() {
+return this.operation;
+
Re: SOAP Monitoring console for CXF
Hi Hi, I have submitted the interceptor part as a patch in jira : https://issues.apache.org/jira/browse/CXF-2641. thanks. Personally, I'm not sure we can commit it just yet. The existing response time management feature is a light weight component whose goal is to collect some operation statistics and eventually expose it over JMX. The idea of persisting exchanges and ultimately showing them without JMX being involved seems to be generally useful, but there are quite a few depedencies/details in the patch which would require users of the in/out persistence interceptors to stick to specific technologies like spring orm, etc, but they may just want to save exchanges into a text file or push them over a socket/http. IMHO it would be useful to have persistence interceptors added to the management feature but it would be better to abstract away the details of how a current exchange can be persisted. Example, I'd only add say 2 interceptors (in/out) plus, say, some simple interface which can be used to save an exchange. Next, we can have a demo showing one way (as shown in the patch) how the exchanges can be persisted. I also have a question regarding the rt/management-web module : the packaging is "jar" in the pom.xml. Does it mean this is a library that should be included by users in their own webapp or should the packaging be "war" instead ? It will be a jar, but ultimately it will become a 'bundle' which is a jar with its manifest updated with few extra OSGI instructions. If this module is intended to be the management webapp, is it OK to add spring-webmvc dependency in it ? The idea behind introducing this module is to let users do a number of useful management-related tasks over HTTP, by relying on the existing CXF modules and technologies already available in JDK. Ex, CXF JAXRS module can be used to create various endpoints (one will be used to let users subscribe to atom logging events, the other one will actually let users view the statisics amd possibly do spme management operations, etc). I'd prefer to have a JAXRS endpoint which could be used to show the statistics and possibly the exchanges persisted by various CXF 'working' endpoints. Thoughts ? thanks, Sergey Thanks, Rémi. Hi Hi, I wrote a soap monitoring tool for cxf and I'd like to make it open source. I'd like to know if it could be included in cxf package since I think it could be useful to other cxf users. Basically it's just two soap interceptors that store requests, responses and some more data in a database. Additional data is the service name, the operation name, the exception type and the stacktrace if the response is a fault, the response time, the status, the user agent, the encoding, http headers, etc. It also provides a mechanism so users can store their own additional data if they need to. What is your opinion about contributing some of this code to the rt/management module ? Cyrille and other experts can help. The rt/management conrtains a management featire which can be used to monitor both SOAP and RESTful services. And it looks like it can do most of what you've described above but perhaps you can help enhancing it for it to match what your interceptors can do ? The cxf console comes with 3 maven modules : - cxf-soap-console-dao : used for CRUD operation in database, use iBatis. MySQL is supported, I'll add Oracle and Postgres support soon since I need it, I might also add derby support. - cxf-soap-console-interceptors : the soap interceptors that users need to add to their webservices. They are basically extended versions of LoggingInterceptors from cxf. - cxf-soap-console-webapp : a webapp to show data stored by the interceptors (see attached screenshots) It is still in an alpha stage, here are some planned features ; - statistics by service - statistics by operation - jfreechart inclusion in the webapp - a search form - make it a cxf feature This is quite interesting. You may've seen we've discussed the possibility of introducing a rt/management-web module which will initially contain : - atom based pull/push logging support for individual jaxrs/jaxrs endpoints (thsi code is currently in CXF JAX-RS) with the eventual possibility to subscribe or register callback URIs from CXF /services page - CXF JAX-RS based endpoint for showing JMX-based data over HTTP for all CXF endpoints and providing more advanced management capabilities over time I hope this component will eventually turn CXF itself into a well-featured Web application on its own. We'll need to complete some intial support for the Atom pull logging stuff (nearly there) and then I will do the move. It looks like what you've done may be eventually added to this new CXF module. Others may have a different opinion though... cheers, Sergey I've attached the source code, some screenshots, and the ddl script to create the database. Maven should generate a war deployable in
Re: SOAP Monitoring console for CXF
Hi, I have submitted the interceptor part as a patch in jira : https://issues.apache.org/jira/browse/CXF-2641. I also have a question regarding the rt/management-web module : the packaging is "jar" in the pom.xml. Does it mean this is a library that should be included by users in their own webapp or should the packaging be "war" instead ? If this module is intended to be the management webapp, is it OK to add spring-webmvc dependency in it ? Thanks, Rémi. Hi Hi, I wrote a soap monitoring tool for cxf and I'd like to make it open source. I'd like to know if it could be included in cxf package since I think it could be useful to other cxf users. Basically it's just two soap interceptors that store requests, responses and some more data in a database. Additional data is the service name, the operation name, the exception type and the stacktrace if the response is a fault, the response time, the status, the user agent, the encoding, http headers, etc. It also provides a mechanism so users can store their own additional data if they need to. What is your opinion about contributing some of this code to the rt/management module ? Cyrille and other experts can help. The rt/management conrtains a management featire which can be used to monitor both SOAP and RESTful services. And it looks like it can do most of what you've described above but perhaps you can help enhancing it for it to match what your interceptors can do ? The cxf console comes with 3 maven modules : - cxf-soap-console-dao : used for CRUD operation in database, use iBatis. MySQL is supported, I'll add Oracle and Postgres support soon since I need it, I might also add derby support. - cxf-soap-console-interceptors : the soap interceptors that users need to add to their webservices. They are basically extended versions of LoggingInterceptors from cxf. - cxf-soap-console-webapp : a webapp to show data stored by the interceptors (see attached screenshots) It is still in an alpha stage, here are some planned features ; - statistics by service - statistics by operation - jfreechart inclusion in the webapp - a search form - make it a cxf feature This is quite interesting. You may've seen we've discussed the possibility of introducing a rt/management-web module which will initially contain : - atom based pull/push logging support for individual jaxrs/jaxrs endpoints (thsi code is currently in CXF JAX-RS) with the eventual possibility to subscribe or register callback URIs from CXF /services page - CXF JAX-RS based endpoint for showing JMX-based data over HTTP for all CXF endpoints and providing more advanced management capabilities over time I hope this component will eventually turn CXF itself into a well-featured Web application on its own. We'll need to complete some intial support for the Atom pull logging stuff (nearly there) and then I will do the move. It looks like what you've done may be eventually added to this new CXF module. Others may have a different opinion though... cheers, Sergey I've attached the source code, some screenshots, and the ddl script to create the database. Maven should generate a war deployable in tomcat, mvn eclipse:eclipse will generate the eclipse projects. The datasource must be named jdbc/cxf/console. Has this any chance to be included in cxf or should I create a separate project on google code/sourceforge ? Regards, R�mi.
Re: SOAP Monitoring console for CXF
Hi Hi, I wrote a soap monitoring tool for cxf and I'd like to make it open source. I'd like to know if it could be included in cxf package since I think it could be useful to other cxf users. Basically it's just two soap interceptors that store requests, responses and some more data in a database. Additional data is the service name, the operation name, the exception type and the stacktrace if the response is a fault, the response time, the status, the user agent, the encoding, http headers, etc. It also provides a mechanism so users can store their own additional data if they need to. What is your opinion about contributing some of this code to the rt/management module ? Cyrille and other experts can help. The rt/management conrtains a management featire which can be used to monitor both SOAP and RESTful services. And it looks like it can do most of what you've described above but perhaps you can help enhancing it for it to match what your interceptors can do ? The cxf console comes with 3 maven modules : - cxf-soap-console-dao : used for CRUD operation in database, use iBatis. MySQL is supported, I'll add Oracle and Postgres support soon since I need it, I might also add derby support. - cxf-soap-console-interceptors : the soap interceptors that users need to add to their webservices. They are basically extended versions of LoggingInterceptors from cxf. - cxf-soap-console-webapp : a webapp to show data stored by the interceptors (see attached screenshots) It is still in an alpha stage, here are some planned features ; - statistics by service - statistics by operation - jfreechart inclusion in the webapp - a search form - make it a cxf feature This is quite interesting. You may've seen we've discussed the possibility of introducing a rt/management-web module which will initially contain : - atom based pull/push logging support for individual jaxrs/jaxrs endpoints (thsi code is currently in CXF JAX-RS) with the eventual possibility to subscribe or register callback URIs from CXF /services page - CXF JAX-RS based endpoint for showing JMX-based data over HTTP for all CXF endpoints and providing more advanced management capabilities over time I hope this component will eventually turn CXF itself into a well-featured Web application on its own. We'll need to complete some intial support for the Atom pull logging stuff (nearly there) and then I will do the move. It looks like what you've done may be eventually added to this new CXF module. Others may have a different opinion though... cheers, Sergey I've attached the source code, some screenshots, and the ddl script to create the database. Maven should generate a war deployable in tomcat, mvn eclipse:eclipse will generate the eclipse projects. The datasource must be named jdbc/cxf/console. Has this any chance to be included in cxf or should I create a separate project on google code/sourceforge ? Regards, Rémi.
