[JBoss JIRA] (WFLY-19) JMX over remoting pollutes query results with ModelController objects
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-19?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated WFLY-19:
---------------------------------
Fix Version/s: (was: 8.0.0.CR1)
> JMX over remoting pollutes query results with ModelController objects
> ---------------------------------------------------------------------
>
> Key: WFLY-19
> URL: https://issues.jboss.org/browse/WFLY-19
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management, JMX
> Reporter: NadirX
> Assignee: Kabir Khan
> Fix For: 8.0.0.Final
>
>
> When issuing MBean queries over JMX remoting, the AS is returning a list of org.jboss.as.controller.ModelController objects in addition to those matching the query.
> This is a transcript of a chat we had about it on IRC:
> Oct 15 14:51:46 <ttarrant> darranl, if I issue a jmx query over jmx-remoting I get many more objects than expected
> Oct 15 14:51:55 <ttarrant> darranl, i.e. ones that do not match the query
> Oct 15 14:52:09 <ttarrant> darranl, this is with 7.1.x
> Oct 15 14:52:57 <ttarrant> darranl, this works if I use the standard JMX over RMI
> Oct 15 14:53:08 --> fnasser (~fnasser(a)CPE602ad07ab726-CM602ad07ab723.cpe.net.cable.rogers.com) has joined #jboss-as7
> Oct 15 14:53:09 <-- fnasser has quit (Changing host)
> Oct 15 14:53:09 --> fnasser (~fnasser@redhat/jboss/fnasser) has joined #jboss-as7
> Oct 15 14:53:09 --- ChanServ gives voice to fnasser
> Oct 15 14:53:16 <ttarrant> darranl, do you just pass the query the the mbeanserver ?
> Oct 15 14:53:39 <darranl> ttarrant: what kind of objects? within AS7 I think there are two things that could affec
> t this 1 - The Remoting JMX protocol, 2 - The domain management representation over JMX
> Oct 15 14:53:54 <darranl> For #1 yes we just pass it to the MBEanServer and return whatever it returns
> Oct 15 14:54:04 <darranl> if it was a Remoting JMX bug maybe we are messing up the query
> Oct 15 14:54:16 <ttarrant> darranl, the query is as follows: *:type=CacheManager,component=Interpreter,name=*
> Oct 15 14:54:16 <darranl> But not sure if #2 could be the reason more is getting added
> Oct 15 14:54:32 <ttarrant> darranl, wait a sec
> Oct 15 14:54:57 <darranl> ttarrant: I would suggest getting a Jira raised and assigned to me, I can verify if it i
> s a remoting jmx issue or pass over if it is a domain management integration issue
> Oct 15 14:55:20 <darranl> regardless of where it is happenign it sounds like you may have discovered a bug
> Oct 15 14:56:23 <ttarrant> darranl, let me get the objects it's returning
> Oct 15 14:56:39 <darranl> ttarrant: when you enable the RMI approach you bypass both Remoting JMX AND the domain m
> anagement integration
> Oct 15 14:56:42 <darranl> ok
> Oct 15 15:26:08 <ttarrant> darranl, ok, my query actually returns the object I queried for and a bunch of org.jboss.as.controller.ModelController (one for each subsystem)
> Oct 15 15:51:24 <darranl> ttarrant: ok that does then sound like it is the domain management integration that is 'poluting' the query results
> Oct 15 15:51:53 <darranl> ttarrant: going RMI was just bypassing that as well
> Oct 15 15:52:05 <ttarrant> darranl, shall I open a Jira ?
> Oct 15 15:52:34 <ttarrant> darranl, I work around the issue by manually filtering the returned objects based on class name
> Oct 15 15:53:23 <darranl> ttarrant: it would probably be one for kkhan to look into, think he is just back today so may be worth the Jira so he can have a look once he has caught back up ;-)
--
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, 11 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 closed WFLY-2841.
------------------------------
> 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
11 years, 11 months
[JBoss JIRA] (JGRP-1788) Backport selected testsuite changes from JGroups 3.4
by Richard Achmatowicz (JIRA)
Richard Achmatowicz created JGRP-1788:
-----------------------------------------
Summary: Backport selected testsuite changes from JGroups 3.4
Key: JGRP-1788
URL: https://issues.jboss.org/browse/JGRP-1788
Project: JGroups
Issue Type: Feature Request
Affects Versions: 3.2.13
Reporter: Richard Achmatowicz
Assignee: Richard Achmatowicz
Fix For: 3.2.13
This issue backports the following features from JGroups 3.4:
- the ability to run the testsuite in sequential mode as opposed to the default parallel mode
- the ability to better configure and run Byteman tests on different platforms
--
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, 11 months
[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
11 years, 11 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
11 years, 11 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
11 years, 11 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
11 years, 11 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
11 years, 11 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
11 years, 11 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
11 years, 11 months