cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aki Yoshida (JIRA)" <>
Subject [jira] [Updated] (CXF-3510) wrong destination determination by OSGi based CXF entry point (regarding its fallback logic)
Date Thu, 12 May 2011 17:52:47 GMT


Aki Yoshida updated CXF-3510:

    Attachment: trunk-20110512.diff.txt

Attached are the 2.3.x and trunk fixes with unit tests.

M       2.3.x-fixes/rt/transports/http-osgi/src/test/java/org/apache/cxf/transport/http_osgi/
M       2.3.x-fixes/rt/transports/http-osgi/src/main/java/org/apache/cxf/transport/http_osgi/

A       trunk/rt/transports/http/src/test/java/org/apache/cxf/transport/http/
M       trunk/rt/transports/http/src/main/java/org/apache/cxf/transport/http/

The path matching code checks the trailing '/' to avoid false matching. This change itself
is straightforward.

The test class is also straightforward for 2.4.x, as the method to be tested is public. In
cotrast, it is somehow complicated for 2.3.x, as the coresponding method is not public and
the test uses another accessible method.

For both codelines, the provided tests cover the cases that we discussed in the dev@cxf mailing

regards, aki

> wrong destination determination by OSGi based CXF entry point (regarding its fallback
> --------------------------------------------------------------------------------------------
>                 Key: CXF-3510
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>          Components: Transports
>    Affects Versions: 2.4, 2.3.4
>            Reporter: Aki Yoshida
>            Assignee: Aki Yoshida
>             Fix For: 2.4.1, 2.3.5
>         Attachments: 2.3.x-fixes-20110512.diff.txt, trunk-20110512.diff.txt
>   Original Estimate: 2h
>  Remaining Estimate: 2h
> This problem is described in cxf-user thread
> In summary, the http entry point in the OSGi container uses the destination determination
logic using a simple request path matching when there is no exact match of the request URL
path to one of the registered destination paths. Consequently, when you have a service registered
at "/abc", a request to any URL path starting with this string, for example, "/abc2", "/abctest"
is also fowarded to this service. And this is not intended.
> The intention of this fallback logic was for the rest based calls to forward a request
with an additional path argument to its correct service. For examples, requests to "/abc/def"
or "/abc/1/2" should be forwarded to the service registered at "/abc".
> I'll be suggesting the change required in org.apache.cxf.transport.http_osgi.OsgiServletController
for 2.3.x and org.apache.cxf.transport.http.DestinationRegistryImpl for 2.4.x.

This message is automatically generated by JIRA.
For more information on JIRA, see:

View raw message