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