[esb-issues] [JBoss JIRA] Updated: (JBESB-3412) All webservice_proxy_* quickstarts are broken

[David Ward (JIRA)]

     [ https://jira.jboss.org/browse/JBESB-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Ward updated JBESB-3412:
------------------------------

    Description: 
Each of the webservice_proxy_* quickstarts are broken in some way.

webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all have problem with their WSDL contracts being empty from the http//localhost:8080/contract/ web application.  Light debugging showed that the reason for this is that ContractProviderLifecycleResource, while having it's map being propertly populated with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at deployment, is returning null when the HttpGatewayServlet attempts to get at it's appropriate ContractProvider.  The reason is that during the thread of execution behind the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat, svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID (or whatever it's called) instead of the actual deployment ID.  This *USED* to work, so I don't know what changed environment-wise.  webservice_proxy_routed doesn't provide a contract (no HTTP endpoints), so it's N/A to that quickstart.

webservice_proxy_routed has a different problem.  It appears the work done in JBESB-3372 ("Move SOAP services away from JBossWS-Native implementation") has a bug when using JBossWS-Native.  I thought the purpose was that both the Native and CXF stacks should work.  If only the CXF stack should work, we shouldn't release ESB .org with Native.  Anyway, after lightly looking at the code changes, it appears that there is a problem with the mappings being done.  Specifically the same QName for Operation/Binding is being reused everywhere, even if there is more than one.  When you run the quickstart with "ant saygoodbye", it work.  When you run the quickstart with "ant sayhello" it breaks.  This is because the goodbye QName is what was used.  For example, "{http://webservice_proxy_routed/goodbye}GoodbyeBinding" and "{http://webservice_proxy_routed/goodbye}sayGoodbye".  This is fine for "ant rungoodbye", but when you run "ant runhello" you get, "ERROR [SOAPFaultHelperJAXWS] SOAP request exception
org.jboss.ws.core.CommonSOAPFaultException: Endpoint {http://webservice_proxy_routed/goodbye}GoodbyePort does not contain operation meta data for: {http://webservice_proxy_routed/hello}sayHello".  So, obviously the mapping work done during initialization is busted in that it won't support more than one.  In fact, looking at the deployment INFO being logged again, you will see the set of "[SOAPProxy] mapped abc [...] to xyz [...]" mappings twice, but both sets for GOODBYE.  Nothing for HELLO.

I also noticed that the new JBossWSDLReader.java (which is used by SOAPProxy, among other soap services), is doing serveral System.out.println's.  For example, "17:59:43,631 INFO  [STDOUT] Retrieving document at...".  These should be using Log4j.

  was:
Each of the webservice_proxy_* quickstarts are broken in some way.

webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all have problem with their WSDL contracts being empty from the http//localhost:8080/contract/ web application.  Light debugging showed that the reason for this is that ContractProviderLifecycleResource, while having it's map being propertly populated with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at deployment, is returning null when the HttpGatewayServlet attempts to get at it's appropriate ContractProvider.  The reason is that during the thread of execution behind the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat, svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID (or whatever it's called) instead of the actual deployment ID.  This *USED* to work, so I don't know what changed environment-wise.  webservice_proxy_routed doesn't provide a contract (no HTTP endpoints), so it's N/A to that quickstart.

webservice_proxy_routed has a different problem.  It appears the work done in JBESB-3372 ("Move SOAP services away from JBossWS-Native implementation") has a bug when using JBossWS-Native.  I thought the purpose was that both the Native and CXF stacks should work.  If only the CXF stack should work, we shouldn't release ESB .org with Native.  Anyway, after lightly looking at the code changes, it appears that there is a problem with the mappings being done.  Specifically the same QName for Operation/Binding is being reused everywhere, even if there is more than one.  When you run the quickstart with "ant saygoodbye", it work.  When you run the quickstart with "ant sayhello" it breaks.  This is because the goodbye QName is what was used.  For example, "{http://webservice_proxy_routed/goodbye}GoodbyeBinding" and "{http://webservice_proxy_routed/goodbye}sayGoodbye".  This is fine for "ant rungoodbye", but when you run "ant runhello" you get, "ERROR [SOAPFaultHelperJAXWS] SOAP request exception
org.jboss.ws.core.CommonSOAPFaultException: Endpoint {http://webservice_proxy_routed/goodbye}GoodbyePort does not contain operation meta data for: {http://webservice_proxy_routed/hello}sayHello".  So, obviously the mapping work done during initialization is busted in that it won't support more than one.  In fact, looking at the deployment INFO being logged again, you will see the set of "[SOAPProxy] mapped abc [...] to xyz [...]" mappings twice, but both sets for GOODBYE.  Nothing for HELLO.



> All webservice_proxy_* quickstarts are broken
> ---------------------------------------------
>
>                 Key: JBESB-3412
>                 URL: https://jira.jboss.org/browse/JBESB-3412
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Examples, Web Services
>         Environment: JDK 1.5 + AS 4.2.3 and JDK 1.6 + AS 5.1.0
>            Reporter: David Ward
>            Priority: Blocker
>             Fix For: 4.9
>
>         Attachments: webservice_proxy_routed.log
>
>
> Each of the webservice_proxy_* quickstarts are broken in some way.
> webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all have problem with their WSDL contracts being empty from the http//localhost:8080/contract/ web application.  Light debugging showed that the reason for this is that ContractProviderLifecycleResource, while having it's map being propertly populated with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at deployment, is returning null when the HttpGatewayServlet attempts to get at it's appropriate ContractProvider.  The reason is that during the thread of execution behind the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat, svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID (or whatever it's called) instead of the actual deployment ID.  This *USED* to work, so I don't know what changed environment-wise.  webservice_proxy_routed doesn't provide a contract (no HTTP endpoints), so it's N/A to that quickstart.
> webservice_proxy_routed has a different problem.  It appears the work done in JBESB-3372 ("Move SOAP services away from JBossWS-Native implementation") has a bug when using JBossWS-Native.  I thought the purpose was that both the Native and CXF stacks should work.  If only the CXF stack should work, we shouldn't release ESB .org with Native.  Anyway, after lightly looking at the code changes, it appears that there is a problem with the mappings being done.  Specifically the same QName for Operation/Binding is being reused everywhere, even if there is more than one.  When you run the quickstart with "ant saygoodbye", it work.  When you run the quickstart with "ant sayhello" it breaks.  This is because the goodbye QName is what was used.  For example, "{http://webservice_proxy_routed/goodbye}GoodbyeBinding" and "{http://webservice_proxy_routed/goodbye}sayGoodbye".  This is fine for "ant rungoodbye", but when you run "ant runhello" you get, "ERROR [SOAPFaultHelperJAXWS] SOAP request exception
> org.jboss.ws.core.CommonSOAPFaultException: Endpoint {http://webservice_proxy_routed/goodbye}GoodbyePort does not contain operation meta data for: {http://webservice_proxy_routed/hello}sayHello".  So, obviously the mapping work done during initialization is busted in that it won't support more than one.  In fact, looking at the deployment INFO being logged again, you will see the set of "[SOAPProxy] mapped abc [...] to xyz [...]" mappings twice, but both sets for GOODBYE.  Nothing for HELLO.
> I also noticed that the new JBossWSDLReader.java (which is used by SOAPProxy, among other soap services), is doing serveral System.out.println's.  For example, "17:59:43,631 INFO  [STDOUT] Retrieving document at...".  These should be using Log4j.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira