Details
-
Type:
Improvement
-
Status: Closed
-
Priority:
Minor
-
Resolution: Complete
-
Affects Version/s: 2.0.4
-
Fix Version/s: 2.2 M4 Sprint 1, 2.2 M4
-
Component/s: Adapters, Async HTTP Support
-
Labels:None
Description
In working on the AsyncHttp Adapter, I would like to extend the existing Http Adapter. More specifically, I would like to extend org.springframework.integration.http.inbound.HttpRequestHandlingMessagingGateway.
However, several methods within that class have restricted visiblity. Would it be possible to make the following 3 changes?
in "org.springframework.integration.http.inbound.HttpRequestHandlingMessagingGateway"
change:
"private void writeResponse(Object content, ServletServerHttpResponse response, List<MediaType> acceptTypes) throws IOException
to
"protected void writeResponse(Object content, ServletServerHttpResponse response, List<MediaType> acceptTypes) throws IOException {...}
"
change:
"private Object handleExceptionInternal(Exception e) throws IOException
to:
"protected Object handleExceptionInternal(Exception e) throws IOException {...}
"
change:
"public final void handleRequest(HttpServletRequest servletRequest, HttpServletResponse servletResponse)
"
to:
"public void handleRequest(HttpServletRequest servletRequest, HttpServletResponse servletResponse) {}"
Issue Links
- is depended on by
-
INT-1196
add Comet/WebSocket/Atmosphere adapters
-
- Open
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Perhaps we can instead factor all of the common code into an abstract base class. The 3 methods you've listed could then be abstract methods. The async and sync implementations would then be relatively thin, containing only the logic that makes them unique.
Mark Fisher
added a comment - Perhaps we can instead factor all of the common code into an abstract base class. The 3 methods you've listed could then be abstract methods. The async and sync implementations would then be relatively thin, containing only the logic that makes them unique. Setting target to 2.1 M1 since that's when we will start providing the foundation for the async HTTP adapter.
Mark Fisher
added a comment - Setting target to 2.1 M1 since that's when we will start providing the foundation for the async HTTP adapter. I want to revisit this for M2. We may address it, move it or dismiss it, but we need to have a separate discussioni about this.
Oleg Zhurakousky
added a comment - I want to revisit this for M2. We may address it, move it or dismiss it, but we need to have a separate discussioni about this. moving back to 2.1 M1
Mark Fisher
added a comment - moving back to 2.1 M1 I'm going to try to start this one first thing after M2.
Mark Fisher
added a comment - I'm going to try to start this one first thing after M2. Moving to 2.2 M1 since that version will provide the initial Async HTTP support.
Mark Fisher
added a comment - Moving to 2.2 M1 since that version will provide the initial Async HTTP support. moving to M2 since we are in discussions with Rossen regarding async support in Spring (and that may affect our approach)
Mark Fisher
added a comment - moving to M2 since we are in discussions with Rossen regarding async support in Spring (and that may affect our approach) Making HttpRequestHandlingEndpointSupport public would be sufficient.
Issued PR: https://github.com/SpringSource/spring-integration/pull/542
Gunnar Hillert
added a comment - Making HttpRequestHandlingEndpointSupport public would be sufficient.
Issued PR: https://github.com/SpringSource/spring-integration/pull/542 
see: http://git.springsource.org/~ghillert/spring-integration/ghillerts-spring-integration/commit/d401e60a4728deaedcd829b5d461498598715cc3