[JBoss JIRA] (WFLY-6885) Exception swallowed by CmtTxInterceptor if transaction has been cancelled by reaper
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-6885?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski reassigned WFLY-6885:
------------------------------------
Assignee: Tomasz Adamski
> Exception swallowed by CmtTxInterceptor if transaction has been cancelled by reaper
> -----------------------------------------------------------------------------------
>
> Key: WFLY-6885
> URL: https://issues.jboss.org/browse/WFLY-6885
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Marcel Kolsteren
> Assignee: Tomasz Adamski
> Attachments: tx-timeout.zip
>
>
> The CMTTxInterceptor is responsible for starting a transaction if a public method is called on a session bean, and for ending it (commit or rollback) after the method has returned. If a runtime exception occurs during the execution of the public method, WildFly normally throws an EJBException with the original exception as cause. However, if the transaction has timed out, it swallows the original exception, and throws a EJBTransactionRolledBackException without a root cause. That obscures what actually happened during the execution of the public method.
> I attached a zip with an small Arquillian project that shows (1) what happens in case of an exception in combination with an active transaction (the succeeding test) and (2) what happens if the exception occurs when the transaction has timed out (the failing test).
> I think that the exception swallow is explainable as follows, referring to the 10.0.0.Final version of CMTTxInterceptor, that can be found here
> [https://github.com/wildfly/wildfly/blob/10.0.0.Final/ejb3/src/main/java/o...]
> This happens (I verified by stepping through the code with the debugger):
> * The catch block of invokeInOurTx is entered.
> * The method handleExceptionInOurTx tries to set the "rollback only" status on the transaction. The result is that the transaction, which has already been rolled back, stays in the rolled back state. A new EJBException is thrown, wrapping the original runtime exception.
> * The finally block of invokeInOurTx is entered.
> * The endTransaction method sees that the transaction is in the rolled back state, and concludes that the "reaper canceled (rolled back) tx case" is applicable. It throws a new exception (which replaces the EJBException that just has been thrown), but that new exception doesn't have a cause.
> The desired behavior would be that the interceptor only wraps the original exception in an EJBException in this case. I think that the invokeInOurTx method should only call the endTransaction method, if the transaction is not in the rolled back state.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-9585) Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-9585?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski commented on WFLY-9585:
--------------------------------------
I have created reproducer for this issue, but it seems to work correctly - can paste the fragment of the bean in which you use InitialContext to lookup the DataSource?
> Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
> ----------------------------------------------------------
>
> Key: WFLY-9585
> URL: https://issues.jboss.org/browse/WFLY-9585
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Environment: Wilfly-10.1.0.Final with jdk-1.8.0_31 under Red Hat Enterprise Linux Server release 5.11 (Tikanga)
> Reporter: Shing Lam
> Assignee: Tomasz Adamski
> Labels: Wildfly-10.0.0.Final, datasource, default, jboss-ejb3.xml, lookup-name, resource-ref
>
> We have a ear that use a datasource that is injected. The application runs normally in Jboss EAP 6.4, with the correct datasource being used. But when deployed to Wildfly-10.1.0_Final, instead of the datasource specified in the jboss-ejb3.xml, the default datasource is alway injected.
> We have in the ejb-jar.xml
> {code:xml}
> <enterprise-beans>
> <session>
> <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
> <resource-ref>
> <res-ref-name>jdbc/RMDataSource</res-ref-name>
> <res-type>javax.sql.DataSource</res-type>
> <res-auth>Container</res-auth>
> </resource-ref>
> <persistence-context-ref>
> <persistence-context-ref-name>persistence/RMEntityManager</persistence-context-ref-name>
> </persistence-context-ref>
> </session>
> {code}
> and in jboss-ejb3.xml
> {code:xml}
> <jboss:enterprise-beans>
> <jboss:ejb>
> <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
> <resource-ref>
> <res-ref-name>jdbc/RMDataSource</res-ref-name>
> <res-type>javax.sql.DataSource</res-type>
> <lookup-name>java:jboss/jdbc/RMDataSource</lookup-name>
> </resource-ref>
> </jboss:ejb>
> {code}
> the datasource java:jboss/jdbc/RMDataSource got injected into the EJB under JBoss EAP 6.4.
> But in WildFly 10.1, the default datasource java:jboss/datasources/ExampleDS was injected, causing "org.h2.jdbc.JdbcSQLException: Table "XXX" not found;"
> If we set the default datasource to java:jboss/jdbc/RMDataSource, java:jboss/jdbc/RMDataSource jot injected into the EJB.
> Seems like the jboss-ejb3.xml has no effect on WildFly 10.1, the default datasource is always used.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3073) Handle Shutdown via TERM gracefully
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3073?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3073:
-------------------------------------
Summary: Handle Shutdown via TERM gracefully (was: Handle TERM gracefully)
> Handle Shutdown via TERM gracefully
> -----------------------------------
>
> Key: WFCORE-3073
> URL: https://issues.jboss.org/browse/WFCORE-3073
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Ben Parees
> Assignee: Brian Stansberry
> Fix For: 4.0.0.Alpha5
>
>
> The wildfly server currently -terminates immediately- performs a standard (non-graceful) shutdown in response to a TERM signal. To achieve a -clean- graceful shutdown requires invoking the CLI tooling. This is particularly problematic in container environments like kubernetes where the container process (wildfly in this case) is going to get a TERM signal when the container needs to be moved.
> While it's possible to wrapper the process and handle the TERM and then invoke the CLI, it would be preferable for the server process itself to cleanly handle a TERM signal by waiting for in-flight requests to complete (w/ some grace period of course).
> Having this as configurable behavior would be good if there are backwards compatibility concerns about introducing this behavior change.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3452) If the legacy SecurityRealm references a non-existant alias in the CredentialStore a null password is assumed.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3452?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-3452:
-------------------------------------
Description:
We may need to double check CredentialStore references in general as a reference to non-existant alias probably should cause service start up to fail.
{noformat}
18:41:45,072 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.core.management.security.realm.SimpleSSL.key-manager: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.SimpleSSL.key-manager: WFLYDM0018: Unable to start service
at org.jboss.as.domain.management.security.AbstractKeyManagerService.start(AbstractKeyManagerService.java:91)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.security.UnrecoverableKeyException: Password must not be null
at sun.security.provider.JavaKeyStore.engineGetKey(JavaKeyStore.java:132)
at sun.security.provider.JavaKeyStore$JKS.engineGetKey(JavaKeyStore.java:56)
at sun.security.provider.KeyStoreDelegator.engineGetKey(KeyStoreDelegator.java:96)
at sun.security.provider.JavaKeyStore$DualFormatJKS.engineGetKey(JavaKeyStore.java:70)
at java.security.KeyStore.getKey(KeyStore.java:1023)
at sun.security.ssl.SunX509KeyManagerImpl.<init>(SunX509KeyManagerImpl.java:133)
at sun.security.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:70)
at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:256)
at org.jboss.as.domain.management.security.AbstractKeyManagerService.createKeyManagers(AbstractKeyManagerService.java:140)
at org.jboss.as.domain.management.security.AbstractKeyManagerService.start(AbstractKeyManagerService.java:89)
... 5 more
{noformat}
was:We may need to double check CredentialStore references in general as a reference to non-existant alias probably should cause service start up to fail.
> If the legacy SecurityRealm references a non-existant alias in the CredentialStore a null password is assumed.
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3452
> URL: https://issues.jboss.org/browse/WFCORE-3452
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 3.0.9.Final, 4.0.0.Alpha4
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
>
> We may need to double check CredentialStore references in general as a reference to non-existant alias probably should cause service start up to fail.
> {noformat}
> 18:41:45,072 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.core.management.security.realm.SimpleSSL.key-manager: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.SimpleSSL.key-manager: WFLYDM0018: Unable to start service
> at org.jboss.as.domain.management.security.AbstractKeyManagerService.start(AbstractKeyManagerService.java:91)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.security.UnrecoverableKeyException: Password must not be null
> at sun.security.provider.JavaKeyStore.engineGetKey(JavaKeyStore.java:132)
> at sun.security.provider.JavaKeyStore$JKS.engineGetKey(JavaKeyStore.java:56)
> at sun.security.provider.KeyStoreDelegator.engineGetKey(KeyStoreDelegator.java:96)
> at sun.security.provider.JavaKeyStore$DualFormatJKS.engineGetKey(JavaKeyStore.java:70)
> at java.security.KeyStore.getKey(KeyStore.java:1023)
> at sun.security.ssl.SunX509KeyManagerImpl.<init>(SunX509KeyManagerImpl.java:133)
> at sun.security.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:70)
> at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:256)
> at org.jboss.as.domain.management.security.AbstractKeyManagerService.createKeyManagers(AbstractKeyManagerService.java:140)
> at org.jboss.as.domain.management.security.AbstractKeyManagerService.start(AbstractKeyManagerService.java:89)
> ... 5 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (DROOLS-2171) NullPointerException in drools core
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2171?page=com.atlassian.jira.plugi... ]
Edson Tirelli reassigned DROOLS-2171:
-------------------------------------
Assignee: Mario Fusco (was: Edson Tirelli)
> NullPointerException in drools core
> ------------------------------------
>
> Key: DROOLS-2171
> URL: https://issues.jboss.org/browse/DROOLS-2171
> Project: Drools
> Issue Type: Bug
> Reporter: Yun Lin
> Assignee: Mario Fusco
> Priority: Critical
> Labels: downstream_dependency
>
> After running for a couple hours, it got the follow NPE.
> java.lang.NullPointerException: null
> at org.drools.core.common.TupleSetsImpl.setNextTuple(TupleSetsImpl.java:349) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.common.TupleSetsImpl.removeUpdate(TupleSetsImpl.java:205) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.common.TupleSetsImpl.addDelete(TupleSetsImpl.java:110) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.phreak.SegmentPropagator.processPeerDeletes(SegmentPropagator.java:109) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.phreak.SegmentPropagator.processPeers(SegmentPropagator.java:48) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.phreak.SegmentPropagator.propagate(SegmentPropagator.java:41) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:347) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:127) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:212) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:87) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.concurrent.AbstractRuleEvaluator.internalEvaluateAndFire(AbstractRuleEvaluator.java:34) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.concurrent.SequentialRuleEvaluator.evaluateAndFire(SequentialRuleEvaluator.java:43) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1067) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1299) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-9604) wildfly-11.0.0.Final JPA
by Trond Tobiassen (JIRA)
Trond Tobiassen created WFLY-9604:
-------------------------------------
Summary: wildfly-11.0.0.Final JPA
Key: WFLY-9604
URL: https://issues.jboss.org/browse/WFLY-9604
Project: WildFly
Issue Type: Feature Request
Components: EJB
Affects Versions: 11.0.0.Final
Environment: Javaee 7, Windows 7, jdk 8 151
Reporter: Trond Tobiassen
Fix For: 12.0.0.Alpha1
I am deploying to above. I get this error message:
{"jboss.persistenceunit.registrar#REGDB" => "org.hibernate.AnnotationException: Property no.tobiassenit.sipstack.sip.message.AbstractMessage.part has an unbound type and no explicit target entity. Resolve this Generic usage issue or set an explicit target attribute (eg @OneToMany(target=) or use an explicit @Type Caused by: org.hibernate.AnnotationException: Property no.tobiassenit.sipstack.sip.message.AbstractMessage.part has an unbound type and no explicit target entity. Resolve this Generic usage issue or set an explicit target attribute (eg @OneToMany(target=) or use an explicit @Type"},
I have this code:
@OneToOne(optional = true, cascade = CascadeType.ALL, targetEntity = AbstractPart.class)
@JoinColumn(name = "PART", unique = false, nullable = true, updatable = false)
protected X part;
What about the target= vs the targetEntity=? There is no target attribute or @Type annotation available.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (DROOLS-2171) NullPointerException in drools core
by Yun Lin (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2171?page=com.atlassian.jira.plugi... ]
Yun Lin updated DROOLS-2171:
----------------------------
Issue Type: Bug (was: Feature Request)
> NullPointerException in drools core
> ------------------------------------
>
> Key: DROOLS-2171
> URL: https://issues.jboss.org/browse/DROOLS-2171
> Project: Drools
> Issue Type: Bug
> Reporter: Yun Lin
> Assignee: Edson Tirelli
> Priority: Critical
> Labels: downstream_dependency
>
> After running for a couple hours, it got the follow NPE.
> java.lang.NullPointerException: null
> at org.drools.core.common.TupleSetsImpl.setNextTuple(TupleSetsImpl.java:349) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.common.TupleSetsImpl.removeUpdate(TupleSetsImpl.java:205) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.common.TupleSetsImpl.addDelete(TupleSetsImpl.java:110) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.phreak.SegmentPropagator.processPeerDeletes(SegmentPropagator.java:109) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.phreak.SegmentPropagator.processPeers(SegmentPropagator.java:48) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.phreak.SegmentPropagator.propagate(SegmentPropagator.java:41) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:347) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:127) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:212) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:87) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.concurrent.AbstractRuleEvaluator.internalEvaluateAndFire(AbstractRuleEvaluator.java:34) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.concurrent.SequentialRuleEvaluator.evaluateAndFire(SequentialRuleEvaluator.java:43) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1067) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1299) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months