[JBoss JIRA] (WFLY-6381) CDI Event handler after transaction success fails to call transactional method
by Guillermo G (JIRA)
[ https://issues.jboss.org/browse/WFLY-6381?page=com.atlassian.jira.plugin.... ]
Guillermo G commented on WFLY-6381:
-----------------------------------
I'm also suffering from this. Any news or available workarounds?
> CDI Event handler after transaction success fails to call transactional method
> ------------------------------------------------------------------------------
>
> Key: WFLY-6381
> URL: https://issues.jboss.org/browse/WFLY-6381
> Project: WildFly
> Issue Type: Feature Request
> Components: CDI / Weld, EJB, JCA
> Affects Versions: 10.0.0.Final
> Environment: Windows 7, Java 1.8.51
> Reporter: Ján Halaša
> Assignee: Stuart Douglas
> Attachments: AfterSuccessTest.zip, wildfly.log
>
>
> Scenario:
> # EJB transactional business method fires a CDI event
> # The CDI event is handled by an event observer configured to receive event after its transaction succeeds (during = TransactionPhase.AFTER_SUCCESS)
> # The event handler calls another EJB transactional method, but the call fails with a ResourceException, error code IJ000459 (last part of its stacktrace pasted below). Full log is attached as a file. I think, when the handler is called, the original transaction should not be there anymore and a new one should be created.
> I attached a simple test web application with a servlet which triggers the sequence described before. I tried the test application on Weblogic 12.2.1 and it worked without problems. The application requires a data source - H2 in-memory is good enough, table will be created automatically by JPA.
> {code:java}
> Caused by: javax.resource.ResourceException: IJ000460: Error checking for a transaction
> at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:424)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:747)
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
> ... 196 more
> Caused by: javax.resource.ResourceException: IJ000459: Transaction is not active: tx=TransactionImple < ac, BasicAction: 0:ffffac180a71:3fd5e4ea:56e93a24:184 status: ActionStatus.COMMITTED >
> at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:408)
> ... 198 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (ELY-651) Add error message with information that is not allowed to read secret-value and entry-type from Credential Store
by Hynek Švábek (JIRA)
Hynek Švábek created ELY-651:
--------------------------------
Summary: Add error message with information that is not allowed to read secret-value and entry-type from Credential Store
Key: ELY-651
URL: https://issues.jboss.org/browse/ELY-651
Project: WildFly Elytron
Issue Type: Bug
Components: Credential Store
Reporter: Hynek Švábek
Assignee: Peter Skopek
Priority: Minor
Add error message with information that is not allowed to read secret value from Credential Store over CLI.
This CLI commands
{code}
/subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=secret-value)
/subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=entry-type)
{code}
end with success result.
{code}
{
"outcome" => "success",
"result" => undefined
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (ELY-651) Add error message with information that is not allowed to read secret-value and entry-type from Credential Store
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/ELY-651?page=com.atlassian.jira.plugin.sy... ]
Hynek Švábek updated ELY-651:
-----------------------------
Description:
Add error message with information that is not allowed to read secret-value and entry-type from Credential Store over CLI.
This CLI commands
{code}
/subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=secret-value)
/subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=entry-type)
{code}
end with success result.
{code}
{
"outcome" => "success",
"result" => undefined
}
{code}
was:
Add error message with information that is not allowed to read secret value from Credential Store over CLI.
This CLI commands
{code}
/subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=secret-value)
/subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=entry-type)
{code}
end with success result.
{code}
{
"outcome" => "success",
"result" => undefined
}
{code}
> Add error message with information that is not allowed to read secret-value and entry-type from Credential Store
> ----------------------------------------------------------------------------------------------------------------
>
> Key: ELY-651
> URL: https://issues.jboss.org/browse/ELY-651
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
> Priority: Minor
>
> Add error message with information that is not allowed to read secret-value and entry-type from Credential Store over CLI.
> This CLI commands
> {code}
> /subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=secret-value)
> /subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=entry-type)
> {code}
> end with success result.
> {code}
> {
> "outcome" => "success",
> "result" => undefined
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFCORE-1853) Ctrl-C could lead to alias not being persisted
by Jean-Francois Denise (JIRA)
Jean-Francois Denise created WFCORE-1853:
--------------------------------------------
Summary: Ctrl-C could lead to alias not being persisted
Key: WFCORE-1853
URL: https://issues.jboss.org/browse/WFCORE-1853
Project: WildFly Core
Issue Type: Bug
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
The bug WFCORE-1729 has revealed it. It seems to only occur on Windows.
I think that a small windows exists (possibly in Aesh) that makes the shutdown hook to not be properly invoked.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-7265) Adding Elytron ldap-realm through CLI throws IllegalArgumentException
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-7265:
----------------------------------
Summary: Adding Elytron ldap-realm through CLI throws IllegalArgumentException
Key: WFLY-7265
URL: https://issues.jboss.org/browse/WFLY-7265
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
In case when ldap-realm is added through CLI then IllegalArgumentException is thrown in all cases when values for {{identity-mapping.user-password-mapper.writable}} and {{identity-mapping.user-password-mapper.verifiable}} are not set.
According to read-attribute operation these attributes (writable and verifiable) should has set default values hence they should not be required by CLI.
Following exception is thrown to server log:
{code}
ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "elytron"),
("ldap-realm" => "ldap")
]): java.lang.IllegalArgumentException
at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69)
at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
at org.wildfly.extension.elytron.LdapRealmDefinition$UserPasswordCredentialMappingObjectDefinition.configure(LdapRealmDefinition.java:163)
at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.configureIdentityMapping(LdapRealmDefinition.java:420)
at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.performRuntime(LdapRealmDefinition.java:375)
at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
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 org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-7265) Adding Elytron ldap-realm through CLI throws IllegalArgumentException
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7265?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-7265:
-------------------------------
Affects Version/s: 11.0.0.Alpha1
> Adding Elytron ldap-realm through CLI throws IllegalArgumentException
> ---------------------------------------------------------------------
>
> Key: WFLY-7265
> URL: https://issues.jboss.org/browse/WFLY-7265
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> In case when ldap-realm is added through CLI then IllegalArgumentException is thrown in all cases when values for {{identity-mapping.user-password-mapper.writable}} and {{identity-mapping.user-password-mapper.verifiable}} are not set.
> According to read-attribute operation these attributes (writable and verifiable) should has set default values hence they should not be required by CLI.
> Following exception is thrown to server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("ldap-realm" => "ldap")
> ]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69)
> at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
> at org.wildfly.extension.elytron.LdapRealmDefinition$UserPasswordCredentialMappingObjectDefinition.configure(LdapRealmDefinition.java:163)
> at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.configureIdentityMapping(LdapRealmDefinition.java:420)
> at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.performRuntime(LdapRealmDefinition.java:375)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 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 org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-7254) pattern-filter disappears if predefined-filter is used for configurable-sasl-server-factory in Elytron subsystem
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7254?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev commented on WFLY-7254:
-------------------------------------
[~olukas] You are right that the following command should lead to "outcome" => "failed" so to fix the issue I'll work on changing the code to prevent such commands.
Invalid CLI command which should be prevented:
{code}
/subsystem=elytron/configurable-sasl-server-factory=someFactory:add(sasl-server-factory=global,filters=[{pattern-filter=(.*),predefined-filter=BINDING}])
{code}
Valid command:
{code}
/subsystem=elytron/configurable-sasl-server-factory=someFactory:add(sasl-server-factory=global,filters=[{pattern-filter=(.*), enabling="false"},{predefined-filter=BINDING}])
{code}
Configuration after executing it:
{code}
<configurable-sasl-server-factory name="someFactory" sasl-server-factory="global">
<filters>
<filter enabling="false">
<pattern-filter value="(.*)"/>
</filter>
<filter>
<predefined-filter value="BINDING"/>
</filter>
</filters>
</configurable-sasl-server-factory>
{code}
The above configuration can be correctly loaded when server is started:
{code}
/subsystem=elytron/configurable-sasl-server-factory=someFactory:read-attribute(name=filters)
{
"outcome" => "success",
"result" => [
{
"enabling" => false,
"pattern-filter" => "(.*)"
},
{"predefined-filter" => "BINDING"}
]
}
{code}
> pattern-filter disappears if predefined-filter is used for configurable-sasl-server-factory in Elytron subsystem
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7254
> URL: https://issues.jboss.org/browse/WFLY-7254
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Ilia Vassilev
> Fix For: 11.0.0.Alpha1
>
>
> In case when configurable-sasl-server-factory is created through CLI with filter which uses both pattern-filter and predefined-filter, then only predefined-filter is stored into configuration (pattern-filter disappears).
> Suggestion:
> In case when usage of both filters is unsupported option, then it should be denied by CLI. In case when it is supported option, then both of them should be stored in configuration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months