[ http://jira.jboss.com/jira/browse/JBESB-583?page=all ] Tom Fennelly updated JBESB-583: ------------------------------- Description: The SOAPClient supports using XStream to deserialize messages. In order to support namespaced messages, we have to use the StaxDriver for XStream. This means including a StAX impl in the classpath. We've included Woodstox. The StAX impl is picked up via a factory class that uses a System property. The System prop is set via services defs in the impl jar i.e. the woodstox jar set the impl via a services def. So the first problem is: When jboss-messaging-client.jar is on the classpath, the stax core is not able to find the impl via the System property. Remove jboss-messaging-client.jar from the classpath(and replace with jboss-remoting.jar) and all is fine for those tests. This however causes the following mysterious issue: When the jboss-message-client.jar is removed from the classpath and replaced with jboss-remoting.jar, the JBossRemotingGatewayListener is unable to start because it can't find the "org.jboss.remoting.transport.coyote.CoyoteInvoker" (or something like that). This is totally bizarre because I've checked the classpath many times and the class is def there. It is picking up the jar because I can assert that other classes from the same jar are visible. I did a number of tests on this, all based on removing everything else from the classpath and only having the jboss-remoting.jar file. Need to get to the bottom of these classpath issues. I've gotten around (for now) it in the tests by running the unit tests twice in the build and modifying the classpath on both runs. Don't worry, I exclude and include so as we're not running the same tests twice. was: The SOAPClient supports using XStream to deserialize messages. In order to support namespaced messages, we have to use the StaxDriver for XStream. This means including a StAX impl in the classpath. We've included Woodstox. The StAX impl is picked up via a factory class that uses a System property. The System prop is set via services defs in the impl jar i.e. the woodstox jar set the impl via a services def. So the first problem is: When jboss-messaging-client.jar is on the classpath, the stax core is not able to find the impl via the System property. Remove jboss-messaging-client.jar from the classpath(and replace with jboss-remoting.jar) and all is fine for those tests. This however causes the following mysterious issue: The jboss-message-client.jar is removed from the classpath and replaced with jboss-remoting.jar, the JBossRemotingGatewayListener is unable to start because it can't find the "org.jboss.remoting.transport.coyote.CoyoteInvoker" (or something like that). This is totally bizarre because I've checked the classpath many times and the class is def there. It is picking up the jar because I can assert that other classes from the same jar are visible. I did a number of tests on this, all based on removing everything else from the classpath and only having the jboss-remoting.jar file. Need to get to the bottom of these classpath issues. I've gotten around it in the tests by running the unit tests twice in the build and modifying the classpath on both runs. Don't worry, I exclude and include so as we're not running the same tests twice. -- 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

[ http://jira.jboss.com/jira/browse/JBESB-583?page=all ] Tom Fennelly closed JBESB-583. ------------------------------ Resolution: Done No longer an issue since we've pulled all the soap components out into a .esb service of it's own. -- 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

[ http://jira.jboss.com/jira/browse/JBESB-583?page=all ] Mark Little reopened JBESB-583: ------------------------------- -- 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