"Kevin.Conner(a)jboss.com" wrote : Second, these processors need to be scoped
correctly with their deployments otherwise they will never be guaranteed to load required
resources/classes (for example during transformation) and this has probably existed since
they were introduced. This could affect both as4 and as5 deployments, especially if the
esb was scoped
When you say "these processors", what are you referring to here?
The reason the Http Gateway works in showing the WSDL is because during the
HttpGatewayServlet init() method, the LifecycleResource mechanism is used to load the WSDL
from the classpath, then the servlet caches the WSDL for when it is called with a
"?wsdl" query string.
However, in the case of using the JBR Gateway (note: INVM no longer an issue - see above),
the contract.jsp is used to serve up the WSDL. It doesn't have a "place" to
hold onto the WSDL like the HttpGatewayServlet does. When contract.jsp (the
"processor" in this case) invokes the WSDL loader, the web tier's
classloader is used. Obviously it won't be able to "see" the wsdl file URL
resource in the ESB archive.
What would you suggest doing here? Can we document that if you are using a classpath://
URI, and you are exposing an HTTP endpoint, that you should simply replace your JBR
Gateway with an HTTP Gateway? That will always work. And if they click on the contract
link with the JBR Gateway, that we warn them there as well (as described above)? Lemme
know; thanks.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4270312#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...