March 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SECURITY-805) Overload SecurityVaultFactory.get() to be able to specify the classloader

by Peter Skopek (JIRA)

[ https://issues.jboss.org/browse/SECURITY-805?page=com.atlassian.jira.plug... ] Peter Skopek resolved SECURITY-805. ----------------------------------- Fix Version/s: PicketBox_4_0_21.Beta2 Resolution: Done > Overload SecurityVaultFactory.get() to be able to specify the classloader > ------------------------------------------------------------------------- > > Key: SECURITY-805 > URL: https://issues.jboss.org/browse/SECURITY-805 > Project: PicketBox > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: PicketBox_4_0_21.Beta2 > > Attachments: SECURITY-805-2.diff, SECURITY-805.diff > > > To work better with modular class loading in WF -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (AS7-4260) Occurences of "Exception acquiring ownership of X (via SharedLocalYieldingClusterLockManager)"

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/AS7-4260?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar commented on AS7-4260: ---------------------------------- [~vishalkumar375] so upgrade to newer version that has this fixed. > Occurences of "Exception acquiring ownership of X (via SharedLocalYieldingClusterLockManager)" > ---------------------------------------------------------------------------------------------- > > Key: AS7-4260 > URL: https://issues.jboss.org/browse/AS7-4260 > Project: Application Server 7 > Issue Type: Bug > Components: Clustering > Affects Versions: 7.1.1.Final > Reporter: Radoslav Husar > Assignee: Paul Ferraro > Labels: JBAS018080, as713tracking > Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final) > > Attachments: SessionTravel.gif, view-perf18.log, view-perf19.log, view-perf20.log, view-perf21.log > > > There are often occurrences of "Exception acquiring ownership of X": > During shutdown, using dist: > {noformat} > 13:09:28,290 WARN [org.apache.catalina.session.ManagerBase] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) JBAS018080: Standard expiration of session qLQps+CQJxEi6pJTBSzis0g3 failed; switching to a brute force cleanup. Problem is JBAS018060: Exception acquiring ownership of qLQps+CQJxEi6pJTBSzis0g3 > {noformat} > During server crash, using repl: > {noformat} > 12:55:49,556 INFO [org.jboss.as.clustering.impl.CoreGroupCommunicationService.ejb] (Incoming-2,null) JBAS010248: New cluster view for partition ejb: 6 (org.jboss.as.clustering.impl.CoreGroupCommunicationService$GroupView@327579f6 delta: -1, merge: false) > 12:55:49,557 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,null) ISPN000094: Received new cluster view: [perf21/ejb|6] [perf21/ejb, perf20/ejb, perf18/ejb] > 12:56:31,694 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host]] (ajp-perf20-10.16.90.58-8009-211) Exception sending request initialized lifecycle event to listener instance of class org.jboss.weld.servlet.WeldListener: java.lang.RuntimeException: JBAS018060: Exception acquiring ownership of MvwC8KGWTuKPjD1-JjLW7URZ > at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:528) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > at org.jboss.as.web.session.ClusteredSession.expire(ClusteredSession.java:1260) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > at org.jboss.as.web.session.ClusteredSession.isValid(ClusteredSession.java:1208) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > at org.jboss.as.web.session.ClusteredSession.isValid(ClusteredSession.java:598) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > at org.jboss.as.web.session.DistributableSessionManager.add(DistributableSessionManager.java:917) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > at org.jboss.as.web.session.DistributableSessionManager.loadSession(DistributableSessionManager.java:1407) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:686) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:85) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > at org.apache.catalina.connector.Request.doGetSession(Request.java:2618) [jbossweb-7.0.13.Final.jar:] > at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.13.Final.jar:] > at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:841) [jbossweb-7.0.13.Final.jar:] > at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.getSession(LazySessionBeanStore.java:72) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] > at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.<init>(LazySessionBeanStore.java:58) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] > at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:31) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] > at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:16) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] > at org.jboss.weld.servlet.WeldListener.requestInitialized(WeldListener.java:134) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143) [jbossweb-7.0.13.Final.jar:] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:] > at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505) [jbossweb-7.0.13.Final.jar:] > at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:445) [jbossweb-7.0.13.Final.jar:] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:] > at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30] > Caused by: org.jboss.as.clustering.lock.TimeoutException: JBAS010223: Cannot acquire lock //default-host//clusterbench/MvwC8KGWTuKPjD1-JjLW7URZ from cluster > at org.jboss.as.clustering.lock.SharedLocalYieldingClusterLockManager.lock(SharedLocalYieldingClusterLockManager.java:439) > at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.acquireSessionOwnership(DistributedCacheManager.java:372) > at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:520) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > ... 23 more > {noformat} -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2957) Refactor the SSL services within the security realms so that key and trust managers are injected instead of stores.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-2957?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-2957. ------------------------------------ Resolution: Done > Refactor the SSL services within the security realms so that key and trust managers are injected instead of stores. > ------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-2957 > URL: https://issues.jboss.org/browse/WFLY-2957 > Project: WildFly > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 8.0.1.Final > > > To cope with things like being able to reload trust stores after files have been modified some implementation details regarding file handling have leaked slightly into the SSLIdentityService which represents the servers identity - instead the key and trust manager instances should be injected. -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-447) Deadlock when marshalling session using WM listeners and fireUntilHalt

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-447?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-447. -------------------------------- Resolution: Won't Fix Invoking fireX inside an event is a bad practice and should be always avoided. In particular, since at the moment some WM events callback are invoked while holding locks on the WM, trying to execute any write operation of the WM itself can inevitably lead to a deadlock. > Deadlock when marshalling session using WM listeners and fireUntilHalt > ---------------------------------------------------------------------- > > Key: DROOLS-447 > URL: https://issues.jboss.org/browse/DROOLS-447 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.1.Final, 6.1.0.Beta1 > Reporter: Davide Sottara > Assignee: Mario Fusco > Fix For: 6.1.0.Final > > -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-447) Deadlock when marshalling session using WM listeners and fireUntilHalt

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-447?page=com.atlassian.jira.plugin... ] Mario Fusco reassigned DROOLS-447: ---------------------------------- Assignee: Mario Fusco (was: Edson Tirelli) > Deadlock when marshalling session using WM listeners and fireUntilHalt > ---------------------------------------------------------------------- > > Key: DROOLS-447 > URL: https://issues.jboss.org/browse/DROOLS-447 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.1.Final, 6.1.0.Beta1 > Reporter: Davide Sottara > Assignee: Mario Fusco > Fix For: 6.1.0.Final > > -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (AS7-4260) Occurences of "Exception acquiring ownership of X (via SharedLocalYieldingClusterLockManager)"

