[JBoss JIRA] Created: (JBESB-2903) Backwards incompatibility with HttpResponse
by Lukáš Petrovický (JIRA)
Backwards incompatibility with HttpResponse
-------------------------------------------
Key: JBESB-2903
URL: https://jira.jboss.org/jira/browse/JBESB-2903
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Rosetta
Reporter: Lukáš Petrovický
Fix For: 4.7
In SOA-P 5.0 ER1 (which leverages ESB 4.7 trunk), we found the following backwards-incompatible change while compiling one of our tests (based on the http_2way_ssl QS):
[javac] /home/lpetrovi/Work/QE/tests/quickstarts/https_2way_ssl/src/org/jboss/soa/esb/samples/https/client/HttpResponsePrinter.java:35: incompatible types
[javac] found : java.util.List<org.jboss.soa.esb.http.HttpHeader>
[javac] required: java.util.List<org.jboss.soa.esb.actions.routing.http.HttpHeader>
[javac] List<HttpHeader> headers = httpResponse.getHeaders();
[javac] ^
[javac] Note: /home/lpetrovi/Work/QE/tests/quickstarts/https_2way_ssl/src/org/jboss/soa/esb/samples/https/client/HttpResponsePrinter.java uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
As you can see, the getHeaders() method now returns a different type than it used to. In my opinion, breaking backwards compatibility would be OK when switching to a new major version of ESB, but this is not the case.
I also noticed that the QS in question has been updated in the ESB to reflect this change, so I expect the view of the ESB team is that this is not a valid bug.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira