[JBoss JIRA] (DROOLS-3041) [DMN Designer] Can not edit node after diagram cleared
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-3041?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3041:
--------------------------------
Description:
If user clears the diagram and then add new node, he is unable to edit this node.
h2. Acceptance test
h3. New diagram (/)
- Add nodes
- Clear
- Add new decision node
- Put some expression inside
h3. Non empty existing diagram (/)
- Clear
- Add new decision node
- Put some expression inside
- Save reopen
was:
If user clears the diagram and then add new node, he is unable to edit this node.
h2. Acceptance test
h3. New diagram (/)
- Add nodes
- Clear
- Add new decision node
- Put some expression inside
h3. Non empty existing diagram
- Clear
- Add new decision node
- Put some expression inside
- Save reopen
> [DMN Designer] Can not edit node after diagram cleared
> ------------------------------------------------------
>
> Key: DROOLS-3041
> URL: https://issues.jboss.org/browse/DROOLS-3041
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.12.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Labels: drools-tools
> Attachments: DMCommunity Challenge - March 2017.dmn, Screenshot from 2018-09-26 13-18-33.png
>
>
> If user clears the diagram and then add new node, he is unable to edit this node.
> h2. Acceptance test
> h3. New diagram (/)
> - Add nodes
> - Clear
> - Add new decision node
> - Put some expression inside
> h3. Non empty existing diagram (/)
> - Clear
> - Add new decision node
> - Put some expression inside
> - Save reopen
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (DROOLS-3041) [DMN Designer] Can not edit node after diagram cleared
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-3041?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3041:
--------------------------------
Description:
If user clears the diagram and then add new node, he is unable to edit this node.
h2. Acceptance test
h3. New diagram (/)
- Add nodes
- Clear
- Add new decision node
- Put some expression inside
h3. Non empty existing diagram
- Clear
- Add new decision node
- Put some expression inside
- Save reopen
was:
If user clears the diagram and then add new node, he is unable to edit this node.
h2. Acceptance test
h3. New diagram
- Add nodes
- Clear
- Add new decision node
- Put some expression inside
h3. Non empty existing diagram
- Clear
- Add new decision node
- Put some expression inside
- Save reopen
> [DMN Designer] Can not edit node after diagram cleared
> ------------------------------------------------------
>
> Key: DROOLS-3041
> URL: https://issues.jboss.org/browse/DROOLS-3041
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.12.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Labels: drools-tools
> Attachments: DMCommunity Challenge - March 2017.dmn, Screenshot from 2018-09-26 13-18-33.png
>
>
> If user clears the diagram and then add new node, he is unable to edit this node.
> h2. Acceptance test
> h3. New diagram (/)
> - Add nodes
> - Clear
> - Add new decision node
> - Put some expression inside
> h3. Non empty existing diagram
> - Clear
> - Add new decision node
> - Put some expression inside
> - Save reopen
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (WFCORE-4143) Embed CLI failures on IBM jdk - checkLogging
by Petr Kremensky (JIRA)
Petr Kremensky created WFCORE-4143:
--------------------------------------
Summary: Embed CLI failures on IBM jdk - checkLogging
Key: WFCORE-4143
URL: https://issues.jboss.org/browse/WFCORE-4143
Project: WildFly Core
Issue Type: Bug
Components: Test Suite
Environment: IBM JDK
{noformat}
java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 8.0.5.20 - pxa6480sr5fp20-20180802_01(SR5 FP20))
IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20180731_393394 (JIT enabled, AOT enabled)
OpenJ9 - bd23af8
OMR - ca1411c
IBM - 98805ca)
JCL - 20180719_01 based on Oracle jdk8u181-b12
{noformat}
Reporter: Petr Kremensky
{{testLogging}} for Cli tests in Wildfly-core testsuite fails on IBM JDK.
*reproduce*
cd wildfly-core/testsuite
mvn clean test -fae -Dts.manualmode -pl manualmode,standalone -Dtest=CLIEmbedHostControllerTestCase,CLIEmbedServerTestCase,SilentModeTestCase
...
[ERROR] Failures:
[ERROR] SilentModeTestCase.testLogging:99->checkIfEmpty:152
[INFO]
[ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0
...
[ERROR] Failures:
[ERROR] CLIEmbedHostControllerTestCase.testHelp:321->checkLogging:744
[ERROR] CLIEmbedHostControllerTestCase.testStdOutDefault:160->stdoutTest:188->checkClientSideLogging:231->checkLogging:744
[ERROR] CLIEmbedHostControllerTestCase.testStdOutDiscard:166->stdoutTest:188->checkClientSideLogging:231->checkLogging:744
[ERROR] CLIEmbedHostControllerTestCase.testStdOutEcho:172->stdoutTest:188->checkClientSideLogging:231->checkLogging:744
[ERROR] CLIEmbedServerTestCase.testHelp:543->checkLogging:764
[ERROR] CLIEmbedServerTestCase.testStdOutDefault:196->stdoutTest:224->checkClientSideLogging:267->checkLogging:764
[ERROR] CLIEmbedServerTestCase.testStdOutDiscard:202->stdoutTest:224->checkClientSideLogging:267->checkLogging:764
[ERROR] CLIEmbedServerTestCase.testStdOutEcho:208->stdoutTest:224->checkClientSideLogging:267->checkLogging:764
[INFO]
[ERROR] Tests run: 51, Failures: 8, Errors: 0, Skipped: 0
{noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (WFLY-11092) XtsAsLogger doesn't compile on JDK11
by Petr Kremensky (JIRA)
Petr Kremensky created WFLY-11092:
-------------------------------------
Summary: XtsAsLogger doesn't compile on JDK11
Key: WFLY-11092
URL: https://issues.jboss.org/browse/WFLY-11092
Project: WildFly
Issue Type: Bug
Components: XTS
Environment: {noformat}
java version "11" 2018-09-25
Java(TM) SE Runtime Environment 18.9 (build 11+28)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode)
{noformat}
Reporter: Petr Kremensky
Assignee: Ondra Chaloupka
Compilation failure on JDK 11 introduced by https://github.com/wildfly/wildfly/pull/11702
{noformat}
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile (default-compile) on project wildfly-xts: Compilation failure
[ERROR] /home/pkremens/devel/wildfly/xts/target/generated-sources/annotations/org/jboss/as/xts/logging/XtsAsLogger_$logger.java:[11,22] '.' expected
{noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (WFLY-9455) WFLYTX0001: Unable to roll back active transaction thrown for EJB bridge transactions
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-9455?page=com.atlassian.jira.plugin.... ]
Petr Kremensky commented on WFLY-9455:
--------------------------------------
[~ochaloup] Heads up, this one doesn't compile on JDK11
{noformat}
$ java -version
java version "11" 2018-09-25
Java(TM) SE Runtime Environment 18.9 (build 11+28)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode)
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] /home/pkremens/devel/wildfly/xts/target/generated-sources/annotations/org/jboss/as/xts/logging/XtsAsLogger_$logger.java:[11,22] '.' expected
[INFO] 1 error
{noformat}
I'll file a separate issue.
> WFLYTX0001: Unable to roll back active transaction thrown for EJB bridge transactions
> -------------------------------------------------------------------------------------
>
> Key: WFLY-9455
> URL: https://issues.jboss.org/browse/WFLY-9455
> Project: WildFly
> Issue Type: Bug
> Components: XTS
> Affects Versions: 11.0.0.CR1
> Reporter: Ondra Chaloupka
> Assignee: Ondra Chaloupka
> Fix For: 15.0.0.Alpha1
>
>
> It happens to get exception
> {code}
> ERROR [org.jboss.as.txn] (default task-12) WFLYTX0003: APPLICATION ERROR: transaction still active in request with status 0
> ERROR [org.jboss.as.txn] (default task-12) WFLYTX0001: Unable to roll back active transaction: javax.transaction.SystemException: WFTXN0032: Rollback not allowed on imported transaction
> at org.wildfly.transaction.client.LocalTransaction.rollbackAndDissociate(LocalTransaction.java:100)
> at org.wildfly.transaction.client.ContextTransactionManager.rollback(ContextTransactionManager.java:83)
> at org.jboss.as.txn.deployment.TransactionRollbackSetupAction.checkTransactionStatus(TransactionRollbackSetupAction.java:137)
> at org.jboss.as.txn.deployment.TransactionRollbackSetupAction.teardown(TransactionRollbackSetupAction.java:67)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1510)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> 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)
> {code}
> when using XTS transactions bridged to JTA for EJB handling. This happens on change of integration layer for WFTC in WFLY11.
> The integration issues were already discussed as part of the JBTM-2853.
> Here I hit a trouble of having log filled with the exception mentioned above. This does not cause a functionality trouble but the log is ugly filled with ERRORs.
> The trouble seems to be caused by the fact that transaction is imported on ivocation of WS
> https://github.com/wildfly/wildfly/blob/master/webservices/server-integra...
> but as it was suspended in the integration code before
> https://github.com/jbosstm/narayana/blob/master/txbridge/src/main/java/or...
> now the WFTC holds the notion about the transaction even on call of
> https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java...
> and such transaction is tried to be rollback which is forbidden on WFTC for imported ones and thus at least ERROR msg is written to the log.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (WFCORE-4142) [GSS](7.1.z) Elytron does not do RunAs identity remote propagation
by Teresa Miyar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4142?page=com.atlassian.jira.plugi... ]
Teresa Miyar moved JBEAP-15553 to WFCORE-4142:
----------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-4142 (was: JBEAP-15553)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
> [GSS](7.1.z) Elytron does not do RunAs identity remote propagation
> ------------------------------------------------------------------
>
> Key: WFCORE-4142
> URL: https://issues.jboss.org/browse/WFCORE-4142
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Teresa Miyar
> Assignee: Teresa Miyar
>
> Elytron does not do RunAs identity remote propagation
> -> EJB with @RunAs("ejbuser") -> remote EJB , where Elytron security forwarding is configured, @RunAs is not working. And caused authentication error when trying to call the 2nd server when @RunAs is added.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (WFCORE-4142) Elytron does not do RunAs identity remote propagation
by Teresa Miyar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4142?page=com.atlassian.jira.plugi... ]
Teresa Miyar updated WFCORE-4142:
---------------------------------
Summary: Elytron does not do RunAs identity remote propagation (was: [GSS](7.1.z) Elytron does not do RunAs identity remote propagation)
> Elytron does not do RunAs identity remote propagation
> -----------------------------------------------------
>
> Key: WFCORE-4142
> URL: https://issues.jboss.org/browse/WFCORE-4142
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Teresa Miyar
> Assignee: Teresa Miyar
>
> Elytron does not do RunAs identity remote propagation
> -> EJB with @RunAs("ejbuser") -> remote EJB , where Elytron security forwarding is configured, @RunAs is not working. And caused authentication error when trying to call the 2nd server when @RunAs is added.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (WFLY-10912) CodecSessionConfig#findSessionId() causes an incorrect JSESSIONID Set-Cookie header
by Masafumi Miura (JIRA)
[ https://issues.jboss.org/browse/WFLY-10912?page=com.atlassian.jira.plugin... ]
Masafumi Miura commented on WFLY-10912:
---------------------------------------
[~pferraro], I understand the responsibility of the CodecSessionConfig, but WildFly should not respond back with the JSESSIONID Cookie which is not a valid session id.
> CodecSessionConfig#findSessionId() causes an incorrect JSESSIONID Set-Cookie header
> -----------------------------------------------------------------------------------
>
> Key: WFLY-10912
> URL: https://issues.jboss.org/browse/WFLY-10912
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 13.0.0.Final, 14.0.0.Beta2
> Reporter: Masafumi Miura
> Assignee: Paul Ferraro
>
> This issue is very similar to WFLY-10262/JBEAP-14641 but the condition causing the problem is a bit different.
> The issue happens when the client sends JSESSIONID Cookie in the request to the web application does NOT use HttpSession. JSESSIONID Set-Cookie response header should not be sent in this scenario, but WildFly/EAP 7 returns the response with JSESSIONID reusing the requested session id which does not exist in the session manager.
> The fix for WFLY-10262 / JBEAP-14641 added AttachmentKey SESSION_ID_SET to avoid invoking CodecSessionConfig#setSessionId() more than once. However, the fix does not help for this issue because CodecSessionConfig#setSessionId() is not invoked (= SESSION_ID_SET is null) before the problematic CodecSessionConfig#findSessionId() processing in this scenario.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months