[
https://issues.apache.org/jira/browse/CXF-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781166#action_12781166
]
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
code".
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 OperationInfo,
* 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.
Cyrille
> JMX Per Operation ResponseTime not collected for JAX-RS services
> ----------------------------------------------------------------
>
> Key: CXF-2541
> URL: https://issues.apache.org/jira/browse/CXF-2541
> 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.
