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
