November 2013 - jboss-jira - Jboss List Archives

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

by Jonáš Trantina (JIRA)

[ https://issues.jboss.org/browse/WFLY-2493?page=com.atlassian.jira.plugin.... ] Jonáš Trantina updated WFLY-2493: --------------------------------- Attachment: elresolver_stack > 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 via EL I get > {noformat} > java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "private" > {noformat} > 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

11 years, 2 months

1
0
0 / 0

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

by Jonáš Trantina (JIRA)

[ https://issues.jboss.org/browse/WFLY-2493?page=com.atlassian.jira.plugin.... ] Jonáš Trantina updated WFLY-2493: --------------------------------- Attachment: reproducer.zip Attached reproducer and stack trace > 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 via EL I get > {noformat} > java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "private" > {noformat} > 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

11 years, 2 months

1
0
0 / 0

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

by Jonáš Trantina (JIRA)

[ https://issues.jboss.org/browse/WFLY-2493?page=com.atlassian.jira.plugin.... ] Jonáš Trantina updated WFLY-2493: --------------------------------- Description: When trying to access public method/field of non-public class via EL I get {noformat} java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "private" {noformat} 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 was: When trying to access public method/field of non-public class via EL I get {noformat} java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "private" {noformat} 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. My guess is it could be done either in BeanELResolver#invokeMethod(...) or BeanELResolver#getMethod(...). 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 > 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 > > When trying to access public method/field of non-public class via EL I get > {noformat} > java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "private" > {noformat} > 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2403) Cannot disable Datasource or XADatasource in standalone and domain modes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2403?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2403: ----------------------------------------------- Stefano Maestri <smaestri(a)redhat.com> made a comment on [bug 970679|https://bugzilla.redhat.com/show_bug.cgi?id=970679] isn't it this bug? https://bugzilla.redhat.com/show_bug.cgi?id=952277 Should be solved and verified on ER7 > Cannot disable Datasource or XADatasource in standalone and domain modes > ------------------------------------------------------------------------ > > Key: WFLY-2403 > URL: https://issues.jboss.org/browse/WFLY-2403 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Stefano Maestri > Assignee: Stefano Maestri > > Description of problem: > Cannot disable a Datasource or XADatasource in standalone mode. It's back to enabled state after server reload. > Version-Release number of selected component (if applicable): > 6.1 > How reproducible: > Always > Steps to Reproduce: > Use the http management interface or the CLI > 1.Create a Datasource of XADatasource > 2.Disable it > 3.The response indicates a server reload is required > 4.Execute the reload operation > Actual results: > The datasource is back to enabled state > Expected results: > The datasource should be in disabled state -- 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

11 years, 2 months

1
0
0 / 0

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

by Jonáš Trantina (JIRA)

[ https://issues.jboss.org/browse/WFLY-2493?page=com.atlassian.jira.plugin.... ] Jonáš Trantina updated WFLY-2493: --------------------------------- Component/s: JSF > 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 > > When trying to access public method/field of non-public class via EL I get > {noformat} > java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "private" > {noformat} > 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. My guess is it could be done either in BeanELResolver#invokeMethod(...) or BeanELResolver#getMethod(...). > 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

11 years, 2 months

1
0
0 / 0

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

by Jonáš Trantina (JIRA)

Jonáš Trantina created WFLY-2493: ------------------------------------ Summary: 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) Environment: JBoss AS 7.2.0.Final Reporter: Jonáš Trantina When trying to access public method/field of non-public class via EL I get {noformat} java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "private" {noformat} 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. My guess is it could be done either in BeanELResolver#invokeMethod(...) or BeanELResolver#getMethod(...). 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2403) Cannot disable Datasource or XADatasource in standalone and domain modes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2403?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2403: ----------------------------------------------- Martin Simka <msimka(a)redhat.com> made a comment on [bug 970679|https://bugzilla.redhat.com/show_bug.cgi?id=970679] @Brian: I've just never noticed this behavior. It isn't regression. @Stefano: I can't reproduce this issue on EAP 6.1.0? Any idea what I'm doing wrong? EAP 6.1.0 Steps to Reproduce: 1.Create a Datasource of XADatasource [standalone@localhost:9999 /] data-source add --name=Test2 --driver-name=h2 --jndi-name=java:jboss/datasources/Test2 --connection-url=jdbc:h2:mem:test2;DB_CLOSE_DELAY=-1 2.Disable it [standalone@localhost:9999 /] data-source disable --name=Test2 operation-requires-reload true process-state reload-required 3.The response indicates a server reload is required 4.Execute the reload operation [standalone@localhost:9999 /] reload Actual results: The datasource is back to enabled state Expected results: The datasource should be in disabled state ^------ this is not true, datasource is disabled [standalone@localhost:9999 /] /subsystem=datasources/data-source=Test2:read-attribute(name=enabled) { "outcome" => "success", "result" => false } EAP 6.1.1 Steps to Reproduce: 1.Create a Datasource of XADatasource [standalone@localhost:9999 /] data-source add --name=Test2 --driver-name=h2 --jndi-name=java:jboss/datasources/Test2 --connection-url=jdbc:h2:mem:test2;DB_CLOSE_DELAY=-1 2.Disable it [standalone@localhost:9999 /] data-source disable --name=Test2 operation-requires-reload true process-state reload-required 3.The response indicates a server reload is required 4.Execute the reload operation [standalone@localhost:9999 /] reload Actual results: The datasource is back to enabled state Expected results: The datasource should be in disabled state ^-- this is not true, datasource is disabled [standalone@localhost:9999 /] /subsystem=datasources/data-source=Test2:read-attribute(name=enabled) { "outcome" => "success", "result" => false } EAP 6.2.0.CR1 Steps to Reproduce: 1.Create a Datasource of XADatasource [standalone@localhost:9999 /] data-source add --name=Test2 --driver-name=h2 --jndi-name=java:jboss/datasources/Test2 --connection-url=jdbc:h2:mem:test2;DB_CLOSE_DELAY=-1 2.Disable it [standalone@localhost:9999 /] data-source disable --name=Test2 operation-requires-reload true process-state reload-required 3.The response indicates a server reload is required 4.Execute the reload operation [standalone@localhost:9999 /] reload Actual results: The datasource is back to enabled state Expected results: The datasource should be in disabled state ^-- this is not true, datasource is disabled [standalone@localhost:9999 /] /subsystem=datasources/data-source=Test2:read-attribute(name=enabled) { "outcome" => "success", "result" => false } The same with EAP 6.1.0 [standalone@localhost:9999 /] /subsystem=datasources/data-source=Test2:add(connection-url=jdbc:h2:mem:test2;DB_CLOSE_DELAY=-1, jndi-name=java:jboss/datasources/Test2, driver-name=h2) {"outcome" => "success"} [standalone@localhost:9999 /] /subsystem=datasources/data-source=Test2:disable() { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } } [standalone@localhost:9999 /] reload [standalone@localhost:9999 /] /subsystem=datasources/data-source=Test2:read-attribute(name=enabled) { "outcome" => "success", "result" => false } I'm getting same result when I add step enable after creation of datasource. EAP 6.1.0 [standalone@localhost:9999 /] data-source add --name=Test2 --driver-name=h2 --jndi-name=java:jboss/datasources/Test2 --connection-url=jdbc:h2:mem:test2;DB_CLOSE_DELAY=-1 [standalone@localhost:9999 /] data-source enable --name=Test2 [standalone@localhost:9999 /] data-source disable --name=Test2 operation-requires-reload true process-state reload-required [standalone@localhost:9999 /] reload [standalone@localhost:9999 /] /subsystem=datasources/data-source=Test2:read-attribute(name=enabled) { "outcome" => "success", "result" => false } > Cannot disable Datasource or XADatasource in standalone and domain modes > ------------------------------------------------------------------------ > > Key: WFLY-2403 > URL: https://issues.jboss.org/browse/WFLY-2403 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Stefano Maestri > Assignee: Stefano Maestri > > Description of problem: > Cannot disable a Datasource or XADatasource in standalone mode. It's back to enabled state after server reload. > Version-Release number of selected component (if applicable): > 6.1 > How reproducible: > Always > Steps to Reproduce: > Use the http management interface or the CLI > 1.Create a Datasource of XADatasource > 2.Disable it > 3.The response indicates a server reload is required > 4.Execute the reload operation > Actual results: > The datasource is back to enabled state > Expected results: > The datasource should be in disabled state -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2481) CDI.current().getBeanManager() returns a beanmanager from a different deployment

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/WFLY-2481?page=com.atlassian.jira.plugin.... ] Jozef Hartinger commented on WFLY-2481: --------------------------------------- Yes, the CDI class implementation provided by Weld is wrong. Both GlassFish and WildFly use that. The proper way to fix this is specific to the integrator. Please raise a GlassFish issue for this. > CDI.current().getBeanManager() returns a beanmanager from a different deployment > -------------------------------------------------------------------------------- > > Key: WFLY-2481 > URL: https://issues.jboss.org/browse/WFLY-2481 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.0.0.Beta1 > Environment: WildFly master build > Reporter: Emond Papegaaij > Assignee: Jozef Hartinger > > CDI.current().getBeanManager() uses the classname of the calling class to cache BeanManagers returned. This fails if multiple deployments contain classes with the same name. For example, wicket-cdi-1.1 looks up the BeanManager from org.apache.wicket.cdi.CdiConfiguration. If multiple Wicket-CDI applications are deployed in the same container, every BeanManager lookup will return the instance cached on the first call. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2428) MDBs should use the full identifier of the resource adapter

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2428?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2428: ----------------------------------------------- Ondrej Chaloupka <ochaloup(a)redhat.com> changed the Status of [bug 1012044|https://bugzilla.redhat.com/show_bug.cgi?id=1012044] from ON_QA to VERIFIED > MDBs should use the full identifier of the resource adapter > ----------------------------------------------------------- > > Key: WFLY-2428 > URL: https://issues.jboss.org/browse/WFLY-2428 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Affects Versions: 8.0.0.CR1 > Reporter: Jesper Pedersen > Assignee: Stefano Maestri > Fix For: 8.0.0.CR1 > > > The .rar suffix shouldn't be stripped anymore, as the resource adapters are registered under their full name. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2383) resource-adapter id attribute has to match ra name otherwise MDB is not deployed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2383?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2383: ----------------------------------------------- Ondrej Chaloupka <ochaloup(a)redhat.com> made a comment on [bug 1012044|https://bugzilla.redhat.com/show_bug.cgi?id=1012044] OK, thank you. In this way it works fine. > resource-adapter id attribute has to match ra name otherwise MDB is not deployed > -------------------------------------------------------------------------------- > > Key: WFLY-2383 > URL: https://issues.jboss.org/browse/WFLY-2383 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Stefano Maestri > Assignee: Stefano Maestri > > The resource-adapter id has to have the same name as the ra archive has. Otherwise the the MDB is not deployed. -- 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

11 years, 2 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 November 2013