September 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2110) HTTPS Listener: Security realm needs to be flagged 'required'

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-2110?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-2110: -------------------------------------- I am not sure what you mean. This is marked as required in the schema, and in the model it is not nilable with no default value. > HTTPS Listener: Security realm needs to be flagged 'required' > ------------------------------------------------------------- > > Key: WFLY-2110 > URL: https://issues.jboss.org/browse/WFLY-2110 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Heiko Braun > Assignee: Stuart Douglas > Fix For: 8.0.0.CR1 > > > It's required to add an https listeners. Otherwise the add dialogs doesn't work (See HTTP > Listeners HTTPS > Add) -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2156) Upgrade scannotation to 1.0.3

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-2156?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-2156: -------------------------------------- Just FYI scannotation is not actually used (as we use Jandex instead), I only included it because I was worried about the possibility of runtime NoClassDefFoundErrors > Upgrade scannotation to 1.0.3 > ----------------------------- > > Key: WFLY-2156 > URL: https://issues.jboss.org/browse/WFLY-2156 > Project: WildFly > Issue Type: Feature Request > Components: REST > Affects Versions: 8.0.0.Alpha4 > Reporter: Weinan Li > Assignee: Stuart Douglas > > RESTEasy has a dependency on 1.0.3 of scannotation. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2180) Thread threads pools inherit security context of submitting threads

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-2180: ------------------------------------ Summary: Thread threads pools inherit security context of submitting threads Key: WFLY-2180 URL: https://issues.jboss.org/browse/WFLY-2180 Project: WildFly Issue Type: Bug Components: EE, EJB, Server, Web (Undertow) Affects Versions: 8.0.0.Alpha4 Reporter: Stuart Douglas Assignee: David Lloyd Some thread pool implementation will immediately create a new thread if work is submitted and there is not enough threads available to handle it. This newly created thread will inherit the access control context of the thread that is submitting the work, which essentially means that thread pool threads have a random access control context. This is the root cause of UNDERTOW-102, and likely other security manager related failures as well. I think that the best way to fix this is in the thread pool itself, as it should create the thread in a privileged block. We obviously cannot do this for JDK thread pools however. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2096) WeldApplicationFactory doesn't implement setApplication() correctly

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-2096?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-2096: ------------------------------------ Assignee: Stuart Douglas (was: Jozef Hartinger) > WeldApplicationFactory doesn't implement setApplication() correctly > ------------------------------------------------------------------- > > Key: WFLY-2096 > URL: https://issues.jboss.org/browse/WFLY-2096 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, JSF > Affects Versions: 8.0.0.Alpha4 > Reporter: Martin Kouba > Assignee: Stuart Douglas > > The problem is described in WELD-913. The fix was only applied to Weld servlet support [1] and not AS7/WildFly8 integration code (most probably because the target environment of the issue was Tomcat). > [1] > https://github.com/weld/core/blob/master/environments/servlet/core/src/ma... -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2179) Enforce permissions on deployment upload ops

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-2179: -------------------------------------- Summary: Enforce permissions on deployment upload ops Key: WFLY-2179 URL: https://issues.jboss.org/browse/WFLY-2179 Project: WildFly Issue Type: Sub-task Components: Domain Management Affects Versions: 8.0.0.Alpha4 Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 8.0.0.CR1 The handlers for the upload-deployment-[bytes|stream|url] ops are not triggering any permission checks. This is because they do not affect model and are not accessing the service registry. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1708) sun.security.rsa.RSAPrivateCrtKeyImpl cannot be cast to javax.crypto.SecretKey

by shen kim (JIRA)

