Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Date: Tue, 30 Apr 2013 12:20:16 +0000 (UTC)
From: "Sergey Beryozkin (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: <JIRA.12645281.1367261968420.248017.1367324416431@arcas>
In-Reply-To: <JIRA.12645281.1367261968420@arcas>
References: <JIRA.12645281.1367261968420@arcas>
Subject: [jira] [Resolved] (CXF-4992) proxy sub-resources creating wrong
 request URIs with non-HTTP transports
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CXF-4992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sergey Beryozkin resolved CXF-4992.
-----------------------------------

    Resolution: Fixed
    
> proxy sub-resources creating wrong request URIs with non-HTTP transports
> ------------------------------------------------------------------------
>
>                 Key: CXF-4992
>                 URL: https://issues.apache.org/jira/browse/CXF-4992
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>    Affects Versions: 2.7.4
>            Reporter: Adar Dembo
>            Assignee: Sergey Beryozkin
>             Fix For: 2.8.0, 2.5.11, 2.6.8, 2.7.5
>
>
> I was experimenting with direct dispatch local transport and ran into an issue with proxy-based clients.
> Here's my working WebClient-based client code:
> {code}
> WebClient client = WebClient.create("local://api");
> WebClient.getConfig(client).getRequestContext().put(LocalConduit.DIRECT_DISPATCH, Boolean.TRUE);
> client.path("v1/clusters/not-a-valid-cluster");
> client.get();
> {code}
> Here's my broken proxy-based client code:
> {code}
> JAXRSClientFactoryBean bean = new JAXRSClientFactoryBean();
> bean.setAddress("local://api");
> bean.setResourceClass(ApiRootResourceImpl.class);
> ApiRootResource root = bean.create(ApiRootResourceImpl.class);
> ClientConfiguration config = WebClient.getConfig(root);
> config.getRequestContext().put(LocalConduit.DIRECT_DISPATCH, Boolean.TRUE);
> config.getConduit();
> root.getRootV1().getClustersResource().readCluster("not-a-valid-cluster");
> {code}
> What breaks? I get an IllegalStateException with the message "Local destination does not have a MessageObserver on address /clusters". Note that the proxy-based client code works correctly when the address is "http://localhost:<port>/api", so I don't suspect anything broken in either the code or in my resource layout.
> I've spent a fair amount of time debugging this and I think I've figured out what's going on. Every method call into the proxy (getRootV1(), getClustersResource(), and readCluster()) creates a new proxy for the corresponding subresource. That involves creating a new LocalClientState (see ClientProxyImpl.invoke() for details). Here is its constructor:
> {code}
> public LocalClientState(URI baseURI) {
>     this.baseURI = baseURI;
>     String scheme = baseURI.getScheme();
>     if (!StringUtils.isEmpty(scheme) && scheme.startsWith(HTTP_SCHEME)) {
>         this.currentBuilder = UriBuilder.fromUri(baseURI);
>     } else {
>         this.currentBuilder = UriBuilder.fromUri("/");
>     }
> }
> {code}
> Because the baseURI in question begins with "local://", we end up in the 'else' statement, which resets our URI's path to '/'. In my case, the URIs for each subcall end up looking like "/", "/v1", and "/clusters" instead of "local://api", "local://api/v1", and "local://api/v1/clusters".
> Later, during conduit selector preparation (called from inside ClientProxyImpl.doChainedInvocation, via createMessage()), we try to find a "compatible" conduit. We only have one conduit: a LocalConduit constructed during the call to config.getConduit() in the client code. The conduit is "compatible" if its endpoint's address matches the address in the message. And the address in the message is based on those partial URIs I described earlier. So what happens? The LocalConduit's endpoint's address is "local://api", but the address in the message is "/clusters". They don't match, and findCompatibleConduit() fails. We then construct a new LocalConduit on-the-fly (see AbstractConduitSelector.getSelectedConduit()), but the LocalDestination that's created for it (by LocalTransportFactory) never gets an observer installed in it. The original LocalConduit (the one that didn't match) has a destination with an observer; it was set up in ServerImpl.start().
> Now, I was able to make forward progress by, using my debugger, modifying LocalClientState.currentBuilder in every proxy call to be an absolute path like "local://api/...". At that point, the exception went away and the message was routed to the server. But then JAXRSInInterceptor.processMessage() failed to find the method to dispatch, so I suspect I broke something in the process.
> I asked about this on the cxf-users mailing list (http://cxf.547215.n5.nabble.com/JAX-RS-recursive-dispatch-td5726752.html). The consensus was that this is a real bug, and likely affects other non-HTTP transports like JMS.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira