cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rémi Flament <>
Subject Re: SOAP Monitoring console for CXF
Date Wed, 03 Feb 2010 02:20:43 GMT

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.
Basically I've removed all the spring-orm/ibatis part and I've added a 
simple implementation of ExchangeDAO which logs to text files.

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

> 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