[507] | 1 | These tests are the same as those found in the WSDLClientFileIssue_OldESB
|
---|
| 2 | Test 4 here is the same as test 3 there. It was just created from scratch
|
---|
| 3 | in GlassFishESB Release Candidate1 to see if the issue still exists and it does.
|
---|
| 4 |
|
---|
| 5 | Test 5 is identical to Test 1 from that test. It still does not work, but it gives
|
---|
| 6 | a different error message that seems to confirm the suspicion that I had that the
|
---|
| 7 | response from the client web service call is being confused by OpenESB to be the
|
---|
| 8 | response to the first web service. The message is as follows:
|
---|
| 9 |
|
---|
| 10 | Testcase: TestCase1(org.netbeans.modules.compapp.catd.ConfiguredTest): FAILED
|
---|
| 11 | [Jan 27, 2009 11:17:24 AM] The response is not identical to the expected output.
|
---|
| 12 | junit.framework.AssertionFailedError: [Jan 27, 2009 11:17:24 AM] The response is not identical to the expected output.
|
---|
| 13 | at org.netbeans.modules.compapp.catd.ConfiguredTest.checkExpectedOutput(ConfiguredTest.java:2240)
|
---|
| 14 | at org.netbeans.modules.compapp.catd.ConfiguredTest.checkExpectedOutput(ConfiguredTest.java:2122)
|
---|
| 15 | at org.netbeans.modules.compapp.catd.ConfiguredTest.testConcurrentSOAPRequest(ConfiguredTest.java:748)
|
---|
| 16 |
|
---|
| 17 |
|
---|
| 18 | ---------------------------------------------------------------------------------
|
---|
| 19 |
|
---|
| 20 |
|
---|
| 21 |
|
---|
| 22 |
|
---|
| 23 |
|
---|
| 24 |
|
---|
| 25 | Notes from the other file...
|
---|
| 26 |
|
---|
| 27 | These three composite applications illustrate two separate issues we are
|
---|
| 28 | having.
|
---|
| 29 |
|
---|
| 30 | Issue 1: Calling web service must be done in Thread
|
---|
| 31 | --------------------------------------------------
|
---|
| 32 | First, we have an issue where when we have an EJB Bean which calls a web service
|
---|
| 33 | from within the java code, the call will fail unless it is wrapped in a thread.
|
---|
| 34 |
|
---|
| 35 | Issue 2: Hard coded path to WSDL
|
---|
| 36 | ---------------------------------
|
---|
| 37 | Second, when we expose a web service in the NMR that is an EJB web service, and
|
---|
| 38 | where that EJB web service makes a Java based call to another web service, it
|
---|
| 39 | keeps a hard coded path to the WSDL that was used to create the client proxy
|
---|
| 40 | code, and when you deploy the composite application, it tries to find (at runtime)
|
---|
| 41 | the WSDL in the physical location on the machine it was compiled on, rather
|
---|
| 42 | than looking within the deployed location for the WSDL.
|
---|
| 43 |
|
---|
| 44 | Issue 3: Hand modification of jaxws-build.xml to get Schemas
|
---|
| 45 | -------------------------------------------------------------
|
---|
| 46 | There is a secondary question that we have.... Whenever we create an EJB web service
|
---|
| 47 | that we wrap with a composite application, in the EJB project, we have to add in
|
---|
| 48 | code to copy the XML Schemas to their appropriate location. if we do not put that
|
---|
| 49 | in, the EJB will not deploy.... This one we know how to work around, but we would
|
---|
| 50 | like to know why NetBeans is not taking care of this.
|
---|
| 51 |
|
---|
| 52 | NOTE: When running these projects, they call a UDDI web service. This web service
|
---|
| 53 | is exposed to the internet, so you should be able to run the tests directly....
|
---|
| 54 |
|
---|
| 55 | List of Projects:
|
---|
| 56 |
|
---|
| 57 | Issue 1: SampleService1EJB & SampleService1CA (Illistrates
|
---|
| 58 | ------------------------------------
|
---|
| 59 | This illustrates the issue when trying to access a web service through an EJB
|
---|
| 60 | and where the call to the web service is NOT done in a thread. To run this test
|
---|
| 61 | you should compile and deploy SampleService1CA. Run TestCase1. It will
|
---|
| 62 | say passed, but this may not be true. The only way to tell whether this passed
|
---|
| 63 | is to look at the glassfish output log. When it fails, you see the following error:
|
---|
| 64 |
|
---|
| 65 | HTTPBC-E00759: An exception occured while processing a reply message. The server sent HTTP status code -1: null
|
---|
| 66 | com.sun.xml.ws.client.ClientTransportException: The server sent HTTP status code -1: null
|
---|
| 67 | at com.sun.xml.ws.transport.http.client.HttpTransportPipe.checkStatusCode(HttpTransportPipe.java:203)
|
---|
| 68 | at com.sun.xml.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:177)
|
---|
| 69 | at com.sun.xml.xwss.XWSSClientPipe.process(XWSSClientPipe.java:118)
|
---|
| 70 | at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
|
---|
| 71 | at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:598)
|
---|
| 72 | at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:557)
|
---|
| 73 | at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:542)
|
---|
| 74 | at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:439)
|
---|
| 75 | at com.sun.xml.ws.client.Stub.process(Stub.java:222)
|
---|
| 76 | at com.sun.xml.ws.client.dispatch.DispatchImpl.doInvoke(DispatchImpl.java:180)
|
---|
| 77 | at com.sun.xml.ws.client.dispatch.DispatchImpl.invoke(DispatchImpl.java:206)
|
---|
| 78 | at com.sun.jbi.httpsoapbc.OutboundMessageProcessor.outboundCall(OutboundMessageProcessor.java:986)
|
---|
| 79 | at com.sun.jbi.httpsoapbc.OutboundMessageProcessor.dispatch(OutboundMessageProcessor.java:1017)
|
---|
| 80 | at com.sun.jbi.httpsoapbc.OutboundMessageProcessor.processRequestReplyOutbound(OutboundMessageProcessor.java:661)
|
---|
| 81 | at com.sun.jbi.httpsoapbc.OutboundMessageProcessor.processMessage(OutboundMessageProcessor.java:243)
|
---|
| 82 | at com.sun.jbi.httpsoapbc.OutboundAction.run(OutboundAction.java:63)
|
---|
| 83 | at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
|
---|
| 84 | at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
|
---|
| 85 | at java.lang.Thread.run(Thread.java:619)
|
---|
| 86 |
|
---|
| 87 | You can see the full output in: Output_SampleService1.txt. Please note that we have also seen a different error message
|
---|
| 88 | when running without a thread. I cannot recall the text of that message, it was in a different project, but pushing the
|
---|
| 89 | call to a thread resolved it.... I do notice the strange binary data in the trace messages - it makes me wonder if
|
---|
| 90 | what is happening by the HTTP binding component is that it is confusing the response of the encapsualted web service with
|
---|
| 91 | the outer one.
|
---|
| 92 |
|
---|
| 93 | Issue 1: SampleService2EJB & SampleService2CA
|
---|
| 94 | ----------------------------------------------
|
---|
| 95 | Before running this test, you must undeploy sample 1 above....
|
---|
| 96 | This project is identical to the previous one, except in this case a thread is created so that the
|
---|
| 97 | call to the web service from Java is done in an encapsulated thread. This one works. You can see
|
---|
| 98 | the output of this example in Output_SampleService2.txt.
|
---|
| 99 |
|
---|
| 100 | Issue 2: SampleService2EJB & SampleService2CA
|
---|
| 101 | ----------------------------------------------
|
---|
| 102 | This one uses the same project as the previous test to illustrate issue 2. To run this test, with
|
---|
| 103 | the SampleService2CA deployed, rename your WSDLInterfaces directory to some other name (i.e. WSDLInterfaces_renamed).
|
---|
| 104 | Now re-run the test. Since it can no longer find the WSDL in the "compiled" location, it will fail.
|
---|
| 105 | You can find the output of this one in Output_SampleService2_FailedLocation.txt.
|
---|
| 106 |
|
---|
| 107 | You will notice here that the errors are that it cannot find the WSDL in the specified location. It
|
---|
| 108 | is not looking in the deployed application area, but rather in the location where the file existed at
|
---|
| 109 | compile time.
|
---|
| 110 |
|
---|
| 111 | Issue 2: SampleService3EJB & SampleService3CA
|
---|
| 112 | ---------------------------------------------
|
---|
| 113 | Before running this test, you must undeploy sample 2 above....
|
---|
| 114 | In searching the web regarding this problem, we found several pages that described this as a known problem
|
---|
| 115 | with a work around. It defined the problem to be that the jaxws-build.xml file contained the following target:
|
---|
| 116 |
|
---|
| 117 | <target name="wsimport-client-uddi_v3_service" depends="wsimport-init,wsimport-client-check-uddi_v3_service" unless="wsimport-client-uddi_v3_service.notRequired">
|
---|
| 118 | <wsimport xendorsed="true" sourcedestdir="${build.generated.dir}/wsimport/client" extension="true" destdir="${build.generated.dir}/wsimport/binaries" wsdl="${basedir}/${meta.inf}/xml-resources/web-service-references/uddi_v3_service/wsdl/uddi_v3_service.wsdl" wsdlLocation="file:/C:/projects/nhinc/Current/Product/Production/Tutorials/WSDLClientFileIssue/WSDLInterfaces/src/wsdl/uddi_v3_service.wsdl" catalog="catalog.xml"/>
|
---|
| 119 | <copy todir="${classes.dir}">
|
---|
| 120 | <fileset dir="${build.generated.dir}/wsimport/binaries" includes="**/*.xml"/>
|
---|
| 121 | </copy>
|
---|
| 122 | </target>
|
---|
| 123 |
|
---|
| 124 | It stated that the problem is that it generates with an attribute in the wsimport called "wsdlLocation". This
|
---|
| 125 | is treated as a hard path... The recommendation on the web sites was to remove the wsdlLocation attribute
|
---|
| 126 | and that it would then fall back to using the "wsdl" attribute instead and that it will now be relative to the
|
---|
| 127 | deployed composite application. However, we found that this is not the case. To illustrate this, we copied the
|
---|
| 128 | target from the jaxws-build.xml file to the build.xml file (standard way of overriding targets). We then removed
|
---|
| 129 | the wsldLocation attribute. We saw a change in behavior, but it was not sufficient... It just changed the physical
|
---|
| 130 | path that was hard coded. Now rather than looking in
|
---|
| 131 | C:\projects\nhinc\Current\Product\Production\Tutorials\WSDLClientFileIssue\WSDLInterfaces\src\wsdl\uddi_v3_service.wsdl,
|
---|
| 132 | it now looks in:
|
---|
| 133 | C:\projects\nhinc\Current\Product\Production\Tutorials\WSDLClientFileIssue\SampleService3EJB\src\conf\xml-resources\web-service-references\uddi_v3_service\wsdl\uddi_v3_service.wsdl
|
---|
| 134 |
|
---|
| 135 | I have tried many different options to try to get this to use a relative path to no avail... When I look at the generated code, it
|
---|
| 136 | still tries to find the wsdl in this physical path.
|
---|
| 137 |
|
---|
| 138 | To reproduce this one, you deploy the composite application, then after it is deployed, you rename the directory where
|
---|
| 139 | it is looking for the wsdl (similar to the previous test). Rename the SampleService3EJB\src\conf\xml-resources\web-service-references to
|
---|
| 140 | some other name... and then run the test... Note that You could also deploy it in a glassfish environment that
|
---|
| 141 | does not have the development projets available at all... (Different machine altogether...).
|
---|
| 142 |
|
---|
| 143 | An example of the output is found in Output_SampleService3.txt
|
---|
| 144 |
|
---|
| 145 |
|
---|
| 146 |
|
---|