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 [email protected] http://www.dankulp.com/blog
