[ https://jira.jboss.org/jira/browse/JBAS-7882?page=com.atlassian.jira.plug... ] Petr H updated JBAS-7882: ------------------------- Attachment: IAIKTest.ear testcase ear -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBAS-7882?page=com.atlassian.jira.plug... ] Petr H updated JBAS-7882: ------------------------- Attachment: server-forceVfsJar.log log with workaround jboss.vfs.forceVfsJar=true applies - issue doesn't occur, correct jar location returned: Provider code base: file:/tmp/nestedjar2481829661547119990.tmp -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBAS-7882?page=com.atlassian.jira.plug... ] Petr H updated JBAS-7882: ------------------------- Description: We've got applications which use the IAIK JCE provider (http://jce.iaik.tugraz.at/sic/Products/Core-Crypto-Toolkits/JCA-JCE) whose library is included directly in our application. On JBoss AS 5 and later, we can't use this provider as usually. The new VFS mechanism seems to break the path determination to the IAIK provider library (needed to determine provider code base) - it still points into the ear/war structure inside the server deploy directory but as all this is packed into one ear file, the provider verification.fails because of unsigned ear/war and thus the following exception is thrown: 2010-04-01 15:04:20,034 INFO [STDOUT] (http-0.0.0.0-8180-1) Provider code base: jar:file:/opt/jboss-5.1.0.GA/server/test1/deploy/IAIKTest.ear!/IAIKTestWeb.war ... 2010-04-01 15:04:20,890 ERROR [STDERR] (http-0.0.0.0-8180-1) java.lang.SecurityException: JCE cannot authenticate the provider IAIK 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.Cipher.getInstance(DashoA13*..) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.Cipher.getInstance(DashoA13*..) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at iaik.test.ControllerServlet.service(ControllerServlet.java:123) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:905) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:592) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2036) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at java.lang.Thread.run(Thread.java:619) 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) Caused by: java.util.jar.JarException: Cannot parse jar:file:/opt/jboss-5.1.0.GA/server/test1/deploy/IAIKTest.ear!/IAIKTestWeb.war 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.SunJCE_c.a(DashoA13*..) 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.SunJCE_b.b(DashoA13*..) 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.SunJCE_b.a(DashoA13*..) 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) ... 24 more This works when one of tho three mentioned workarounds is used. The most interesting of course is the third workaround for which the code base corectly points to the temporary IAIK library instance in the java.io.tmpdir: 2010-04-01 15:09:51,291 INFO [STDOUT] (http-0.0.0.0-8180-1) Provider code base: file:/tmp/nestedjar2481829661547119990.tmp I'll attach a simple testcase ear (IAIKTest.ear) which contains an evaluation version of IAIK provider library (thanks for permission to the IAIK authors) and a simple servlet (including source) which demonstrates the problem. All you need to do is to have the unrestricted JCE policy files installed in your JRE and then just put the IAIKTest.ear into the deploy directory, start the JBoss instance and access the test servlet URL in browser, for example: http://localhost:8080/IAIKTestWeb/ControllerServlet On init (which happens on start) it will register the IAIK provider On service (after you access it in browser) it will attempt to get some cipher instance and here it fails. I'll also attach two log files covering the problem: - server-default.log with default server setup where the issue occurs - server-forceVfsJar.log with jboss.vfs.forceVfsJar=true where the issue doesn't occur Also I think this is more generic problem because we had similar issues, where some jar or resource location was pointing to the packed ear/war structure inside the deploy directory instead of those VFS temporary locations, with our own code (when attemting to obtain full path) and had to perform some modifications in order to make it working. The same set of workarounds could resolve these issues as well. was: We've got applications which use the IAIK JCE provider (http://jce.iaik.tugraz.at/sic/Products/Core-Crypto-Toolkits/JCA-JCE) whose library is included directly in our application. On JBoss AS 5 and later, we can't use this provider as usually. The new VFS mechanism seems to break the path determination to the IAIK provider library (needed to determine provider code base) - it still points into the ear/war structure inside the server deploy directory but as all this is packed into one ear file, the provider verification.fails because of unsigned ear/war and thus the following exception is thrown: 2010-04-01 15:04:20,890 ERROR [STDERR] (http-0.0.0.0-8180-1) java.lang.SecurityException: JCE cannot authenticate the provider IAIK 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.Cipher.getInstance(DashoA13*..) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.Cipher.getInstance(DashoA13*..) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at iaik.test.ControllerServlet.service(ControllerServlet.java:123) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:905) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:592) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2036) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at java.lang.Thread.run(Thread.java:619) 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) Caused by: java.util.jar.JarException: Cannot parse jar:file:/opt/jboss-5.1.0.GA/server/test1/deploy/IAIKTest.ear!/IAIKTestWeb.war 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.SunJCE_c.a(DashoA13*..) 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.SunJCE_b.b(DashoA13*..) 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.SunJCE_b.a(DashoA13*..) 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) ... 24 more This works when one of tho three mentioned workarounds is used. The most interesting of course is the third workaround for which the code base corectly points to the temporary IAIK library instance in the java.io.tmpdir: 2010-04-01 15:09:51,291 INFO [STDOUT] (http-0.0.0.0-8180-1) Provider code base: file:/tmp/nestedjar2481829661547119990.tmp I'll attach a simple testcase ear (IAIKTest.ear) which contains an evaluation version of IAIK provider library (thanks for permission to the IAIK authors) and a simple servlet (including source) which demonstrates the problem. All you need to do is to have the unrestricted JCE policy files installed in your JRE and then just put the IAIKTest.ear into the deploy directory, start the JBoss instance and access the test servlet URL in browser, for example: http://localhost:8080/IAIKTestWeb/ControllerServlet On init (which happens on start) it will register the IAIK provider On service (after you access it in browser) it will attempt to get some cipher instance and here it fails. I'll also attach two log files covering the problem: - server-default.log with default server setup where the issue occurs - server-forceVfsJar.log with jboss.vfs.forceVfsJar=true where the issue doesn't occur Also I think this is more generic problem because we had similar issues, where some jar or resource location was pointing to the packed ear/war structure inside the deploy directory instead of those VFS temporary locations, with our own code (when attemting to obtain full path) and had to perform some modifications in order to make it working. The same set of workarounds could resolve these issues as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBAS-7882?page=com.atlassian.jira.plug... ] Tomas Gustavsson commented on JBAS-7882: ---------------------------------------- I believe the issue only occurs with Sun/Oracle JDK though and not OpenJDK right? I think that OpenJDK does not verify the signature on jce's. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBAS-7882?page=com.atlassian.jira.plug... ] Dimitris Andreadis reassigned JBAS-7882: ---------------------------------------- Assignee: Marko Strukelj Maybe Marko can take a look? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBAS-7882?page=com.atlassian.jira.plug... ] Marko Strukelj commented on JBAS-7882: -------------------------------------- The problem is with jar:file: url. SunJCE receives this url: - jar:file:/opt/jboss-5.1.0.GA/server/test1/deploy/IAIKTest.ear!/IAIKTestWeb.war from ClassLoader which gets it from VFS FileHandler with vfs URL: - vfszip:/opt/jboss-5.1.0.GA/server/test1/deploy/IAIKTest.ear/IAIKTestWeb.war/WEB-INF/lib/iaik_jce_full.jar There is clearly a loss of information here. The problem is that vfszip URLs for nested jars can't be mapped into jar:file form directly. VFS only converts to the first nested level (in this case IAIKTestWeb.war), as jar:file simpy doesn't support nested archives, it in fact interprets our jar:file URL as IAIKTest.ear containing IAIKTestWeb.war file entry, when what we really want here is iaik_jce_full.jar. The only way for it to work is to expose the temporary location of the extracted nested jar. And this would only work for forceCopy mode (which is enabled by default). I'm attaching a patch - against branch_2_1 (http://anonsvn.jboss.org/repos/jbossas/projects/vfs/branches/Branch_2_1). We should add some tests for this ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBAS-7882?page=com.atlassian.jira.plug... ] Marko Strukelj commented on JBAS-7882: -------------------------------------- Indeed it does: 22:05:49,220 ERROR [STDERR] java.lang.SecurityException: JCE cannot authenticate the provider IAIK 22:05:49,221 ERROR [STDERR] at javax.crypto.Cipher.getInstance(DashoA13*..) 22:05:49,221 ERROR [STDERR] at javax.crypto.Cipher.getInstance(DashoA13*..) 22:05:49,221 ERROR [STDERR] at iaik.test.ControllerServlet.service(ControllerServlet.java:123) 22:05:49,221 ERROR [STDERR] at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) 22:05:49,221 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:336) 22:05:49,221 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) 22:05:49,222 ERROR [STDERR] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:293) 22:05:49,222 ERROR [STDERR] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) 22:05:49,222 ERROR [STDERR] at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183) 22:05:49,222 ERROR [STDERR] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95) 22:05:49,222 ERROR [STDERR] at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) 22:05:49,223 ERROR [STDERR] at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) 22:05:49,223 ERROR [STDERR] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) 22:05:49,223 ERROR [STDERR] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) 22:05:49,224 ERROR [STDERR] at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) 22:05:49,224 ERROR [STDERR] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) 22:05:49,224 ERROR [STDERR] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) 22:05:49,224 ERROR [STDERR] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:872) 22:05:49,224 ERROR [STDERR] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) 22:05:49,225 ERROR [STDERR] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) 22:05:49,225 ERROR [STDERR] at java.lang.Thread.run(Thread.java:619) 22:05:49,225 ERROR [STDERR] Caused by: java.util.jar.JarException: Cannot parse vfs:/C:/opt/java/jboss-6.0.0.20100429-M3/server/default/deploy/IAIKTest.ear/IAIKTestWeb.war/WEB-INF/lib/iaik_jce_full.jar/ 22:05:49,226 ERROR [STDERR] at javax.crypto.SunJCE_c.a(DashoA13*..) 22:05:49,226 ERROR [STDERR] at javax.crypto.SunJCE_b.b(DashoA13*..) 22:05:49,226 ERROR [STDERR] at javax.crypto.SunJCE_b.a(DashoA13*..) 22:05:49,226 ERROR [STDERR] ... 21 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-7882?page=com.atlassian.jira.plugin.sy... ] jaikiran pai updated JBAS-7882: ------------------------------- Affects Version/s: 6.0.0.M3 -- 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

[ https://jira.jboss.org/browse/JBAS-7882?page=com.atlassian.jira.plugin.sy... ] Ales Justin commented on JBAS-7882: ----------------------------------- VFS has a notion of TempStore, which can also create predictable locations. * http://anonsvn.jboss.org/repos/jbossas/projects/vfs/branches/Branch_2_2/s... -- 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

[ https://issues.jboss.org/browse/JBAS-7882?page=com.atlassian.jira.plugin.... ] Tomas Gustavsson commented on JBAS-7882: ---------------------------------------- None of the workarounds work for JBoss 6.0.0 Final, so this is very bad. I.e. JCE providers can not be used at al with Oracle JDK with JBoss 6.0.0. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-7882?page=com.atlassian.jira.plugin.... ] Petr H commented on JBAS-7882: ------------------------------ Yeah, I also think expanding isn't the right approach as this should be a deployment "transparent". Even the workaround involving moving the JCE provider lib into server lib directory didn't work for JBAS 6.0? Then I don't think expanding will work though and perhaps there's another issue introduced in 6.0 series. What do you get when printing out the provider code base? What may be related is one issue we encountered with hibernate persistence unit loading (we do it ourselves) and it didn't work the way it worked in 5.x series. First there was a change from vfszip to vfs protocol, second what hibernate was getting when trying to read from a jar via vfs protocol was some mess, a workaround we applied was that we override vfs to jar protocol in all paths passed to hibernate for loading persistence units and then it works, but this is kinda ugly. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-7882?page=com.atlassian.jira.plugin.... ] Ales Justin reassigned JBAS-7882: --------------------------------- Assignee: John Bailey (was: Marko Strukelj) Assigning it to John, since this is VFS3 issue. Any input from DML is welcome. ;-) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-7882?page=com.atlassian.jira.plugin.... ] Mats Andersson commented on JBAS-7882: -------------------------------------- I have tried this workaround: http://www.randombugs.com/java/javalangsecurityexception-jce-authenticate... and it works on Jboss AS 6 and Sun/Oracle JDK (1.6.0_22 tested) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-7882?page=com.atlassian.jira.plugin.... ] jaikiran pai edited comment on JBAS-7882 at 2/18/11 6:21 AM: ------------------------------------------------------------- Just a FYI - the workaround mentioned in that blog http://www.randombugs.com/java/javalangsecurityexception-jce-authenticate... is _not_ recommended since you end up adding these jars to the JRE installation. If you upgrade the JRE or move your application to some other system, then this is going to fail. Changing/adding anything to the JRE installation isn't really the best thing to do. was (Author: jaikiran): Just a FYI - the workaround mentioned in that blog http://www.randombugs.com/java/javalangsecurityexception-jce-authenticate... is really recommend since you end up adding these jars to the JRE installation. If you upgrade the JRE or move your application to some other system, then this is going to fail. Changing/adding anything to the JRE installation isn't really the best thing to do. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-7882?page=com.atlassian.jira.plugin.... ] David Lloyd commented on JBAS-7882: ----------------------------------- I've just tested it and the same exception occurs in AS 7. However running the test under openjdk 7 (unstable), it works. This is troubling because the JCE code in which the exception occurs has no source listing available under Sun's JDK, whereas openjdk has sources. Thus, it is going to be challenging to debug this issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-7882?page=com.atlassian.jira.plugin.... ] David Lloyd commented on JBAS-7882: ----------------------------------- ...or at least, using the "real" location for code sources as opposed to the virtual location... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-7882?page=com.atlassian.jira.plugin.... ] David Lloyd updated JBAS-7882: ------------------------------ Fix Version/s: (was: 7.0.0.CR1) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-7882?page=com.atlassian.jira.plugin.... ] Mike Hutton commented on JBAS-7882: ----------------------------------- As of October 2011, the only workaround for this issue that works for us (Bouncy Castle provider, AS 6.1.0 final) is still the one described by Mats Andersson in http://www.randombugs.com/java/javalangsecurityexception-jce-authenticate.... Obviously Jaikiran's warnings about the substantial drawbacks with this workaround apply, but it's the only way that works for us. If there is a better work around for AS 6.1.0, please let us know. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-7882?page=com.atlassian.jira.plugin.... ] David Lloyd commented on JBAS-7882: ----------------------------------- This issue should be fixed in the upcoming 7.1 release. See AS7-308. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-7882?page=com.atlassian.jira.plugin.... ] David Lloyd commented on JBAS-7882: ----------------------------------- The 7.1 fix doesn't need to, no. From what I understand, the code source in this case is used to open and inspect the JAR file only. It is however also possible to deploy a JAR from a filesystem location; in this case you would know the URL in advance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-7882?page=com.atlassian.jira.plugin.... ] Ales Justin commented on JBAS-7882: ----------------------------------- VFS3 doesn't support this flag any more. And VFS3 is what's used in AS7.x. AS7 modules do not use VFS, so putting BC there might work? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-7882?page=com.atlassian.jira.plugin.... ] george zheng commented on JBAS-7882: ------------------------------------ Hi Peter, I have the same problem for BC. Do you mind posting your code for module definition and steps for adding module to configuration? Thanks in advance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-7882?page=com.atlassian.jira.plugin.... ] george zheng commented on JBAS-7882: ------------------------------------ It works like a charm! Thank you so much!!! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-7882?page=com.atlassian.jira.plugin.... ] george zheng commented on JBAS-7882: ------------------------------------ Instead of setup bouncycastle as a global module, can it be setup at application level? Such as at jboss-deployment-structure.xml? People have the concerns that a global module may have impacts on other applications which are running on the same JBoss AS. Any help are highly appreciated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-7882?page=com.atlassian.jira.plugin.... ] Ales Justin resolved JBAS-7882. ------------------------------- Resolution: Done Looks like this is just fine with AS7 and its modular env. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-7882?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on JBAS-7882: ---------------------------------------- Don't re-open resolved issues - instead create a new issue under the AS7 project. You can always link the issues together to show they are related. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira