Please first read this JBoss ESB User Form Thread: http://community.jboss.org/message/528014
This JBoss ESB Developer Forum Thread is in context to the short-circuting behavior of HttpGatewayServlet when it encounters a ?wsdl (or ?WSDL) request.
Right now, the SOAPProxyWsdlContractPublisher is the only Publisher that implements ContractProvider. When there is a Service whose action pipeline contains an action that is annotated with @Publish, and the associated Publisher implements ContractProvider, then the HttpGatewayServlet knows to ask it to provide the ContractInfo so it can respond to the WSDL request appropriately. However, if a ?wsdl request is made to the servlet and there is no ContractProvider, it simply spits out an empty <definitions/> WSDL contract. This is expected behavior.
We might want to change this behavior, such that if there is no ContractProvider, then go ahead and have the HttpGatewayServlet execute ServiceInvoker anyway, even if it's a ?wsdl request. What this does is it gives the developer an option to write a custom action that uses HttpRequest requestInfo = HttpRequest.getRequest(message), then use the properties of requestInfo to determine of the user asked for the WSDL (?wsdl), then serve up custom wsdl. The downside is that if the developer doesn't handle that case, then most likely the action pipeline will get executed without the correct request data / payload, and things will fail. Hmmm... perhaps we keep the current behavior the default, but provide an option to HttpGateway to allow for this? Maybe something like <http-gateway name="..." allow-wsdl-requests="true"/> ? (Okay, that's a bad attribute name, but you get the point.)
If we don't do anything, the developer still has another existing option, although it does entail a bit more work. Basically, on a custom action, add a @Publish annotation that uses a custom Publisher implementation that implements ContractProvider. The developer could simply extend DefaultContractReferencePublisher and implemement ContractProvider, for example, then use that to spit out their custom WSDL. The added benefit of this approach is that their WSDL will also magically show up in the contract JSP application ( http://.../contract/ ).
|Retrieving data ...|