9 Replies Latest reply on Dec 14, 2009 5:44 AM by kconner

    SOAPProxy+AS5: INVM contract unavailable w/classpath URI

    dward

      This post is to discuss options for fixing https://jira.jboss.org/jira/browse/JBESB-3034.

      Using ESB 4.7 deployed in AS 5.1, if you configure the SOAPProxy with a wsdl property using a classpath URI (like "classpath://helloworld.wsdl"), then attempt to look at the INVM service contract at http://localhost:8080/contract/, you will get the following error:

      11:48:24,707 ERROR [AbstractWsdlContractPublisher] Failed to load WSDL contract information from WS Endpoint 'classpath:///helloworld.wsdl'.
      java.lang.NullPointerException
       at org.jboss.soa.esb.actions.soap.proxy.SOAPProxyWsdlContractPublisher.getWsdl(SOAPProxyWsdlContractPublisher.java:60)
       at org.jboss.soa.esb.actions.soap.AbstractWsdlContractPublisher.getContractInfo(AbstractWsdlContractPublisher.java:141)
       at org.apache.jsp.contract_jsp._jspService(contract_jsp.java:126)
       at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
       at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
       at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:369)
       ...


      When deploying ESB into JBoss AS 4.2.3, both the HTTP and INVM wsdl is available through the contract JSP app. But when deploying ESB into JBoss AS 5.1, only the HTTP wsdl is available.

      I believe the problem is classloading visibility. In the contract JSP app, when clicking on the INVM wsdl link, the classloader of the web tier is used to lookup the classpath URL resource of "helloworld.wsdl". This is no problem on AS 4.2.3, most likely because of the behavior of the UnifiedClassLoader. However, on AS 5.1, classloading is obviously different, so the URL resource cannot be found. One would have to use the classloader of the deployed esb archive, I would assume (as that's where helloworld.wsdl lives).

      But why does the HTTP wsdl link work through the contract JSP app, no matter if AS 4.2.3 or 5.1 is used? Because during the esb archive deployment, when the HttpGatewayServlet is initialized, the wsdl is obtained using the ContractProviderLifecycleResource, which handles it.

      Thoughts on what we should do about this?

        • 1. Re: SOAPProxy+AS5: INVM contract unavailable w/classpath URI
          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

            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

              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

                 

                "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

                   

                  "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

                    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

                       

                      "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

                        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

                          EPRs are *not* the issue, the publishers are.

                           

                          We need to fix this issue, not hide it.

                           

                          Kev