February 2014 - jboss-jira - Jboss List Archives

[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 Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-2936?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-2936: ------------------------------------ I saw this error on another jira recently (WFLY-2960). From the attached server.log, you can see the exception comes from a check in [AllowedMethodsInformation|https://github.com/wildfly/wildfly/blob/master/...] that (like the message indicates), the application attempted to access the UserTransaction from a container managed transaction. The attempt to look up the UT, is coming from Seam org.jboss.seam.transaction.Transaction.getUserTransaction() which isn't going to work from CMT beans in WildFly 8.0. The AllowedMethodsInformation.realCheckPermission() check is doing what it was intended to do. Can we relax the UserTransaction part of the check to not throw an error? > "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, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2898) JNDI Name lookup of the DataSource returns NULL

by Igor Shulika (JIRA)

[ https://issues.jboss.org/browse/WFLY-2898?page=com.atlassian.jira.plugin.... ] Igor Shulika commented on WFLY-2898: ------------------------------------ Thank you Emeric, The javamelody-core-1.50.0-SNAPSHOT fixed the issue. Please close this bug. > JNDI Name lookup of the DataSource returns NULL > ----------------------------------------------- > > Key: WFLY-2898 > URL: https://issues.jboss.org/browse/WFLY-2898 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Naming, Web (Undertow) > Affects Versions: 8.0.0.CR1, 8.0.0.Final > Reporter: Igor Shulika > Assignee: Eduardo Martins > Attachments: 1.PNG, 2.PNG, 3.PNG, jaffa-oracle-driver-6.0.0.Alpha2-SNAPSHOT.jar, server.log, standalone.conf.bat, standalone.xml, test.zip, test.zip > > > Hi, > I'm having a problem to obtain DataSource using JNDI Name lookup. > Please see my code below: > Connection connection = null; > DataSource dataSource = null; > try { > final Context initContext = new InitialContext(); > dataSource = (DataSource) initContext.lookup("java:/MyDataSource"); connection = dataSource.getConnection(); > } catch (Exception e) { > LOGGER.error(e); > } > I'm doing initContext.lookup from a servlet, everything is working on JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14). > Also I can find and test connection of my “java:/MyDataSource” under the “Datasources” section of the WildFly Administration Console just fine(anoter word the datasource is there). -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-802) Release PicketBox 4.0.21.Beta1

by Stefan Guilhen (JIRA)

[ https://issues.jboss.org/browse/SECURITY-802?page=com.atlassian.jira.plug... ] Stefan Guilhen closed SECURITY-802. ----------------------------------- Resolution: Done PicketBox 4.0.21.Beta1 has been released and is available on Nexus. > Release PicketBox 4.0.21.Beta1 > ------------------------------ > > Key: SECURITY-802 > URL: https://issues.jboss.org/browse/SECURITY-802 > Project: PicketBox > Issue Type: Release > Security Level: Public(Everyone can see) > Components: JBossSX, Security SPI > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1799) RpcDispatcher test fails when working with large values

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1799?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1799: --------------------------- Fix Version/s: (was: 3.5) > RpcDispatcher test fails when working with large values > ------------------------------------------------------- > > Key: JGRP-1799 > URL: https://issues.jboss.org/browse/JGRP-1799 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.13 > Environment: RHEL, Win, Solaris > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.2.13 > > > The two tests: > * testLargeReturnValue > * testLargeReturnValueUnicastCall > make RPC calls with values which are increasingly large. > The values used are in this range: > {noformat} > SIZES={10000, 20000, 40000, 80000, 100000, 200000, 400000, 800000,1000000, 2000000, 5000000} > {noformat} > The tests have been see to fail with the values 1000000, 2000000 and 5000000, always with the same error in each case. > In the case of testLargeReturnValue, the test fails because one of the returned values from the RPC is null. > In the case of testLargeReturnValueUnicastCall, the test fails due to a timeout while sending the RPC. > -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1797) NakackTest testReceptionOfAllMessages fails to receive all messages

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1797?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1797: --------------------------- Fix Version/s: (was: 3.5) > NakackTest testReceptionOfAllMessages fails to receive all messages > ------------------------------------------------------------------- > > Key: JGRP-1797 > URL: https://issues.jboss.org/browse/JGRP-1797 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.13 > Environment: RHEL (5/24), Solaris (6/24), HPUX (1/2) where x/y means x failures over y test executions. > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.2.13 > > Attachments: stdout.txt > > > This test does the following: > - involves channels A, B, and C where only B and C are senders and all are receivers > - B and C send 1000 multicast messages > - checks that all messages are received and in the correct order > This test is failing intermittently but quite often. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1795) OOBTest testRandomRegularAndOOBMulticasts fails to receive all messages

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1795?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1795: --------------------------- Fix Version/s: (was: 3.5) > OOBTest testRandomRegularAndOOBMulticasts fails to receive all messages > ----------------------------------------------------------------------- > > Key: JGRP-1795 > URL: https://issues.jboss.org/browse/JGRP-1795 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.13 > Environment: RHEL(3/24), WIN (1/6), Solaris (6/24) where (x/y) means x failures over y test executions. > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.2.13 > > > This test does the following with two channels a and b: > - adds a DISCARD layer to a to disccard 50% of down messages > - sends 20 messages to the group, randomly using a and b as senders, and randomly choosing OOB or non-OOB > - wait 10 seconds for 20 messages to be received by each of a and b > - print out the messages received > - remove the DISCARD layer from a > - wait 2.5 seconds for further messages to arrive > - assert that 20 messages have arrived for each channel a and b > The test fails on the assertion, with results such as: > {noformat} > expected 20 elements, but got 19 (list=[1, 4, 3, 8, 6, 7, 10, 13, 15, 20, 2, 5, 9, 12, 14, 16, 17, 18, 19]), missing=[0, 11] > {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, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1794) OOBTest method testNonBlockingUnicastOOBMessage fails to correctly receive all OOB mssages

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1794?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1794: --------------------------- Fix Version/s: (was: 3.5) Cannot reproduce this on 3.5 > OOBTest method testNonBlockingUnicastOOBMessage fails to correctly receive all OOB mssages > ------------------------------------------------------------------------------------------- > > Key: JGRP-1794 > URL: https://issues.jboss.org/browse/JGRP-1794 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.13 > Environment: Solaris, RHEL, Windows, HPUX > tcp stack only > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.2.13 > > > This test fails regularly on multiple platforms. It doesn't fail all the time, but perhaps on 5/10 platform executions. > The test consists of a sender and a receiver. The receiver B will receive OOB messages but blocks on a latch for 25 seconds when it receives a non-OOB message. After 25 seconds, it unblocks and continues receiving > The test does this: > - send 1 regular message from A -> B > - send 9 OOB meesages from A -> B > - wait 20 seconds for messages to arrive > - check that all 9 OOB messages have arrived > - unblock the latch > - check that all 10 message have arrived > The test failures all involve the first 9 OOB messages not arriving completely. For example, sample lists of received messages before the first 20 second interval are: > [3,2,6,8,9,10,4] > [2,3,4,8,9,5] > [2,3,4,8,7,9] > [2,3,5,4,6] > So, it appears that either the messages are slow to arrive or not arriving at all. > A correct result looks like this: > {noformat} > list = [2, 4, 3, 7, 8, 9, 10, 5, 6] > [main]: releasing latch > list = [2, 4, 3, 7, 8, 9, 10, 5, 6, 1] > {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, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1709) Logging: convert the most important WARN and ERROR messages to use IDs and resource bundles

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1709?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1709: --------------------------- Fix Version/s: 4.0 (was: 3.5) > Logging: convert the most important WARN and ERROR messages to use IDs and resource bundles > ------------------------------------------------------------------------------------------- > > Key: JGRP-1709 > URL: https://issues.jboss.org/browse/JGRP-1709 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > Convert WARN and ERROR messages that might be seen by users to use a resource bundle (conf/jg-messages*.properties) and assign unique IDs the those messages. > Link in BZ: https://bugzilla.redhat.com/show_bug.cgi?id=999671 -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1721) AUTH and ENCRYPT protocols configured with plain text passwords

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1721?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1721: -------------------------------- What's the deal, do we still need to fix this ? > AUTH and ENCRYPT protocols configured with plain text passwords > --------------------------------------------------------------- > > Key: JGRP-1721 > URL: https://issues.jboss.org/browse/JGRP-1721 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.4 > Reporter: Martin Gencur > Assignee: Bela Ban > Fix For: 3.5 > > > The following parameters of AUTH protocol are stored as plain text: > * keystore_password > The following parameters of ENCRYPT protocol are stored as plain text: > * store_password > * key_password > Example: > {code} > <ENCRYPT key_store_name="defaultStore.keystore" store_password="changeit" alias="myKey"/> > {code} > Requirements for storing passwords: https://docspace.corp.redhat.com/docs/DOC-131628 -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1792) "No buffer space available" when sending on Mac OS

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1792?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1792: --------------------------- Priority: Minor (was: Major) > "No buffer space available" when sending on Mac OS > -------------------------------------------------- > > Key: JGRP-1792 > URL: https://issues.jboss.org/browse/JGRP-1792 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.5 > > > When sending multicast messages (with MPerf & fast.xml), the following message appears: > {noformat} > 8981 [ERROR] UDP: JGRP000029: A: failed sending message to cluster (1053 bytes): java.io.IOException: No buffer space available, > headers: MPerf: DATA999, NAKACK2: [MSG, seqno=1003], UDP: [cluster_name=mperf] > {noformat} > The messages *are* received, but the error message occurs on almost every message (1 sender thread sending 1000 messages). > With {{UdpPerf}} (also shipped with JGroups), which also multicasts messages, the error doesn't happen. > With {{UPerf}}, which uses unicasts, the error doesn't occur either. > Todo: compare UdpPerf to MPerf (UDP protocol) to see what the diff is. -- 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, 4 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 February 2014