[JBoss JIRA] (JGRP-1787) Adjust Windows command line parameter processing to accept more than 9 parameters.
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1787?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1787:
-------------------------------------------
This is fixed by:
{noformat}
"%JAVA_HOME%\bin\java" -classpath "%CP%" org.apache.tools.ant.Main -buildfile build.xml %*
{noformat}
where %* represents all command-line parameters.
> Adjust Windows command line parameter processing to accept more than 9 parameters.
> ----------------------------------------------------------------------------------
>
> Key: JGRP-1787
> URL: https://issues.jboss.org/browse/JGRP-1787
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: Windows
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Minor
> Fix For: 3.2.13
>
>
> In the Windows build.bat script, command-line parameters are processed using the following code:
> {noformat}
> "%JAVA_HOME%\bin\java" -classpath "%CP%" org.apache.tools.ant.Main -buildfile build.xml %1 %2 %3 %4 %5 %6 %7 %8 %9
> {noformat}
> This limits the number of command-line parameters to 9, which is not sufficient for executing builds which make use of many system properties (e.g. in the QA lab).
>
--
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, 3 months
[JBoss JIRA] (JGRP-1787) Adjust Windows command line parameter processing to accept more than 9 parameters.
by Richard Achmatowicz (JIRA)
Richard Achmatowicz created JGRP-1787:
-----------------------------------------
Summary: Adjust Windows command line parameter processing to accept more than 9 parameters.
Key: JGRP-1787
URL: https://issues.jboss.org/browse/JGRP-1787
Project: JGroups
Issue Type: Bug
Affects Versions: 3.2.13
Environment: Windows
Reporter: Richard Achmatowicz
Assignee: Richard Achmatowicz
Priority: Minor
Fix For: 3.2.13
In the Windows build.bat script, command-line parameters are processed using the following code:
{noformat}
"%JAVA_HOME%\bin\java" -classpath "%CP%" org.apache.tools.ant.Main -buildfile build.xml %1 %2 %3 %4 %5 %6 %7 %8 %9
{noformat}
This limits the number of command-line parameters to 9, which is not sufficient for executing builds which make use of many system properties (e.g. in the QA lab).
--
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, 3 months
[JBoss JIRA] (WFLY-2841) Datasource mapped in jboss-web.xml not available to persistence unit
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-2841?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-2841:
-------------------------------
Workaround Description:
Set wildfly.jpa.twophasebootstrap to false in the persistence unit definition as a workaround to have the persistence unit start as late as possible (during the INSTALL deployment phase):
<property name="wildfly.jpa.twophasebootstrap" value="false"/>
Workaround: Workaround Exists
> Datasource mapped in jboss-web.xml not available to persistence unit
> --------------------------------------------------------------------
>
> Key: WFLY-2841
> URL: https://issues.jboss.org/browse/WFLY-2841
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.CR1
> Reporter: Martin Andersson
>
> I have mapped the datasource java:jboss/datasources/ExampleDS to jdbc/MyDS in jboss-web.xml for my application.
> In a stateless bean i can do a jndi lookup and find the datasource in both java:comp/env/jdbc/MyDS and java:module/env/jdbc/MyDS as expected. But if I try to use it in my persistence.xml I get an error:
> 13:18:28,129 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
> A minimal example application that demonstrates the problem is available at: https://github.com/umartin/wfds/
--
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, 3 months
[JBoss JIRA] (WFLY-2841) Datasource mapped in jboss-web.xml not available to persistence unit
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-2841?page=com.atlassian.jira.plugin.... ]
Scott Marlow resolved WFLY-2841.
--------------------------------
Resolution: Rejected
The deployment succeeds with wildfly.jpa.twophasebootstrap set to false.
> Datasource mapped in jboss-web.xml not available to persistence unit
> --------------------------------------------------------------------
>
> Key: WFLY-2841
> URL: https://issues.jboss.org/browse/WFLY-2841
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.CR1
> Reporter: Martin Andersson
>
> I have mapped the datasource java:jboss/datasources/ExampleDS to jdbc/MyDS in jboss-web.xml for my application.
> In a stateless bean i can do a jndi lookup and find the datasource in both java:comp/env/jdbc/MyDS and java:module/env/jdbc/MyDS as expected. But if I try to use it in my persistence.xml I get an error:
> 13:18:28,129 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
> A minimal example application that demonstrates the problem is available at: https://github.com/umartin/wfds/
--
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, 3 months
[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
10 years, 3 months
[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
10 years, 3 months
[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
10 years, 3 months
[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
10 years, 3 months
[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
10 years, 3 months
[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
10 years, 3 months