[Bug 57091] Websockets cannot be used in Windows applet plugin environments based on Oracle Java7
https://issues.apache.org/bugzilla/show_bug.cgi?id=57091 --- Comment #7 from Niklas Hallqvist --- (In reply to Mark Thomas from comment #6) > Thanks for the test case. Very helpful. > > I can repeat this issue with Java 8 and Java 7 and I have applied your > suggested patch to 8.0.x for 8.0.15 onwards and 7.0.x for 7.0.57 onwards. > > On a related topic, would it be helpful at all if the Tomcat JARs were > signed by the ASF (we recently started to use Symantec's code signing > service). If this would be useful, please open a new enhancement request and > we'll figure out how to fit JSAR signing into the build process. Sorry I forgot to tell the tomcat jars needed to be signed as well. I am not sure it will be helpful, maybe it will now, but at least at some point in time, mixed signers were not working too well in our applet setups, so we decided sign all jars ourselves, 3rd party or not, with our own certificate as a standard practice these days. Of course we would have the potential to verify the jars' origin if they were signed, but we would still overwrite the signature with our own before deployment. Thanks for including the fix, this way I don't need to have a customized tomcat version for our needs. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57091] Websockets cannot be used in Windows applet plugin environments based on Oracle Java7
https://issues.apache.org/bugzilla/show_bug.cgi?id=57091 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Mark Thomas --- Thanks for the test case. Very helpful. I can repeat this issue with Java 8 and Java 7 and I have applied your suggested patch to 8.0.x for 8.0.15 onwards and 7.0.x for 7.0.57 onwards. On a related topic, would it be helpful at all if the Tomcat JARs were signed by the ASF (we recently started to use Symantec's code signing service). If this would be useful, please open a new enhancement request and we'll figure out how to fit JSAR signing into the build process. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57091] Websockets cannot be used in Windows applet plugin environments based on Oracle Java7
https://issues.apache.org/bugzilla/show_bug.cgi?id=57091 --- Comment #5 from Mark Thomas --- A note for folks trying to reproduce this, the Tomcat JARs need to be signed as well. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57091] Websockets cannot be used in Windows applet plugin environments based on Oracle Java7
https://issues.apache.org/bugzilla/show_bug.cgi?id=57091 --- Comment #4 from Niklas Hallqvist --- Created attachment 32117 --> https://issues.apache.org/bugzilla/attachment.cgi?id=32117&action=edit A simple websocket client A simple websocket client test. Name it se/appli/test/WebsocketClientTest.java Compile, put in a jar, sign, call it test-signed.jar. Install it somewhere in a web-catalog along with an html-file like: WebsocketClientTest Alter the uri-parameter to somewhere a websocket will reply. Any websocket service that provides a greeting (e.g. an hello world websocket test) will suffice. Also install the foloowing jar files in there: websocket-api.jar tomcat-websocket.jar tomcat-util.jar tomcat-juli.jar Fire up a browser on a MS Windows box with a JRE7 installed, whcih is trusting the key you signed the applet with. Load the HTML file. Watch the AccessControlException come up in the console. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57091] Websockets cannot be used in Windows applet plugin environments based on Oracle Java7
https://issues.apache.org/bugzilla/show_bug.cgi?id=57091 --- Comment #3 from Mark Thomas --- A test case would be helpful, thank you. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57091] Websockets cannot be used in Windows applet plugin environments based on Oracle Java7
https://issues.apache.org/bugzilla/show_bug.cgi?id=57091 --- Comment #2 from Niklas Hallqvist --- (In reply to Mark Thomas from comment #1) > Does this still work if you narrow the doPrivileged() block to just the > setContextClassLoader() call? If so provide an updated patch and I'll apply > it. If not, why not? Actually I haven't tested that, I may do that toorrow localtime (UTC+2). But... I know for a fact that the AccessController failed other operations before that, inside the Thread constructor, but the exceptions were masked by inner try-clauses. In a normal AccessController setup they wouldn't have failed, which is why I covered the whole thing in the doPrivileged. As the problem is really that the method is called with the wrong AccessController setup established for all of the duraton, I thought it most safe to actually cover all of the code, even if not strictly required at this moment. But as I said, I may do the tests tomorrow. I have a testcase btw, but in order to run it you need to sign the code and trust the ceritifcate in the browser which will run the test. If you want it I can make a package. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57091] Websockets cannot be used in Windows applet plugin environments based on Oracle Java7
https://issues.apache.org/bugzilla/show_bug.cgi?id=57091 Mark Thomas changed: What|Removed |Added OS||All --- Comment #1 from Mark Thomas --- Does this still work if you narrow the doPrivileged() block to just the setContextClassLoader() call? If so provide an updated patch and I'll apply it. If not, why not? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
