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

[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