[ https://issues.jboss.org/browse/JGRP-1708?page=com.atlassian.jira.plugin.... ] shen kim closed JGRP-1708. -------------------------- Resolution: Rejected > sun.security.rsa.RSAPrivateCrtKeyImpl cannot be cast to javax.crypto.SecretKey > ------------------------------------------------------------------------------ > > Key: JGRP-1708 > URL: https://issues.jboss.org/browse/JGRP-1708 > Project: JGroups > Issue Type: Bug > Environment: JDK1.7 Jgroups3.4.0.Beta1 > Reporter: shen kim > Assignee: Bela Ban > > When I used ENCRYPT with key_store like this: > <config xmlns="urn:org:jgroups" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.3.xsd"> > <TCP /> > <MPING /> > <MERGE2 /> > <FD /> > <VERIFY_SUSPECT /> > <ENCRYPT key_store_name="server.keystore" store_password="changeit" alias="tomcat"/> > <pbcast.NAKACK /> > <UNICAST3 /> > <pbcast.GMS /> > <UFC /> > <MFC /> > <STATS /> > <pbcast.STATE_SOCK /> > </config> > When I start the first Cluster it is OK, but when I start the second Cluster it throw: > Exception in thread "main" java.lang.ClassCastException: sun.security.rsa.RSAPrivateCrtKeyImpl cannot be cast to javax.crypto.SecretKey > at org.jgroups.protocols.ENCRYPT.initConfiguredKey(ENCRYPT.java:274) > at org.jgroups.protocols.ENCRYPT.init(ENCRYPT.java:234) > at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:848) > at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:467) > at org.jgroups.JChannel.init(JChannel.java:830) > at org.jgroups.JChannel.<init>(JChannel.java:158) > at org.jgroups.JChannel.<init>(JChannel.java:138) -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1708) sun.security.rsa.RSAPrivateCrtKeyImpl cannot be cast to javax.crypto.SecretKey

by shen kim (JIRA)

shen kim created JGRP-1708: ------------------------------ Summary: sun.security.rsa.RSAPrivateCrtKeyImpl cannot be cast to javax.crypto.SecretKey Key: JGRP-1708 URL: https://issues.jboss.org/browse/JGRP-1708 Project: JGroups Issue Type: Bug Environment: JDK1.7 Jgroups3.4.0.Beta1 Reporter: shen kim Assignee: Bela Ban When I used ENCRYPT with key_store like this: <config xmlns="urn:org:jgroups" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.3.xsd"> <TCP /> <MPING /> <MERGE2 /> <FD /> <VERIFY_SUSPECT /> <ENCRYPT key_store_name="server.keystore" store_password="changeit" alias="tomcat"/> <pbcast.NAKACK /> <UNICAST3 /> <pbcast.GMS /> <UFC /> <MFC /> <STATS /> <pbcast.STATE_SOCK /> </config> When I start the first Cluster it is OK, but when I start the second Cluster it throw: Exception in thread "main" java.lang.ClassCastException: sun.security.rsa.RSAPrivateCrtKeyImpl cannot be cast to javax.crypto.SecretKey at org.jgroups.protocols.ENCRYPT.initConfiguredKey(ENCRYPT.java:274) at org.jgroups.protocols.ENCRYPT.init(ENCRYPT.java:234) at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:848) at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:467) at org.jgroups.JChannel.init(JChannel.java:830) at org.jgroups.JChannel.<init>(JChannel.java:158) at org.jgroups.JChannel.<init>(JChannel.java:138) -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-278) ProtobufMarshaller throws ClassCastException when marshalling CDI proxied KieSession.

by Duncan Doyle (JIRA)

Duncan Doyle created DROOLS-278: ----------------------------------- Summary: ProtobufMarshaller throws ClassCastException when marshalling CDI proxied KieSession. Key: DROOLS-278 URL: https://issues.jboss.org/browse/DROOLS-278 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 6.0.0.CR3 Environment: Mac OS-X 1.0.8.5, Hotspot 1.7.0_40 Reporter: Duncan Doyle Assignee: Mark Proctor I have a CDI (Weld) @Producer which produces a KieSession. The KieSession is therefore proxied by a CDI/Weld proxy. When I try to marshall such a KieSession object, the ProtobufMarshaller throws the following ClassCastException: 01:21:07.505 [main] ERROR o.j.d.b.c.CdiSessionPersistenceTest - Error saving KieSession. java.lang.ClassCastException: org.jboss.weld.proxies.CommandExecutor$EntryPoint$KieRuntime$KieRuntimeEventManager$KieSession$ProcessEventManager$ProcessRuntime$RuleRuntime$StatefulProcessSession$StatefulRuleSession$WorkingMemoryEventManager$761192450$Proxy$_$$_WeldClientProxy cannot be cast to org.drools.core.impl.StatefulKnowledgeSessionImpl at org.drools.core.marshalling.impl.ProtobufMarshaller.marshall(ProtobufMarshaller.java:157) ~[drools-core-6.0.0.CR4-Pre1.jar:6.0.0.CR4-Pre1] at org.drools.core.marshalling.impl.ProtobufMarshaller.marshall(ProtobufMarshaller.java:148) ~[drools-core-6.0.0.CR4-Pre1.jar:6.0.0.CR4-Pre1] at org.jboss.ddoyle.brms.cep.ha.management.FileKieSessionLoader.save(FileKieSessionLoader.java:67) ~[classes/:na] at org.jboss.ddoyle.brms.cep.ha.management.FileKieSessionLoader.save(FileKieSessionLoader.java:37) ~[classes/:na] at org.jboss.ddoyle.brms.cep.ha.drools.session.SessionManager.saveKieSession(SessionManager.java:27) ~[classes/:na] at org.jboss.ddoyle.brms.cep.ha.drools.session.SessionManager$Proxy$_$$_WeldClientProxy.saveKieSession(SessionManager$Proxy$_$$_WeldClientProxy.java) ~[classes/:na] at org.jboss.ddoyle.brms.cdi.CdiSessionPersistenceTest.testCdiSessionPersistence(CdiSessionPersistenceTest.java:43) ~[test-classes/:na] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_40] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_40] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_40] at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_40] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) [junit-4.11.jar:na] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) [junit-4.11.jar:na] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) [junit-4.11.jar:na] at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) [junit-4.11.jar:na] at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) [junit-4.11.jar:na] at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) [junit-4.11.jar:na] at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) [junit-4.11.jar:na] at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) [junit-4.11.jar:na] at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) [junit-4.11.jar:na] at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) [junit-4.11.jar:na] at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) [junit-4.11.jar:na] at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) [junit-4.11.jar:na] at org.junit.runners.ParentRunner.run(ParentRunner.java:309) [junit-4.11.jar:na] at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) [surefire-junit4-2.10.jar:2.10] at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) [surefire-junit4-2.10.jar:2.10] at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) [surefire-junit4-2.10.jar:2.10] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_40] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_40] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_40] at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_40] at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) [surefire-api-2.10.jar:2.10] at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) [surefire-booter-2.10.jar:2.10] at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) [surefire-booter-2.10.jar:2.10] at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107) [surefire-booter-2.10.jar:2.10] at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) [surefire-booter-2.10.jar:2.10] I've created a reproducer which shows the behaviour: https://github.com/DuncanDoyle/DroolsSessionCdiClassCastException Just run 'mvn clean test' in the project. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2178) exception in distributable webapp leads to infinispan lock contention

by Thomas Frühbeck (JIRA)

[ https://issues.jboss.org/browse/WFLY-2178?page=com.atlassian.jira.plugin.... ] Thomas Frühbeck commented on WFLY-2178: --------------------------------------- see UNDERTOW-107 for the reason of ConcurrentModificationException > exception in distributable webapp leads to infinispan lock contention > ---------------------------------------------------------------------- > > Key: WFLY-2178 > URL: https://issues.jboss.org/browse/WFLY-2178 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.0.0.Beta1 > Reporter: Thomas Frühbeck > Assignee: Paul Ferraro > Attachments: lockContention_server.log > > > Exception in session.invalidate leads to: > ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-23) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutExceptio > n: Unable to acquire lock after [15 seconds] on key [FIsDATdNvtWFPLx-x-00_6x0] for requestor [GlobalTransaction:<storage/web>:171:local]! Lock held by [GlobalTransaction:<storage/web>:170:local] > server.log attached -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2178) exception in distributable webapp leads to infinispan lock contention

by Thomas Frühbeck (JIRA)

Thomas Frühbeck created WFLY-2178: ------------------------------------- Summary: exception in distributable webapp leads to infinispan lock contention Key: WFLY-2178 URL: https://issues.jboss.org/browse/WFLY-2178 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 8.0.0.Beta1 Reporter: Thomas Frühbeck Assignee: Paul Ferraro Attachments: lockContention_server.log Exception in session.invalidate leads to: ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-23) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutExceptio n: Unable to acquire lock after [15 seconds] on key [FIsDATdNvtWFPLx-x-00_6x0] for requestor [GlobalTransaction:<storage/web>:171:local]! Lock held by [GlobalTransaction:<storage/web>:170:local] server.log attached -- 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

12 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2013