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
