cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: SOAP Monitoring console for CXF
Date Wed, 03 Feb 2010 17:33:46 GMT
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

- 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

- 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.


> 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 :

ex, you might have :

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 :
>> 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

View raw message