[esb-issues] [JBoss JIRA] Updated: (JBESB-2903) Backwards incompatibility with HttpResponse

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 Affects Versions: 4.7 Reporter: Lukáš Petrovický 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.