-
1. Re: SOAPProxy+AS5: INVM contract unavailable w/classpath URI
dward Dec 9, 2009 3:03 PM (in response to dward)It doesn't look like the ContractProviderLifecycleResource can be used to help in this circumstance.
I question the usefulness of providing a wsdl contract for non-HTTP addresses at this time. May I suggest that for now (ie: the 4.x ESB stream, pre-5.x), we handle this case by not dumping an exception, but instead give the user the message:'classpath:///helloworld.wsdl' unavailable: WSDL address URI format unsupported by contract application.
only IF they click on a contract link whose contract was loaded with a "classpath://" uri AND they are not using the HttpGateway? (The HTTP contract via classpath would still be available in that case, thanks to ContractProviderLifecycleResource.)
I made this change locally, but won't commit it to JBESB_4_7_CP until I hear that this is the approach we want to take. Of course I'm all ears too if someone has another option. -
2. Re: SOAPProxy+AS5: INVM contract unavailable w/classpath URI
dward Dec 9, 2009 3:06 PM (in response to dward)Or more specifically, the message could be:
'classpath:///helloworld.wsdl' unavailable: WSDL address URI format unsupported by contract application unless http-gateway is employed.
-
3. Re: SOAPProxy+AS5: INVM contract unavailable w/classpath URI
kconner Dec 10, 2009 4:51 AM (in response to dward)This problem highlights two issues, one of which we already know about
First, only when WSDL is exposed through the HTTP/JBR endpoints should the contract publisher be registered. https://jira.jboss.org/jira/browse/JBESB-2913 seems to cover this.
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.
We should use https://jira.jboss.org/jira/browse/JBESB-3034 to focus on the classloading aspect and the other to focus on when they are published.
Kev -
4. Re: SOAPProxy+AS5: INVM contract unavailable w/classpath URI
dward Dec 11, 2009 3:15 PM (in response to dward)"Kevin.Conner@jboss.com" wrote:
First, only when WSDL is exposed through the HTTP/JBR endpoints should the contract publisher be registered. https://jira.jboss.org/jira/browse/JBESB-2913 seems to cover this.
I spent a good amount of time digging through when/how/why publishers are added to ServicePublisher, as well as when/how/why EPRs are registered in the Registry, as well as how/why the contract JSP application exposes contracts. Basically, there are two kinds of Publishers: ContractPublishers and ContractReferencePublishers. When you are talking about EBWS or SOAPProxy, a ContractReferencePublisher is added, and they do not require an EPR registered in the Registry. However, everything else (like SOAPProducer) requires an EPR registered in the Registry for them to display properly in the contract JSP application.
You can't not register their EPRs, just so the contract JSP app won't display them. Reason is that a particular Service might have multiple Listeners configured, for example a mix of JMS and HTTP (JBR or HttpGateway), and not registering the non-HTTP EPRs would mean the ServiceInvoker would have nothing to load balance across. Because of this, I believe the best route to take is to change the contract JSP app so that it lists all Services, but only provides contract links to WSDL for HTTP (or HTTPS) endpoints. -
5. Re: SOAPProxy+AS5: INVM contract unavailable w/classpath URI
dward Dec 11, 2009 3:24 PM (in response to dward)"dward" wrote:
"Kevin.Conner@jboss.com" wrote:
First, only when WSDL is exposed through the HTTP/JBR endpoints should the contract publisher be registered. https://jira.jboss.org/jira/browse/JBESB-2913 seems to cover this.
You can't not register their EPRs, just so the contract JSP app won't display them. Reason is that a particular Service might have multiple Listeners configured, for example a mix of JMS and HTTP (JBR or HttpGateway), and not registering the non-HTTP EPRs would mean the ServiceInvoker would have nothing to load balance across.
To more completely address Kev's quote, I should also clarify that you similarly can't not add the Publisher for those cases where you have a mix of Listeners configured, some that we want to expose contracts for, and some that we don't. I believe that doing the filtering in the contract JSP app is the safest thing to do without causing big ripples in the 4.x codebase. -
6. Re: SOAPProxy+AS5: INVM contract unavailable w/classpath URI
dward Dec 11, 2009 4:35 PM (in response to dward)I added a screenshot of the fixed contract JSP application:
https://jira.jboss.org/jira/secure/attachment/12330765/service-list.png
to this Jira:
https://jira.jboss.org/jira/browse/JBESB-2913
You can see only HTTP and HTTPS contracts are available, whether it be via JBR, EBWS or HttpGateway (in this example, from SOAPProxy).
Next I'm onto this Jira:
https://jira.jboss.org/jira/browse/JBESB-3034
... -
7. Re: SOAPProxy+AS5: INVM contract unavailable w/classpath URI
dward Dec 11, 2009 6:57 PM (in response to dward)"Kevin.Conner@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. -
8. Re: SOAPProxy+AS5: INVM contract unavailable w/classpath URI
kconner Dec 14, 2009 4:46 AM (in response to dward)We are not going to document this away, we need to fix it.
Please leave this one alone for now, I will look at it later this week.
Kev
-
9. Re: SOAPProxy+AS5: INVM contract unavailable w/classpath URI
kconner Dec 14, 2009 5:44 AM (in response to dward)EPRs are *not* the issue, the publishers are.
We need to fix this issue, not hide it.
Kev