[JBoss JIRA] (WFLY-2936) "Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction" error in migrated seam 2.2.2 application
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/WFLY-2936?page=com.atlassian.jira.plugin.... ]
Tomas Remes commented on WFLY-2936:
-----------------------------------
Hi Eduardo! I am not sure, if you are still interested in some reproducer, but this can be easily reproduced also in latest Seam 2.3.x for example in Booking example. It is available here https://github.com/tremes/jboss-seam/tree/seam-on-wildfly (branch containing some updates to run on WF) and you can run in examples/booking e.g.:
{noformat}
mvn clean verify -Darquillian=wildfly-remote-8 -Dtest=BookingTest
{noformat}
> "Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction" error in migrated seam 2.2.2 application
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2936
> URL: https://issues.jboss.org/browse/WFLY-2936
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.Final
> Environment: Windows 7 64bit
> Java 1.7.0_51
> WildFly 8.0.0.Final
> JBoss Seam 2.2.2.Final
> Reporter: Dimitris Keramidas
> Assignee: Eduardo Martins
> Attachments: Auth.java, Authenticator.java, components.xml, jboss-deployment-structure.xml, server.log
>
>
> The error is fired when attempting to call a transaction-enabled EJB method, from a seam component. Specifically the authentication component.
> In order to get to this position, the project's deployment descriptors had to be migrated. Furthermore, mojarra version 1.2_15 was deployed to WildFly, as described by this link: https://community.jboss.org/wiki/DesignOfWildFlyMulti-JSFFeature
> Please see attached logs and descriptors.
--
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, 3 months
[JBoss JIRA] (DROOLS-441) drools-guvnor 5.5, declarative model, create more than one fact type, BPMN process does not load
by niraj gupta (JIRA)
niraj gupta created DROOLS-441:
----------------------------------
Summary: drools-guvnor 5.5, declarative model, create more than one fact type, BPMN process does not load
Key: DROOLS-441
URL: https://issues.jboss.org/browse/DROOLS-441
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.5.0.Final
Environment: Tomcat 6.0.35, jBPM 5.5.Final
Reporter: niraj gupta
Assignee: Mark Proctor
I am using ‘drools-guvnor 5.5.0.Final’ open source tool for designing the business process (BPMN2). I end up in an issue and looking for help. Following is the scenario
I created a package then process then after build, deploy execute successfully. Now I came back to guvnor and made few changes in the process. Then after same build, deploy execute successfully. But now this time I am creating a declarative model having 2 facts, also modifying business process. Then after same build, deploy execute successfully. This time modified/latest business process doesn’t load into console. This is my problem. However I trouble shoot and google following are my observations:
• I am running this application in tomcat 6.0.35
• It works perfectly with POJO Model Jar approach.
• It works perfectly with declarative model but having single fact.
• I am not seeing any exceptions either in UI or console logs
--
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, 3 months
[JBoss JIRA] (WFLY-2261) standalone.sh --debug without port number not working
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2261?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2261:
-----------------------------------------------
Jeff Mesnil <jmesnil(a)redhat.com> changed the Status of [bug 1063289|https://bugzilla.redhat.com/show_bug.cgi?id=1063289] from NEW to POST
> standalone.sh --debug without port number not working
> ------------------------------------------------------
>
> Key: WFLY-2261
> URL: https://issues.jboss.org/browse/WFLY-2261
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Scripts
> Affects Versions: 8.0.0.Beta1
> Reporter: Cheng Fang
> Assignee: Jeff Mesnil
> Fix For: 8.0.1.Final
>
>
> ./standalone.sh --debug port-num works, but it failed when omitting port number.
> sh -x standalone.sh --debug (expecting the default port 8787 to be used)
> {noformat}
> + eval '"/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java"' '-D"[Standalone]"' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n '"-Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log"' '"-Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties"' -jar '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar"' -mp '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules"' org.jboss.as.standalone '-Djboss.home.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT"' '-Djboss.server.base.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone"' ' ""'
> ++ /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java '-D[Standalone]' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties -jar /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar -mp /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT -Djboss.server.base.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone ''
> Listening for transport dt_socket at address: 8787
> 12:19:36,715 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 12:19:36,886 ERROR [stderr] (main) JBAS015801: Invalid option ''
> 12:19:36,893 INFO [stdout] (main)
> 12:19:36,893 INFO [stdout] (main) Usage: standalone.sh [args...]
> {noformat}
> sh -x standalone.sh --debug 8787 (the working command)
> {noformat}
> + eval '"/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java"' '-D"[Standalone]"' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n '"-Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log"' '"-Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties"' -jar '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar"' -mp '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules"' org.jboss.as.standalone '-Djboss.home.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT"' '-Djboss.server.base.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone"' ''
> ++ /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java '-D[Standalone]' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties -jar /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar -mp /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT -Djboss.server.base.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone
> Listening for transport dt_socket at address: 8787
> 12:20:39,251 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 12:20:39,626 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.0.Beta2
> {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
12 years, 3 months
[JBoss JIRA] (WFLY-2987) RemoteDestinationOutboundSocketBindingService is not stopped when the resource is removed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2987?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2987:
-----------------------------------------------
Jeff Mesnil <jmesnil(a)redhat.com> changed the Status of [bug 1038465|https://bugzilla.redhat.com/show_bug.cgi?id=1038465] from NEW to POST
> RemoteDestinationOutboundSocketBindingService is not stopped when the resource is removed
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-2987
> URL: https://issues.jboss.org/browse/WFLY-2987
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Server
> Affects Versions: 8.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 8.0.1.Final
>
>
> Steps to Reproduce:
> 1. add remote-destination-outbound-socket-binding
> ./jboss-cli.sh -c "/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-connection-war-ejb-1:add(host=localhost, port=4447)"
> result is {"outcome" => "success"}
> 3. remove remote-destination-outbound-socket-binding
> ./bin/jboss-cli.sh -c "/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-connection-war-ejb-1:remove"
> result is {"outcome" => "success"}
> 4. add remote-destination-outbound-socket-binding
> ./jboss-cli.sh -c "/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-connection-war-ejb-1:add(host=localhost, port=4447)"
> result is
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014749: Operation handler failed: Service jboss.outbound-socket-binding.remote-connection-war-ejb-1 is already registered",
> "rolled-back" => true
> }
> Expected results:
> {"outcome" => "success"}
> Step 3 should either report reload required or should be fixed
--
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, 3 months
[JBoss JIRA] (JBAS-9558) Unknown JSF version 'WAR_BUNDLES_JSF_IMPL'. Default version 'main' will be used instead. " in EAP Jboss 6.1.0
by Shnejuti Bose (JIRA)
Shnejuti Bose created JBAS-9558:
-----------------------------------
Summary: Unknown JSF version 'WAR_BUNDLES_JSF_IMPL'. Default version 'main' will be used instead. " in EAP Jboss 6.1.0
Key: JBAS-9558
URL: https://issues.jboss.org/browse/JBAS-9558
Project: Application Server 3 4 5 and 6
Issue Type: Patch
Security Level: Public (Everyone can see)
Reporter: Shnejuti Bose
I am trying to use jsf 1.1 in a ear application deployed on JBoss 6.1.0 EAP , but WAR_BUNDLES_JSF_IMPL is not working for EAR files .
Deployment is failing with an error "[org.jboss.as.jsf] (MSC service thread 1-2) JBAS012603: Unknown JSF version 'WAR_BUNDLES_JSF_IMPL'. Default version 'main' will be used instead. " .
I assume this is because JBoss 7 is expecting me to use the JSF implementation that comes with JBoss 7.
I can not change or upgrade the JSF implementation. Please provide the fix so that i can use the jsf 1.1 .
--
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, 3 months
[JBoss JIRA] (JGRP-1800) OverlappingMergeTest testRegularMessageSending does not receive all expected mcast messages
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1800?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1800:
--------------------------------
I streamlined the test a bit. The only thing that comes to mind why A#3 wasn't received in the error case above is that {{ArrayList.add()}} is not synchronized and concurrently adding messages from different senders A, B and C might cause this.
I changed this on 3.2 and master; let's see what Jenkins had to say...
> OverlappingMergeTest testRegularMessageSending does not receive all expected mcast messages
> -------------------------------------------------------------------------------------------
>
> Key: JGRP-1800
> URL: https://issues.jboss.org/browse/JGRP-1800
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL, Solairis
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13, 3.5
>
>
> testRegularMessageSending is a kind of smoke test for the stack used in OverlappingMergeTest:
> - three channels a,b,c are created with a particular stack (see modifyConfigs)
> - each of a,b,c sends 5 multicast messages to the group, with message payloads "1", "2", "3", "4", "5"
> - the receiver in each channel collects up the multicasts received
> - the test checks that all 15 messages are received by each of the channels, and an assertion error is thrown is this is not the case
> This test is failing occasionally. An example of the error:
> {noformat}
> Error Message
> (C) num_mcasts=C: 1 C: 2 C: 3 C: 4 C: 5 A: 1 B: 1 A: 2 B: 2 B: 3 B: 4 A: 4 B: 5 A: 5 expected: 15)
> Stacktrace
> java.lang.AssertionError
> at org.jgroups.tests.OverlappingMergeTest.checkReceivedMessages(OverlappingMergeTest.java:476)
> at org.jgroups.tests.OverlappingMergeTest.testRegularMessageSending(OverlappingMergeTest.java:66)
> {noformat}
> This assertion error indicates that multicast #3 was not received from A by C.
> This is a very simple scenario and failures should not be occurring. I mention this error as there are other merge tests, namely:
> * testOverlappingMergeWithBC
> * testOverlappingMergeWithABC
> which are more complex, but when we look at their failures, they fail on an initial step similar to the one described above.
--
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, 3 months
[JBoss JIRA] (LOGMGR-95) Log4j Logger.getParent() inconsistent
by James Livingston (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-95?page=com.atlassian.jira.plugin.... ]
James Livingston commented on LOGMGR-95:
----------------------------------------
One possible solution would be to have updateParents() create the log4j Logger instance for the parent node if it did not exist.
> Log4j Logger.getParent() inconsistent
> -------------------------------------
>
> Key: LOGMGR-95
> URL: https://issues.jboss.org/browse/LOGMGR-95
> Project: JBoss Log Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: James Livingston
> Assignee: David Lloyd
>
> Log4j Loggers have a getParent() method, whose return value is set up by JBossLogManagerFacade.updateParents(). The method locates the closest parent node which has an existing Log4J logger created *at the time*. This results in the parent being different depending on the order Log4j loggers are used in.
> Consider:
> Logger.getLogger("a");
> Logger.getLogger("a.b.c");
> Logger.getLogger("a.b");
> When the second line causes updateParents() to be called, LoggerNode.getOrCreate() has already created the intermediate "a.b" node. That does not yet have a Log4j Logger created, so the Logger for "a" is returned. Original log4j would have returned "a.b" due to it using the parent structure in the implementation.
--
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, 3 months
[JBoss JIRA] (LOGMGR-95) Log4j Logger.getParent() inconsistent
by James Livingston (JIRA)
James Livingston created LOGMGR-95:
--------------------------------------
Summary: Log4j Logger.getParent() inconsistent
Key: LOGMGR-95
URL: https://issues.jboss.org/browse/LOGMGR-95
Project: JBoss Log Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: James Livingston
Assignee: David Lloyd
Log4j Loggers have a getParent() method, whose return value is set up by JBossLogManagerFacade.updateParents(). The method locates the closest parent node which has an existing Log4J logger created *at the time*. This results in the parent being different depending on the order Log4j loggers are used in.
Consider:
Logger.getLogger("a");
Logger.getLogger("a.b.c");
Logger.getLogger("a.b");
When the second line causes updateParents() to be called, LoggerNode.getOrCreate() has already created the intermediate "a.b" node. That does not yet have a Log4j Logger created, so the Logger for "a" is returned. Original log4j would have returned "a.b" due to it using the parent structure in the implementation.
--
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, 3 months
[JBoss JIRA] (JGRP-1800) OverlappingMergeTest testRegularMessageSending does not receive all expected mcast messages
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1800?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1800:
---------------------------
Fix Version/s: 3.5
> OverlappingMergeTest testRegularMessageSending does not receive all expected mcast messages
> -------------------------------------------------------------------------------------------
>
> Key: JGRP-1800
> URL: https://issues.jboss.org/browse/JGRP-1800
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL, Solairis
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13, 3.5
>
>
> testRegularMessageSending is a kind of smoke test for the stack used in OverlappingMergeTest:
> - three channels a,b,c are created with a particular stack (see modifyConfigs)
> - each of a,b,c sends 5 multicast messages to the group, with message payloads "1", "2", "3", "4", "5"
> - the receiver in each channel collects up the multicasts received
> - the test checks that all 15 messages are received by each of the channels, and an assertion error is thrown is this is not the case
> This test is failing occasionally. An example of the error:
> {noformat}
> Error Message
> (C) num_mcasts=C: 1 C: 2 C: 3 C: 4 C: 5 A: 1 B: 1 A: 2 B: 2 B: 3 B: 4 A: 4 B: 5 A: 5 expected: 15)
> Stacktrace
> java.lang.AssertionError
> at org.jgroups.tests.OverlappingMergeTest.checkReceivedMessages(OverlappingMergeTest.java:476)
> at org.jgroups.tests.OverlappingMergeTest.testRegularMessageSending(OverlappingMergeTest.java:66)
> {noformat}
> This assertion error indicates that multicast #3 was not received from A by C.
> This is a very simple scenario and failures should not be occurring. I mention this error as there are other merge tests, namely:
> * testOverlappingMergeWithBC
> * testOverlappingMergeWithABC
> which are more complex, but when we look at their failures, they fail on an initial step similar to the one described above.
--
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, 3 months