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 Thu, 04 Feb 2010 10:57:20 GMT
Hi Rémi

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

Thoughts ? Objections ?

> 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
>> in. Instead we can have a CXF JAXRS
>> endpoint (see below) in rt/management-web implementing an interface to do with searching
>> exchanges.
>> - please remove Statistics class, we can introduce it later on, when working on exposing
>> over the web. Now, I'm also
>> thinking that may be we can ensure it can keep the data accumulated in JMX beans
>> - 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,
>> 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 :
>> 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
>>        return exchangeDaoReader.getStatistics();
>>    }
>>    ...
>> }
>> cheers, Sergey

View raw message