[jira] [Issue Comment Edited] (CXF-4154) AbstractConduitSelector reused cached conduit even if protocol was changed

["Andrei Shakirin (Issue Comment Edited) (JIRA)" <ji...@apache.org>]

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

Andrei Shakirin edited comment on CXF-4154 at 3/26/12 3:52 PM:
---------------------------------------------------------------

Just tested with my use case - your fix works!

Only snapshoot in findCompatibleConduit() I did not completely understand:
{code}
        for (Conduit c2 : conduits) {
            if (c2.getTarget() == null 
                || c2.getTarget().getAddress() == null
                || c2.getTarget().getAddress().getValue() == null) {
                return c2;
            }
        }
{code}
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.
                
      was (Author: ashakirin):
    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