cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrei Shakirin (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-4154) AbstractConduitSelector reused cached conduit even if protocol was changed
Date Mon, 26 Mar 2012 15:52:27 GMT

    [ https://issues.apache.org/jira/browse/CXF-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238505#comment-13238505
] 

Andrei Shakirin commented on CXF-4154:
--------------------------------------

Just tested with my use case - your fix works!

Only snapshoot in findCompatibleConduit() I did not completely understand:
        for (Conduit c2 : conduits) {
            if (c2.getTarget() == null 
                || c2.getTarget().getAddress() == null
                || c2.getTarget().getAddress().getValue() == null) {
                return c2;
            }
        }
Does conduit with not initialized target endpoint make sense at all? AbstractConduit constructor
requires target endpoint argument, of course it is possible to give null there - but is there
any use case for it? 
Do you think it is legal to choose such conduit if there is no another one that fit better
(regarding protocol or full URL)?
I would propose just return null in findCompatibleConduit() for this case and re-initialse
conduit.
                
> AbstractConduitSelector reused cached conduit even if protocol was changed
> --------------------------------------------------------------------------
>
>                 Key: CXF-4154
>                 URL: https://issues.apache.org/jira/browse/CXF-4154
>             Project: CXF
>          Issue Type: Bug
>          Components: Core
>            Reporter: Andrei Shakirin
>         Attachments: AbstractConduitSelector.patch
>
>
> Hi,
> Actually AbstractConduitSelector.getSelectedConduit() creates and caches conduit in selectedConduit
variable. Cached conduit is reused by the next calls.
> I see the following problem: if user changed protocol in URI between calls, AbstractConduitSelector
still uses cached Conduit even it cannot process new URL. In my case cached HTTP consuit tries
to process UDP URL.
> Proposal for fix: check if protocol in URL was changed and if yes, close and reset selectedConduit.
> Patch is attached.
> Regards,
> Andrei.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message