[ http://jira.jboss.com/jira/browse/JBTM-265?page=all ] Work on JBTM-265 started by Andrew Dinn. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBTM-265?page=com.atlassian.jira.plugi... ] Mark Little updated JBTM-265: ----------------------------- Fix Version/s: 4.7 -- 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

[ https://jira.jboss.org/jira/browse/JBTM-265?page=com.atlassian.jira.plugi... ] Andrew Dinn commented on JBTM-265: ---------------------------------- Ok, I have managed to modify XTS to run over JBossWS/CXF 3.1.0 but a few caveats apply I had to patch two bugs in CXF so we cannot go ahead with moving to CXF untiil JBossWS assimilates fixes for CXF-2161 and CXF-2167. I had to break XTS working on JBossWS/Native because of several incompatibilities. The most notable difference is that the AddressingProperties class and related classes reside in different packages but there are a couple of others: i) the RelatesTo field in CXF has only one entry whereas in JBoss it is an array of entries ii) when a JaxWS port is created from a W3CEndpoint JBossWS configures its request messaqe properties with a MAP containing any WSA header values derived from the endpoint. this requires the XTS code to merge any extra headers into the existing MAP. CXF stashes the endpoint WSA header values in the port and so XTS has to create a MAP containing the extra headers and hang this off the request message properties. iii) CXF does not support JAX-RPC so the JaxRPC client handlers could not be compiled (the requisite headers are missing from the CXF libraries). This means the old version of the demo has to be dropped on CXF. Ignoring the JAX-RPC issue, it ought to be possible to hide these differences behind a wrapper class which managed the underlying MAP types and handled the task of configuring a JaxWS port. However, this would mean that the build process would have to be modified to build either a JBossWS/Native compatible version or a JBoss/CXF compatible version i.e. the XTS code would for all intents and purposes become dual binary (this is why we really need a fix in JBossWS). -- 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

[ https://jira.jboss.org/jira/browse/JBTM-265?page=com.atlassian.jira.plugi... ] Work on JBTM-265 stopped by Andrew Dinn. -- 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