[JBoss JIRA] (WFLY-6919) Nested Call of EJBs from one call of client from frontend works with @TransactionAttribute(REQUIRES_NEW)
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-6919?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed WFLY-6919.
-------------------------------
Resolution: Rejected
Please discuss in the forums first: https://developer.jboss.org/en/wildfly
Please do consider tagging me in your discussion if you don't get feedback in a few days but it looks like an EJB issue (either in the server, or in the app) rather than a transaction one.
> Nested Call of EJBs from one call of client from frontend works with @TransactionAttribute(REQUIRES_NEW)
> --------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6919
> URL: https://issues.jboss.org/browse/WFLY-6919
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 9.0.1.Final
> Environment: Java 8
> Reporter: Serg Jakean19019
> Assignee: Tom Jenkinson
>
> Case:
> - client calls ejb1 through frontend
> - ejb1 (stateless) process and saves some info
> - ejb1 calls method ejb2 (stateless)
> - ejb2 access saved info by ejb1 and saves something too
> if Method of ejb2 has Annotation @TransactionAttribute(REQUIRES_NEW) than it works. In other case there is error. For example: javax.ejb.EJBTransactionRolledbackException: WFLYJPA0060: Transaction is required to perform this operation (either use a transaction or extended persistence context.
> Ejbs are injected simply (@Inject) in other Ejbs
> These calls must be one transaction to tell the truth. What is right solution and way? Or is there any problem in Transaction Management in Wildfly?
> Sorry if it is no Wildfly issue and concerns discussion in forum.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6922) Default value for "realm" option in RealmUsersRolesLoginModule isn't set.
by Hynek Švábek (JIRA)
Hynek Švábek created WFLY-6922:
----------------------------------
Summary: Default value for "realm" option in RealmUsersRolesLoginModule isn't set.
Key: WFLY-6922
URL: https://issues.jboss.org/browse/WFLY-6922
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Hynek Švábek
Assignee: Darran Lofthouse
Default value for "realm" option in RealmUsersRolesLoginModule isn't set.
I can see default value for "realm" option in documentation https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-appli....
But I have to set this option explicitly otherwise I will get NPE exception.
In my opinion problem is here https://github.com/jbossas/jboss-eap7/blob/7.x/security/subsystem/src/mai....
{code}
2016-08-04 10:58:19,415 DEBUG [org.jboss.security] (management task-9) PBOX00206: Login failure: javax.security.auth.login.LoginException: java.lang.NullPointerException
at org.jboss.sasl.util.UsernamePasswordHashUtil.stringToByte(UsernamePasswordHashUtil.java:86)
at org.jboss.sasl.util.UsernamePasswordHashUtil.generateHashedURP(UsernamePasswordHashUtil.java:131)
at org.jboss.sasl.util.UsernamePasswordHashUtil.generateHashedHexURP(UsernamePasswordHashUtil.java:156)
at org.jboss.sasl.util.UsernamePasswordHashUtil.generateHashedHexURP(UsernamePasswordHashUtil.java:162)
at org.jboss.as.security.RealmUsersRolesLoginModule.createPasswordHash(RealmUsersRolesLoginModule.java:71)
at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:263)
at org.jboss.security.auth.spi.UsersRolesLoginModule.login(UsersRolesLoginModule.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:406)
at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345)
at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:323)
at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146)
at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:406)
at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:367)
at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:347)
at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:174)
at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:175)
at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:162)
at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:141)
at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:161)
at org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:52)
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:239)
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:257)
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:225)
at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:124)
at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:99)
at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:92)
at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:802)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:856)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:406)
at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345)
at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:323)
at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146)
at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:406)
at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:367)
at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:347)
at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:174)
at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:175)
at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:162)
at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:141)
at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:161)
at org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:52)
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:239)
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:257)
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:225)
at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:124)
at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:99)
at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:92)
at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:802)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6921) org.wildfly.test.extension.rts.InboundBridgeTestCase failing when transaction uses JTS
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-6921?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson moved JBEAP-1626 to WFLY-6921:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6921 (was: JBEAP-1626)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Test Suite
(was: Test Suite)
Affects Version/s: (was: 7.0.0.DR12)
> org.wildfly.test.extension.rts.InboundBridgeTestCase failing when transaction uses JTS
> --------------------------------------------------------------------------------------
>
> Key: WFLY-6921
> URL: https://issues.jboss.org/browse/WFLY-6921
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Ondra Chaloupka
> Assignee: Gytis Trikleris
>
> There is failures in testcase org.wildfly.test.extension.rts.InboundBridgeTestCase when transaction uses JTS.
> Example of the failure
> {code}
> testCommit(org.wildfly.test.extension.rts.InboundBridgeTestCase) Time elapsed: 2.54 sec <<< FAILURE!
> java.lang.AssertionError: expected:<4> but was:<5>
> {code}
> The JBOSS_HOME distribution is change to transaction to be run with JTS: changing the {{docs/example/standalone-rts.xml}} to switch transactions parameter in iiop orb subsystem to {{full}} and adding {{jts}} element to transactions subsystem.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6921) org.wildfly.test.extension.rts.InboundBridgeTestCase failing when transaction uses JTS
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-6921?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on WFLY-6921:
-------------------------------------
Done - thanks for the report :)
> org.wildfly.test.extension.rts.InboundBridgeTestCase failing when transaction uses JTS
> --------------------------------------------------------------------------------------
>
> Key: WFLY-6921
> URL: https://issues.jboss.org/browse/WFLY-6921
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Ondra Chaloupka
> Assignee: Gytis Trikleris
>
> There is failures in testcase org.wildfly.test.extension.rts.InboundBridgeTestCase when transaction uses JTS.
> Example of the failure
> {code}
> testCommit(org.wildfly.test.extension.rts.InboundBridgeTestCase) Time elapsed: 2.54 sec <<< FAILURE!
> java.lang.AssertionError: expected:<4> but was:<5>
> {code}
> The JBOSS_HOME distribution is change to transaction to be run with JTS: changing the {{docs/example/standalone-rts.xml}} to switch transactions parameter in iiop orb subsystem to {{full}} and adding {{jts}} element to transactions subsystem.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-1247) ForceEagerActivationOption may cause a recursive segment initialization
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-1247:
-----------------------------------
Summary: ForceEagerActivationOption may cause a recursive segment initialization
Key: DROOLS-1247
URL: https://issues.jboss.org/browse/DROOLS-1247
Project: Drools
Issue Type: Bug
Components: core engine
Reporter: Mario Fusco
Assignee: Mario Fusco
Priority: Blocker
ForceEagerActivationOption may cause a recursive segments initialization resulting in an infinite recursive linked list of segment memories like: smem1 -> smem2 -> smem1 -> ... When this happens the segments evaluation makes the engine to fall in an endless loop.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2095) FILE_PING rewrites files too often
by Dennis Reed (JIRA)
[ https://issues.jboss.org/browse/JGRP-2095?page=com.atlassian.jira.plugin.... ]
Dennis Reed commented on JGRP-2095:
-----------------------------------
Suggested fix:
remove writeToFile call from fetchClusterMembers
add a writeToFile call sometime during startup. (has to be after Event.SET_LOCAL_ADDRESS for local_addr, and after Event.CONNECT* for group_addr)
> FILE_PING rewrites files too often
> ----------------------------------
>
> Key: JGRP-2095
> URL: https://issues.jboss.org/browse/JGRP-2095
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Reporter: Dennis Reed
> Assignee: Bela Ban
>
> FILE_PING.fetchClusterMembers writes its own data to file on every call.
> If there is an issue finding a cluster member's address, fetchClusterMembers can be called very frequently by TP's GET_PHYSICAL_ADDRESS calls.
> This can cause problems because while that file is being (unnecessarily) overwritten, any readers will see an empty or corrupt file. If it's bad enough JGRP-1448 is not sufficient to handle it, and readers will end up thinking the file is stale and delete it (even while it's still in progress of being written). That missing file can then cascade the problem, with other nodes not being able to find this member's address, and triggering the same problem again.
> There is already a scheduled task to rewrite the file occasionally, so rewriting it on every fetchClusterMembers call is not needed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2095) FILE_PING rewrites files too often
by Dennis Reed (JIRA)
[ https://issues.jboss.org/browse/JGRP-2095?page=com.atlassian.jira.plugin.... ]
Dennis Reed commented on JGRP-2095:
-----------------------------------
Does not affect 3.5.0 or later, because JGRP-1841 completely changed how FILE_PING works (to a single file managed by the coord).
> FILE_PING rewrites files too often
> ----------------------------------
>
> Key: JGRP-2095
> URL: https://issues.jboss.org/browse/JGRP-2095
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Reporter: Dennis Reed
> Assignee: Bela Ban
>
> FILE_PING.fetchClusterMembers writes its own data to file on every call.
> If there is an issue finding a cluster member's address, fetchClusterMembers can be called very frequently by TP's GET_PHYSICAL_ADDRESS calls.
> This can cause problems because while that file is being (unnecessarily) overwritten, any readers will see an empty or corrupt file. If it's bad enough JGRP-1448 is not sufficient to handle it, and readers will end up thinking the file is stale and delete it (even while it's still in progress of being written). That missing file can then cascade the problem, with other nodes not being able to find this member's address, and triggering the same problem again.
> There is already a scheduled task to rewrite the file occasionally, so rewriting it on every fetchClusterMembers call is not needed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2095) FILE_PING rewrites files too often
by Dennis Reed (JIRA)
Dennis Reed created JGRP-2095:
---------------------------------
Summary: FILE_PING rewrites files too often
Key: JGRP-2095
URL: https://issues.jboss.org/browse/JGRP-2095
Project: JGroups
Issue Type: Bug
Affects Versions: 3.2.13
Reporter: Dennis Reed
Assignee: Bela Ban
FILE_PING.fetchClusterMembers writes its own data to file on every call.
If there is an issue finding a cluster member's address, fetchClusterMembers can be called very frequently by TP's GET_PHYSICAL_ADDRESS calls.
This can cause problems because while that file is being (unnecessarily) overwritten, any readers will see an empty or corrupt file. If it's bad enough JGRP-1448 is not sufficient to handle it, and readers will end up thinking the file is stale and delete it (even while it's still in progress of being written). That missing file can then cascade the problem, with other nodes not being able to find this member's address, and triggering the same problem again.
There is already a scheduled task to rewrite the file occasionally, so rewriting it on every fetchClusterMembers call is not needed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1695) Echo tab completion suggests variables without $ prefix
by Martin Schvarcbacher (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1695?page=com.atlassian.jira.plugi... ]
Martin Schvarcbacher moved JBEAP-5547 to WFCORE-1695:
-----------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1695 (was: JBEAP-5547)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
(was: CLI)
Affects Version/s: (was: 7.1.0.DR2)
> Echo tab completion suggests variables without $ prefix
> -------------------------------------------------------
>
> Key: WFCORE-1695
> URL: https://issues.jboss.org/browse/WFCORE-1695
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Martin Schvarcbacher
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> *Description:*
> echo command prints all variables in tab auto-complete even without typing $ prefix
> This duplicates functionality of 'set' with no arguments.
> *Steps to reproduce*
> {code:bash}
> [disconnected /] set myvar1=value1
> [disconnected /] set myvar2=value2
> [disconnected /] set
> myvar1=value1
> myvar2=value2
> {code}
> *Actual*
> {code:bash}
> [disconnected /] echo <TAB>
> --help myvar1 myvar2 #should not suggest variables
> [disconnected /] echo $<TAB>myvar<TAB> #expected, auto-completes with $prefix
> myvar1 myvar2
> [disconnected /] echo myvar<TAB> #autocompletes variable without $prefix
> myvar1 myvar2
> {code}
> *Expected*
> {code:bash}
> [disconnected /] echo <TAB>
> --help
> [disconnected /] echo $<TAB>myvar<TAB>
> myvar1 myvar2
> [disconnected /] echo myvar<TAB> #does not suggest anything
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6920) Enhance behavior of transaction propagation called over IIOP to not start 2PC when called ejb creates own new transaction
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-6920?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka moved JBEAP-5546 to WFLY-6920:
----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6920 (was: JBEAP-5546)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: EJB
IIOP
(was: EJB)
(was: IIOP)
Affects Version/s: 10.1.0.CR1
(was: 7.1.0.DR1)
> Enhance behavior of transaction propagation called over IIOP to not start 2PC when called ejb creates own new transaction
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6920
> URL: https://issues.jboss.org/browse/WFLY-6920
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB, IIOP
> Affects Versions: 10.1.0.CR1
> Reporter: Ondra Chaloupka
> Assignee: Tomasz Adamski
> Priority: Minor
>
> Based on discussion at jira JBEAP-5126 (https://issues.jboss.org/browse/JBEAP-5126?focusedCommentId=13271878#comm...) there could be a good enhancement for transaction propagated over ejb called over iiop to not start 2PC process when the called ejb creates its own new transaction ({{TransactionAttributeType.REQUIRES_NEW}}).
> Quoting Tom's comment here
> {quote}
> Yeah, its expected to be this way for JTS as the context is propagated
> over. It could be possible to register an enhancement in the iiop
> subsystem to remove the context from the thread if the EJB does not
> require a propagated transaction.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months