Hi Sameer No problem, here's the complete echoserv directory under wwwroot, source and binary. It's fine to copy to the list - I'll re-subscribe to pick up any comments. BTW, I should have stated the JRE version - for completeness it's 1.5.0_06-b05. Thanks Rick -----Original Message----- From: Sameer Tyagi [mailto:Sameer.Tyagi@Sun.COM] Sent: 16 August 2006 12:53 To: Jones, Rick Subject: Re: [Issue 13] Problem running WS client in Applet It would be helpful if you could send the endpoint along also. I can deploy in IIS if you like Also is it ok if I copy further replies to the users@jax-ws list ? /s Jones, Rick wrote:Hi Sameer Thanks for looking at this bug report, and having revisited the problem again I agree that it works in the simple case. However, we have a slightly more complex scenario where the applet dynamically loads another jar containing the web-service client code. In this situation I can't get it to work. It hadn't occcured to me that this was the root of the problem, as this technique does not cause any issues using JWSDP 1.x. I've attached some code to demonstrate this. I'ts the relevant bits of our application stripped down for simplicity. The WSDL is in the JWSApplet directory - it's a trivial "echo" service. I haven't included the service itself, as we build services using .Net to run under IIS, which I guess won't be much help to you! At top level in the zip you have two jars, and an HTML file that loads an applet. The applet is in jwstest.jar, when started it loads another class using the URL to jwsext.jar. Clicking the applet button calls the loaded class, which connects to the service. Jwsext.jar includes the stub code generated by wsimport. In this configuration, the connection throws an exception in RuntimeModeler, as I reported. The jwsdp jars are loaded using a cache_archive parameter in the applettag.I've found that it's only necessary to load jaxws-rt.jar, this automatically chains the other required jars. It makes no difference if all the jars are specified, or what path they're in, or what flavour of cache_archive[_ex] is used. I've included these jars (signed) in the zip. All the source is in the JWSApplet directory, including a Jbuilder project file (if that's any help). The jwstest jar contains only the jwstest package, the jwsext jar contains all the other packages. Neither jar includes any dependencies from JWSDP (it doesn't make any difference if you include them). If you link the stub code (the echoserv package) into the applet rather than the extension, it works, but that is not an option for our situation. The point is that we supply a compiled applet as part of a product, and users can build extensions themselves (extensions have a lot of purposes, calling a web service is just one application). The extension jar is loaded using the ExtensionLoader class in jwstest, this makes use of URLClassLoader, subclassed so as to enable AllPermissions (the complete code checks that the extension jar is signed, this has been omitted for simplicity). I can't think of any other way to load the extension that might overcome the problem. As I said, this configuration works fine using JWSDP 1.x, given stub code created by wscompile, and with cache_archive loading the appropriate set of jars. We'd like users who build extensions to have the option to work with JWSDP-2. Is there something in JWSDP that needs fixing for this to work, or is there a way of loading the extension that will work better? Your advice would be much appreciated. Best regards Rick Jones Developer Support Manager Sage Sage House Wharfedale Road Winnersh Wokingham Berkshire RG41 5RD Switchboard: +44 118 927 0100 e-mail: rick.jones@sage.com Web Site: http://www.sage.co.uk -----Original Message----- From: sameer_t@dev.java.net [mailto:sameer_t@dev.java.net] Sent: 15 July 2006 13:14 To: Jones, Rick Subject: [Issue 13] Problem running WS client in Applet https://jax-ws.dev.java.net/issues/show_bug.cgi?id=13 User sameer_t changed the following: What |Old value |New value ======================================================================= ===== ==== Status|NEW |RESOLVED ----------------------------------------------------------------------- ----- ---- Resolution| |WONTFIX ----------------------------------------------------------------------- ----- ---- ------- Additional comments from sameer_t@dev.java.net Thu Jul 13 19:48:09 +0000 2006 ------- Was unable to reproduce this particular problem. It +may be related to how the Jar is created by the user and potentially a missing class file. An example demonstrating how an applet can be used to access the endpoint can be accessed here http://blogs.sun.com/roller/page/sameert?entry=accessing_jax_ws_endpoin ts_fr om
(image/jpeg attachment: screenshot.JPG)