by vishal kumar (JIRA)

[ https://issues.jboss.org/browse/AS7-4260?page=com.atlassian.jira.plugin.s... ] vishal kumar commented on AS7-4260: ----------------------------------- Hi, We are facing the exactly same issue, can you please help in finding out the route cause. We are having two jboss in standalone cluster , they are giving this particular issue while using the application. Thanks > Occurences of "Exception acquiring ownership of X (via SharedLocalYieldingClusterLockManager)" > ---------------------------------------------------------------------------------------------- > > Key: AS7-4260 > URL: https://issues.jboss.org/browse/AS7-4260 > Project: Application Server 7 > Issue Type: Bug > Components: Clustering > Affects Versions: 7.1.1.Final > Reporter: Radoslav Husar > Assignee: Paul Ferraro > Labels: JBAS018080, as713tracking > Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final) > > Attachments: SessionTravel.gif, view-perf18.log, view-perf19.log, view-perf20.log, view-perf21.log > > > There are often occurrences of "Exception acquiring ownership of X": > During shutdown, using dist: > {noformat} > 13:09:28,290 WARN [org.apache.catalina.session.ManagerBase] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) JBAS018080: Standard expiration of session qLQps+CQJxEi6pJTBSzis0g3 failed; switching to a brute force cleanup. Problem is JBAS018060: Exception acquiring ownership of qLQps+CQJxEi6pJTBSzis0g3 > {noformat} > During server crash, using repl: > {noformat} > 12:55:49,556 INFO [org.jboss.as.clustering.impl.CoreGroupCommunicationService.ejb] (Incoming-2,null) JBAS010248: New cluster view for partition ejb: 6 (org.jboss.as.clustering.impl.CoreGroupCommunicationService$GroupView@327579f6 delta: -1, merge: false) > 12:55:49,557 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,null) ISPN000094: Received new cluster view: [perf21/ejb|6] [perf21/ejb, perf20/ejb, perf18/ejb] > 12:56:31,694 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host]] (ajp-perf20-10.16.90.58-8009-211) Exception sending request initialized lifecycle event to listener instance of class org.jboss.weld.servlet.WeldListener: java.lang.RuntimeException: JBAS018060: Exception acquiring ownership of MvwC8KGWTuKPjD1-JjLW7URZ > at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:528) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > at org.jboss.as.web.session.ClusteredSession.expire(ClusteredSession.java:1260) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > at org.jboss.as.web.session.ClusteredSession.isValid(ClusteredSession.java:1208) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > at org.jboss.as.web.session.ClusteredSession.isValid(ClusteredSession.java:598) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > at org.jboss.as.web.session.DistributableSessionManager.add(DistributableSessionManager.java:917) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > at org.jboss.as.web.session.DistributableSessionManager.loadSession(DistributableSessionManager.java:1407) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:686) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:85) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > at org.apache.catalina.connector.Request.doGetSession(Request.java:2618) [jbossweb-7.0.13.Final.jar:] > at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.13.Final.jar:] > at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:841) [jbossweb-7.0.13.Final.jar:] > at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.getSession(LazySessionBeanStore.java:72) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] > at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.<init>(LazySessionBeanStore.java:58) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] > at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:31) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] > at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:16) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] > at org.jboss.weld.servlet.WeldListener.requestInitialized(WeldListener.java:134) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143) [jbossweb-7.0.13.Final.jar:] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:] > at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505) [jbossweb-7.0.13.Final.jar:] > at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:445) [jbossweb-7.0.13.Final.jar:] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:] > at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30] > Caused by: org.jboss.as.clustering.lock.TimeoutException: JBAS010223: Cannot acquire lock //default-host//clusterbench/MvwC8KGWTuKPjD1-JjLW7URZ from cluster > at org.jboss.as.clustering.lock.SharedLocalYieldingClusterLockManager.lock(SharedLocalYieldingClusterLockManager.java:439) > at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.acquireSessionOwnership(DistributedCacheManager.java:372) > at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:520) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] > ... 23 more > {noformat} -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-805) Overload SecurityVaultFactory.get() to be able to specify the classloader

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-805?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-805: -------------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1079930|https://bugzilla.redhat.com/show_bug.cgi?id=1079930] from NEW to ASSIGNED > Overload SecurityVaultFactory.get() to be able to specify the classloader > ------------------------------------------------------------------------- > > Key: SECURITY-805 > URL: https://issues.jboss.org/browse/SECURITY-805 > Project: PicketBox > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Kabir Khan > Assignee: Kabir Khan > Attachments: SECURITY-805-2.diff, SECURITY-805.diff > > > To work better with modular class loading in WF -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-805) Overload SecurityVaultFactory.get() to be able to specify the classloader

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-805?page=com.atlassian.jira.plug... ] RH Bugzilla Integration updated SECURITY-805: --------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1079930 > Overload SecurityVaultFactory.get() to be able to specify the classloader > ------------------------------------------------------------------------- > > Key: SECURITY-805 > URL: https://issues.jboss.org/browse/SECURITY-805 > Project: PicketBox > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Kabir Khan > Assignee: Kabir Khan > Attachments: SECURITY-805-2.diff, SECURITY-805.diff > > > To work better with modular class loading in WF -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBEE-146) jboss-el-api_2.2_spec 1.0.2.Final cannot access public methods from non-public classes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBEE-146?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on JBEE-146: ---------------------------------------------- Matous Jobanek <mjobanek(a)redhat.com> changed the Status of [bug 1076320|https://bugzilla.redhat.com/show_bug.cgi?id=1076320] from ON_QA to VERIFIED > jboss-el-api_2.2_spec 1.0.2.Final cannot access public methods from non-public classes > -------------------------------------------------------------------------------------- > > Key: JBEE-146 > URL: https://issues.jboss.org/browse/JBEE-146 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Reporter: Farah Juma > Assignee: Farah Juma > Fix For: jboss-el-api_2.2_spec-1.0.3.Final, jboss-el-api_3.0_spec-1.0.0.Final > > > When accessing a public method of a non-public class via EL that implements a public interface or has a public superclass, the following exception occurs: > {code}java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "public" > {code} > See https://bugzilla.redhat.com/show_bug.cgi?id=1029387 for more details. -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2493) EL cannot access public methods/fields of non-public classes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2493?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2493: ----------------------------------------------- Matous Jobanek <mjobanek(a)redhat.com> changed the Status of [bug 1076320|https://bugzilla.redhat.com/show_bug.cgi?id=1076320] from ON_QA to VERIFIED > EL cannot access public methods/fields of non-public classes > ------------------------------------------------------------ > > Key: WFLY-2493 > URL: https://issues.jboss.org/browse/WFLY-2493 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JSF > Environment: JBoss AS 7.2.0.Final > Reporter: Jonáš Trantina > Attachments: elresolver_stack, reproducer.zip > > > When trying to access public method/field of non-public class that implements public interface via EL I get > {noformat} > java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "private" > {noformat} > E.g. accessing Collections.unmodifiableList(..).size() via EL will throw the exception, because #unmodifiableList returns non-public implementation of List interface. > This is apparently caused by JDK-4071957 [1], but since that is opened for over 16 years, it should be probably worth it to implement a workaround. > Workaround for this issue is setting setAccessible(true) on the method before invoking it, thus suppress Java access checking. > I have attached a simple reproducer app as well as a stack trace of the exception. > [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957 -- 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

10 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2014