January 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2485) @Transactional not working correctly with @Stereotype wrt. Exception handling

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/WFLY-2485?page=com.atlassian.jira.plugin.... ] Michael Musgrove resolved WFLY-2485. ------------------------------------ Resolution: Done > @Transactional not working correctly with @Stereotype wrt. Exception handling > ----------------------------------------------------------------------------- > > Key: WFLY-2485 > URL: https://issues.jboss.org/browse/WFLY-2485 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transactions > Affects Versions: 8.0.0.Beta1 > Reporter: David Mann > Assignee: Michael Musgrove > Priority: Minor > > Hi, > > suppose I have a @Stereotype with a @Transactional annotation: > > @Named > @ViewScoped > @Transactional > @Stereotype > @Retention (RetentionPolicy.RUNTIME) > @Target (ElementType.TYPE) > public @interface Boundary > { } > > I annotate a CDI Bean with this stereotype > > @Boundary > public class BusinessLogic { > public void doSomething(){ > throw new RuntimeException("foo"); > } > } > > If any exceptions are thrown when calling the business method, the user will get the (incorrect) info that the Class is missing a @Transactional annotation, because the Interceptor doesn't bother to look further into the Stereotype (see below). > > What's worse, the interceptor is swallowing the real exeption in the process. We get the following Stacktrace: > > java.lang.RuntimeException: ARJUNA016107: Expected an @Transactional annotation at class and/or method level > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.getTransactional(TransactionalInterceptorBase.java:61) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.handleException(TransactionalInterceptorBase.java:96) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:72) > Which is pretty clear from the implementation of TransactionalInterceptorBase: > private Transactional getTransactional(InvocationContext ic) { > > Transactional transactional = ic.getMethod().getAnnotation(Transactional.class); > if (transactional != null) { > return transactional; > } > > Class<?> targetClass = ic.getTarget().getClass(); > transactional = targetClass.getAnnotation(Transactional.class); // needs to look further > if (transactional != null) { > return transactional; > } > > throw new RuntimeException(jtaLogger.i18NLogger.get_expected_transactional_annotation()); // swallows the exception that occured at ic.proceed() > } -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2485) @Transactional not working correctly with @Stereotype wrt. Exception handling

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/WFLY-2485?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated WFLY-2485: ----------------------------------- Fix Version/s: 8.0.0.Final > @Transactional not working correctly with @Stereotype wrt. Exception handling > ----------------------------------------------------------------------------- > > Key: WFLY-2485 > URL: https://issues.jboss.org/browse/WFLY-2485 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transactions > Affects Versions: 8.0.0.Beta1 > Reporter: David Mann > Assignee: Michael Musgrove > Priority: Minor > Fix For: 8.0.0.Final > > > Hi, > > suppose I have a @Stereotype with a @Transactional annotation: > > @Named > @ViewScoped > @Transactional > @Stereotype > @Retention (RetentionPolicy.RUNTIME) > @Target (ElementType.TYPE) > public @interface Boundary > { } > > I annotate a CDI Bean with this stereotype > > @Boundary > public class BusinessLogic { > public void doSomething(){ > throw new RuntimeException("foo"); > } > } > > If any exceptions are thrown when calling the business method, the user will get the (incorrect) info that the Class is missing a @Transactional annotation, because the Interceptor doesn't bother to look further into the Stereotype (see below). > > What's worse, the interceptor is swallowing the real exeption in the process. We get the following Stacktrace: > > java.lang.RuntimeException: ARJUNA016107: Expected an @Transactional annotation at class and/or method level > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.getTransactional(TransactionalInterceptorBase.java:61) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.handleException(TransactionalInterceptorBase.java:96) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:72) > Which is pretty clear from the implementation of TransactionalInterceptorBase: > private Transactional getTransactional(InvocationContext ic) { > > Transactional transactional = ic.getMethod().getAnnotation(Transactional.class); > if (transactional != null) { > return transactional; > } > > Class<?> targetClass = ic.getTarget().getClass(); > transactional = targetClass.getAnnotation(Transactional.class); // needs to look further > if (transactional != null) { > return transactional; > } > > throw new RuntimeException(jtaLogger.i18NLogger.get_expected_transactional_annotation()); // swallows the exception that occured at ic.proceed() > } -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2485) @Transactional not working correctly with @Stereotype wrt. Exception handling

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/WFLY-2485?page=com.atlassian.jira.plugin.... ] Michael Musgrove commented on WFLY-2485: ---------------------------------------- Linked issue is the narayana upgrade that contains the fix > @Transactional not working correctly with @Stereotype wrt. Exception handling > ----------------------------------------------------------------------------- > > Key: WFLY-2485 > URL: https://issues.jboss.org/browse/WFLY-2485 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transactions > Affects Versions: 8.0.0.Beta1 > Reporter: David Mann > Assignee: Michael Musgrove > Priority: Minor > > Hi, > > suppose I have a @Stereotype with a @Transactional annotation: > > @Named > @ViewScoped > @Transactional > @Stereotype > @Retention (RetentionPolicy.RUNTIME) > @Target (ElementType.TYPE) > public @interface Boundary > { } > > I annotate a CDI Bean with this stereotype > > @Boundary > public class BusinessLogic { > public void doSomething(){ > throw new RuntimeException("foo"); > } > } > > If any exceptions are thrown when calling the business method, the user will get the (incorrect) info that the Class is missing a @Transactional annotation, because the Interceptor doesn't bother to look further into the Stereotype (see below). > > What's worse, the interceptor is swallowing the real exeption in the process. We get the following Stacktrace: > > java.lang.RuntimeException: ARJUNA016107: Expected an @Transactional annotation at class and/or method level > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.getTransactional(TransactionalInterceptorBase.java:61) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.handleException(TransactionalInterceptorBase.java:96) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:72) > Which is pretty clear from the implementation of TransactionalInterceptorBase: > private Transactional getTransactional(InvocationContext ic) { > > Transactional transactional = ic.getMethod().getAnnotation(Transactional.class); > if (transactional != null) { > return transactional; > } > > Class<?> targetClass = ic.getTarget().getClass(); > transactional = targetClass.getAnnotation(Transactional.class); // needs to look further > if (transactional != null) { > return transactional; > } > > throw new RuntimeException(jtaLogger.i18NLogger.get_expected_transactional_annotation()); // swallows the exception that occured at ic.proceed() > } -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1197) Port the legacy jmx-console to AS7

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-1197?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-1197: ----------------------------------- Fix Version/s: 9.0.0.CR1 > Port the legacy jmx-console to AS7 > ---------------------------------- > > Key: WFLY-1197 > URL: https://issues.jboss.org/browse/WFLY-1197 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JMX > Reporter: Dimitris Andreadis > Assignee: Darran Lofthouse > Labels: JMX, as7, jmx-console > Fix For: 9.0.0.CR1 > > Attachments: jmx-console.war, jmx-console.war > > > I've seen a few people asking for a port of the old jmx-console to AS7, for monitoring purposes, until equivalent functionality is available through the new GWT-based console. > I've ported the old console in this branch: > https://github.com/dandreadis/jboss-as/commits/jmx-console > It only includes a new top-level directory 'jmx-console'. The directory is not build by default, and when you build it manually it does not alter the server configuration in any way, you need to manually copy the resulting target/jboss-as-jmx-console-VERSION.war to the server deployment directory (and rename it to jmx-console.war) > If there is interest, it could be included in the AS7 distro in some top level 'legacy' directory so it is not deployed by default? > The resulting .war is attached on this JIRA, in case someone wants to use it. It work just as well on AS 7.0.2 and the latest AS 7.1.x development branch. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1523) Addition of caching for security realms backed by ldap.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-1523?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-1523: ----------------------------------- Priority: Major (was: Critical) > Addition of caching for security realms backed by ldap. > ------------------------------------------------------- > > Key: WFLY-1523 > URL: https://issues.jboss.org/browse/WFLY-1523 > Project: WildFly > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 8.0.0.Final > > > For JAAS this is achieved by caching keyed on the combination of the username and the password, once we switch to the CallbackHandler approach this is no longer applicable as there is often not a single username/credential combination - instead a protocol specific exchange is used to establish the identity of the remote user. > Any cache would also potentially require: - > - Predicable eviction. > - Management Operations e.g. clear entire cache, remove single entries etc... > - Separation of caches for authenticiation data and additional data loaded for authorization purposes. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2440) Thread pool AccessControlContext Propagation

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-2440?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-2440: ----------------------------------- Fix Version/s: 9.0.0.CR1 (was: 8.0.0.Final) > Thread pool AccessControlContext Propagation > -------------------------------------------- > > Key: WFLY-2440 > URL: https://issues.jboss.org/browse/WFLY-2440 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 9.0.0.CR1 > > > A decision was made within Java that newly created threads should inherit the access control context of their creator. > In general this was justified on the basis that if you are creating a thread you want it to inherit the permissions you already have. > Once we introduce thread pooling that logic no longer makes as much sense and there is not the same relationship between the thread that triggers it's creation and the long term life of that thread. > This may affect components outside of WildFly but I am raising it here as a top level task. > Should also note that JBoss Threads does already have some protection built in if a security manager is in use but there are times the AccessControlContext will be used without a security manager so more control is required. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1652) The security realm PlugIns are currently returning roles, this should be group membership information.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-1652?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-1652: ----------------------------------- Fix Version/s: 9.0.0.CR1 (was: 8.0.0.Final) > The security realm PlugIns are currently returning roles, this should be group membership information. > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-1652 > URL: https://issues.jboss.org/browse/WFLY-1652 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 9.0.0.CR1 > > > Without breaking backwards compatibility this should be returning group membership information and not roles. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2489) Replace add-user example image with something not running as root.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-2489?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-2489: ----------------------------------- Fix Version/s: 8.0.1.Final (was: 8.0.0.Final) > Replace add-user example image with something not running as root. > ------------------------------------------------------------------ > > Key: WFLY-2489 > URL: https://issues.jboss.org/browse/WFLY-2489 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Web Console > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 8.0.1.Final > > > Where no users are defined we show a web page with an example using the add user utility - would be a good idea to not be encouraging running as root. > In addition to this some of the prompts have evolved anyway e.g. no longer a need to specify the realm 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2456) Using add-user.bat for initial admin user results in "JBAS015234: No mgmt-groups.properties files found"

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-2456?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-2456: ----------------------------------- Fix Version/s: 8.0.1.Final (was: 9.0.0.CR1) > Using add-user.bat for initial admin user results in "JBAS015234: No mgmt-groups.properties files found" > -------------------------------------------------------------------------------------------------------- > > Key: WFLY-2456 > URL: https://issues.jboss.org/browse/WFLY-2456 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Scripts > Affects Versions: 8.0.0.Beta1 > Environment: Windows 7, 32-bit, jdk1.7.0_45 > Reporter: John Lusk > Assignee: Darran Lofthouse > Fix For: 8.0.1.Final > > > Just getting started w/Wildfly after a long absence from Java. Fresh download, trying to hit admin console, got instructed to use add-user to add an admin user. > c:\usr\local\wildfly-8.0.0.Beta1\bin>.\add-user.bat > What type of user do you wish to add? > a) Management User (mgmt-users.properties) > b) Application User (application-users.properties) > (a): a > * Error * > JBAS015234: No mgmt-groups.properties files found. > Press any key to continue . . . > c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %JBOSS_HOME% > C:\usr\local\wildfly-8.0.0.Beta1 > c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %JAVA_HOME% > C:\java\jdk1.7.0_45 > c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %M2_HOME% > C:\usr\local\Maven\3.1.1 > c:\usr\local\wildfly-8.0.0.Beta1\bin>mvn -version > Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:2 > 2-0400) > Maven home: C:\usr\local\Maven\3.1.1 > Java version: 1.7.0_45, vendor: Oracle Corporation > Java home: C:\java\jdk1.7.0_45\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "x86", family: "windows" > c:\usr\local\wildfly-8.0.0.Beta1\bin> -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-566) Using pre-digested passwords, having all installations with the same realm could reduce the effectiveness

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-566?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated WFLY-566: ---------------------------------- Fix Version/s: 8.0.0.Final (was: 9.0.0.CR1) > Using pre-digested passwords, having all installations with the same realm could reduce the effectiveness > --------------------------------------------------------------------------------------------------------- > > Key: WFLY-566 > URL: https://issues.jboss.org/browse/WFLY-566 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: Realm_Management > Fix For: 8.0.0.Final > > > Can we generate a name of first boot? Possibly even separate the internal name use to link from the realm to the name presented to the end users? -- 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, 2 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 January 2014