[jira] Created: (CXF-2387) CXF does not call ConduitSelector.complete() on the server side.

["Gyorgy Orban (JIRA)" <ji...@apache.org>]

CXF does not call ConduitSelector.complete() on the server side.
----------------------------------------------------------------

                 Key: CXF-2387
                 URL: https://issues.apache.org/jira/browse/CXF-2387
             Project: CXF
          Issue Type: Improvement
          Components: Core
            Reporter: Gyorgy Orban


I guess the main reason for it is that closing the input stream in a servlet is usually not a good idea. As the default implementation in PreexistingConduitSelector.complete() closes the input stream of the request message, it would cause problems when CXF is deployed in Jetty or in other servlet containers. On the other hand, from design and extensibility perspective it would be quite useful to call ConduitSelector.complete() similarly to the client side for the following reasons:

* integration with other transports could make use of such a lifecycle callback
* If the request InputStream is wrapped (let's say we want to monitor throughput or filter the inputstream for some reason) it is quite difficult to catch the end of the stream without a close() callback on the InputStream. If complete() was called, a custom ConduitSelector could solve that.

I think ConduitSelector.complete() could be included in the Destination implementations.
Could you please give your opinion on this?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (CXF-2387) CXF does not call ConduitSelector.complete() on the server side.

["Daniel Kulp (JIRA)" <ji...@apache.org>]

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

Daniel Kulp resolved CXF-2387.
------------------------------

         Assignee: Daniel Kulp
    Fix Version/s: Invalid
       Resolution: Fixed


This has been more or less implemented for a very long time.

The MessageSenderEndingInterceptor which is used by the outgoing chain for both client and server calls:
{code}
getConduit(message).close(message);
{code}

Where any subclass of Conduit can override the close(Message) call to do whatever custom stuff needs to be done.



> CXF does not call ConduitSelector.complete() on the server side.
> ----------------------------------------------------------------
>
>                 Key: CXF-2387
>                 URL: https://issues.apache.org/jira/browse/CXF-2387
>             Project: CXF
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Gyorgy Orban
>            Assignee: Daniel Kulp
>             Fix For: Invalid
>
>
> I guess the main reason for it is that closing the input stream in a servlet is usually not a good idea. As the default implementation in PreexistingConduitSelector.complete() closes the input stream of the request message, it would cause problems when CXF is deployed in Jetty or in other servlet containers. On the other hand, from design and extensibility perspective it would be quite useful to call ConduitSelector.complete() similarly to the client side for the following reasons:
> * integration with other transports could make use of such a lifecycle callback
> * If the request InputStream is wrapped (let's say we want to monitor throughput or filter the inputstream for some reason) it is quite difficult to catch the end of the stream without a close() callback on the InputStream. If complete() was called, a custom ConduitSelector could solve that.
> I think ConduitSelector.complete() could be included in the Destination implementations.
> Could you please give your opinion on this?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.