[
https://jira.jboss.org/jira/browse/JBESB-2814?page=com.atlassian.jira.plu...
]
David Ward commented on JBESB-2814:
-----------------------------------
Okay, this could be an issue that is due to the webservice_proxy_security using the
jboss-esb-1.1.0.xsd configuration and the <http-provider><http-bus> and
<http-listener is-gateway="true" tags. When doing that, the
org.jboss.soa.esb.listeners.gateway.HttpMessageComposer is used. The other
webservice_proxy_* examples use thew new jboss-esb-1.2.0.xsd configuration and the
<http-gateway tag. When doing that, the
org.jboss.soa.esb.listeners.gateway.http.HttpMessageComposer is used (notice the
"http" sub-package difference).
So, I'm guessing I should upgrade the config to 1.2.0 and use the <http-gateway
tag. I'll have to figure out how to set the SSL configuration properly on the new
tag. What should we do about the old HttpMessageComposer usage? Something was changed
between the release of ESB 4.6 and the current trunk version... Unfortunately I'm
having a little trouble with svn history because things appear to have been moved around.
Also (and I haven't tried it yet), the new composer looks like it puts all the request
headers into a HttpRequest object, found in the ESB Message Properties under the name
"org.jboss.soa.esb.http.HttpRequest#request". I believe this would mean the
HttpRouter would still not be able to find the properties it's looking for...
HTTP request headers now nested inside RequestInfoMap property causes
invisibility to HttpRouter and dependents
---------------------------------------------------------------------------------------------------------------
Key: JBESB-2814
URL:
https://jira.jboss.org/jira/browse/JBESB-2814
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Transports
Affects Versions: 4.7
Reporter: David Ward
Assignee: Tom Fennelly
Priority: Blocker
Fix For: 4.7
It appears the new http gateway on trunk is now nesting the incoming http request headers
into a ESB Message property of "RequestInfoMap". There is code assuming the
request headers would be top-level properties.
For example, HttpSOAPProxyTransport embeds usage of HttpRouter, setting it's default
configuration of "MappedHeaderList" to "Content-Type, Accept,
Authorization, SOAPAction". On lines 232-255 of HttpRouter (the setMappedHttpHeaders
and getHttpHeaders methods), the mapped headers are attempted to be pulled directly out of
the ESB Message Properties, *not* to first pull out the "RequestInfoMap" then
pull out the header properties from that map. This breaks the webservice_proxy_security
quickstart, but more importantly, it would break any code or configuration usage out there
where people are assuming the old location of the request headers.
I'm okay with the change to nest the request headers inside the RequestInfoMap
property, however 1) HttpRouter getHttpHeaders(Message,String):Object needs to be updated,
and 2) we need to make sure the release notes warns users of this change, just in case
there was custom code or configuration out there assuming the old property location.
--
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