cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cyrille Le Clerc (JIRA)" <>
Subject [jira] Commented: (CXF-2541) JMX Per Operation ResponseTime not collected for JAX-RS services
Date Sun, 22 Nov 2009 17:25:39 GMT


Cyrille Le Clerc commented on CXF-2541:

Hello Sergey,

Sorry for the late answer, I wanted to taked time to better understand this point.

I see great opportunities to share a common Service&Operation model in CXF (frontends,
bindings, transports, etc). Of course, these services and operations should be extended for
each frontend. I see quick wins for monitoring, logging, debugging and security.

Unfortunately, the Service and Operation declared in org.apache.cxf.service.model (cxf-api
project) seem to be too much JAX-WS specific and not to fit well for JAX-RS needs. I imagine
this is the reason why o.a.c.jaxrs.model.OperationResourceInfo doesn't extend o.a.c.service.model.OperationInfo
.Moreover, I have the feeling the Exchange and Message maps have reached their limits : indexing
properties by the class is tricky witch inheritance and we are never really sure an entry
may be null or not. due to this, this seem to cause the introduction of "not null defensive

In an ideal world or for a long term goal, I would see :
* refactoring of  o.a.c.service.model ServiceInfo and OperationInfo to push the JAX-WS specific
attributes in dedicated sub classes,
* refactoring of o.a.c.jaxrs.model.OperationResourceInfo to extend the common o.a.c.service.model
* addition of Service and Operation attribute to the Exchange object next to the already existing
Destination attribute.

A short term scenario with limited impacts could be to introduce a shared Operation interface
in cxf-api project with limited attributes to prevent the dependencies issues (cxf-rt-management
has no reason to depend on cxf-frontend-jaxrs). Finding a name to this interface could be
challenging because o.a.c.service.model.OperationInfo is already used and the naming  convention
is to suffix by "Info" (ServiceInfo, OperationInfo, etc).
A solution would be to introduce an interface o.a.c.service.Operation next to the already
existing o.a.c.service.Service.


> JMX Per Operation ResponseTime not collected for JAX-RS services
> ----------------------------------------------------------------
>                 Key: CXF-2541
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>    Affects Versions: 2.2.3
>            Reporter: Cyrille Le Clerc
>         Attachments: usage-of-OperationInfo-and-OperationResourceInfo.log
> The JMX ResponseTimeFeature does not work on a per operation basis for JAXRS calls but
works on a per Service basis.
> My understanding is that it works on a per service basis because both o.a.c.jaxrs.JAXRSServiceImpl
and o.a.c.service.ServiceImpl implement the same o.a.c.service.Service interface and are indexed
in the Exchange map at the o.a.c.service.Service entry.
> On the other hand, it does not work on the per operation basis because o.a.c.jaxrs.model.OperationResourceInfo
and o.a.c.service.model.OperationInfo do not implement a shared interface. Thus, the ResponseTimeFeature
is specific to SOAP operations and can not handle JAXRS 'operations'.
> A fix could be to introduce a shared Operation interface, to make both OperationResourceInfo
and OperationInfo implement this interface and to us the interface as the key for the Exchange
map instead of the current OperationResourceInfo.class and OperationInfo.class.
> There are 30 "put()" & "get()" calls on OperationInfo.class. and 8 "put()" &
"get()" calls on OperationResourceInfo.class.
> I would be very pleased to propose a patch if the project is interested.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message