[JBoss JIRA] (DROOLS-3953) DMN UX - error highlight in boxed expression.
by Daniele Zonca (Jira)
[ https://issues.jboss.org/browse/DROOLS-3953?page=com.atlassian.jira.plugi... ]
Daniele Zonca commented on DROOLS-3953:
---------------------------------------
[~zhutaojiajia]
As I said before it is not clear the scope of this ticket and it should be DMN related so I don't know if we can consider it closed.
[~uxdlc] Wdyt?
> DMN UX - error highlight in boxed expression.
> ---------------------------------------------
>
> Key: DROOLS-3953
> URL: https://issues.jboss.org/browse/DROOLS-3953
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Elizabeth Clayton
> Assignee: Tao Zhu
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam, drools-tools
> Attachments: Error reporting after test run-different kinds.png, Error reporting after test run-different kinds2.png, Error reporting after test run-popup.png, Error reporting after test run-popup.png, Error reporting after test run.png, ux-decision button.png, ux-decision table.png
>
>
> As user after a test run, I want see not only the cell that are not correct (red background) but also the reason.
> For instance have the possibility to see the actual value that is different from the expected or the error message.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 10 months
[JBoss JIRA] (DROOLS-3953) DMN UX - error highlight in boxed expression.
by Tao Zhu (Jira)
[ https://issues.jboss.org/browse/DROOLS-3953?page=com.atlassian.jira.plugi... ]
Tao Zhu commented on DROOLS-3953:
---------------------------------
[~danielezonca] Hi Daniele, there is no new update, could I close this task?
> DMN UX - error highlight in boxed expression.
> ---------------------------------------------
>
> Key: DROOLS-3953
> URL: https://issues.jboss.org/browse/DROOLS-3953
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Elizabeth Clayton
> Assignee: Tao Zhu
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam, drools-tools
> Attachments: Error reporting after test run-different kinds.png, Error reporting after test run-different kinds2.png, Error reporting after test run-popup.png, Error reporting after test run-popup.png, Error reporting after test run.png, ux-decision button.png, ux-decision table.png
>
>
> As user after a test run, I want see not only the cell that are not correct (red background) but also the reason.
> For instance have the possibility to see the actual value that is different from the expected or the error message.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 10 months
[JBoss JIRA] (JGRP-2273) ASYM_ENCRYPT: deprecate encrypt_entire_message
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2273?page=com.atlassian.jira.plugin.... ]
Bela Ban reopened JGRP-2273:
----------------------------
OK, I'm not happy with SERIALIZE anyway (cost of serialization/deserialization). I'll look into what can be done when I return from my PTO.
Do you think {{encrypt_entire_message}} is a required feature?
> ASYM_ENCRYPT: deprecate encrypt_entire_message
> ----------------------------------------------
>
> Key: JGRP-2273
> URL: https://issues.jboss.org/browse/JGRP-2273
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.2
>
>
> In {{ASYM_ENCRYPT}}, {{encrypt_entire_message}} encrypts not only the payload, but also metadata such as destination and sender's address, headers and flags.
> The rationale was to prevent replay attacks. However, this is not an issue, as replayed messages will simply get dropped by the retransmission layer (e.g. NAKACK2 or UNICAST3).
> If people still want this feature, they can write a protocol _above_ {{ASYM_ENCRYPT}}, which serializes the entire message into the payload of a new message, and this would be exactly the same as setting {{encrypt_entire_message}} to {{true}}.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 10 months
[JBoss JIRA] (JGRP-2273) ASYM_ENCRYPT: deprecate encrypt_entire_message
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2273?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2273:
---------------------------
Fix Version/s: 4.1.2
(was: 4.0.12)
> ASYM_ENCRYPT: deprecate encrypt_entire_message
> ----------------------------------------------
>
> Key: JGRP-2273
> URL: https://issues.jboss.org/browse/JGRP-2273
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.2
>
>
> In {{ASYM_ENCRYPT}}, {{encrypt_entire_message}} encrypts not only the payload, but also metadata such as destination and sender's address, headers and flags.
> The rationale was to prevent replay attacks. However, this is not an issue, as replayed messages will simply get dropped by the retransmission layer (e.g. NAKACK2 or UNICAST3).
> If people still want this feature, they can write a protocol _above_ {{ASYM_ENCRYPT}}, which serializes the entire message into the payload of a new message, and this would be exactly the same as setting {{encrypt_entire_message}} to {{true}}.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 10 months
[JBoss JIRA] (WFLY-12244) MaximumTimeoutTestCase fails a lot
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-12244?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka closed WFLY-12244.
-----------------------------------
Resolution: Out of Date
[~kabirkhan] permit me, please, to close this issue.
>From what I can see the CI runs pass succesfuly with this test now. The last fail[1] was 5 days ago (https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=...).
The failures were observed on Windows JDK11 and on Elytron JDK8. Those configuration were the failing ones. The JDK version the error was reported was `11.0.2`.
We investigated the failure by running locally on Windows JDK11, on Narayana CI with JDK 11 `.0.2` and `.0.3.`.
I started the testing run to isolate the test run on CI at https://github.com/wildfly/wildfly/pull/12407 as well.
All those attempts passed without issue. It seems as an intermittent failure of the CI envirionment from this perspective.
[1]
{code}
java.lang.reflect.UndeclaredThrowableException
at com.sun.proxy.$Proxy23.runTestMethod(Unknown Source)
at org.jboss.arquillian.protocol.jmx.JMXMethodExecutor.invoke(JMXMethodExecutor.java:81)
at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:103)
at jdk.internal.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:52)
at jdk.internal.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:128)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:118)
at jdk.internal.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:116)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:83)
at jdk.internal.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
at jdk.internal.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:139)
at org.jboss.arquillian.junit.MethodInvoker.invoke(MethodInvoker.java:15)
at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:332)
at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:204)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:350)
at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:215)
at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:285)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:166)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:350)
at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:177)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
Caused by: java.io.IOException: Unable to invoke invoke(), status=WAITING
at org.jboss.remotingjmx.protocol.v2.ClientConnection$TheConnection.invoke(ClientConnection.java:1072)
at org.jboss.as.arquillian.container.ManagementClient$MBeanConnectionProxy.invoke(ManagementClient.java:762)
at java.management/javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:298)
... 75 more
------- Stdout: -------
06:15:04,302 WARN [org.jboss.as.txn] (management-handler-thread - 2) WFLYTX0039: A value of zero is not permitted for the maximum timeout, as such the timeout has been set to 400
06:15:04,333 WARN [org.jboss.as.txn] (management-handler-thread - 2) WFLYTX0039: A value of zero is not permitted for the maximum timeout, as such the timeout has been set to 500
06:16:04,209 ERROR [org.jboss.threads.errors] (XNIO-1 task-5) Thread Thread[XNIO-1 task-5,5,main] threw an uncaught exception: java.lang.IllegalThreadStateException
at java.base/java.lang.ThreadGroup.addUnstarted(ThreadGroup.java:865)
at java.base/java.lang.Thread.<init>(Thread.java:435)
at java.base/java.lang.Thread.<init>(Thread.java:709)
at java.base/java.lang.Thread.<init>(Thread.java:630)
at org.jboss.remotingjmx.protocol.v2.ClientExecutorManager$1.newThread(ClientExecutorManager.java:56)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.<init>(ThreadPoolExecutor.java:623)
at java.base/java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:912)
at java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1354)
at org.jboss.remotingjmx.protocol.v2.ClientExecutorManager.execute(ClientExecutorManager.java:64)
at org.jboss.remotingjmx.protocol.v2.ClientCommon$MessageReceiver.handleMessage(ClientCommon.java:118)
at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:975)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.base/java.lang.Thread.run(Thread.java:834)
{code}
> MaximumTimeoutTestCase fails a lot
> ----------------------------------
>
> Key: WFLY-12244
> URL: https://issues.jboss.org/browse/WFLY-12244
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite, Transactions
> Reporter: Kabir Khan
> Assignee: Ondrej Chaloupka
> Priority: Critical
>
> This is failing a lot on CI for loads of pull requests: https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=...
> It also happens on master JDK 11 https://ci.wildfly.org/viewLog.html?buildId=156368&buildTypeId=WF_MasterW...
> CC [~tomjenkinson] [~ochaloup] [~zhfeng]
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 10 months
[JBoss JIRA] (WFLY-12267) Upgrade java-support to 7.3.0 for opensmal 3.3.0
by Jim Ma (Jira)
Jim Ma created WFLY-12267:
-----------------------------
Summary: Upgrade java-support to 7.3.0 for opensmal 3.3.0
Key: WFLY-12267
URL: https://issues.jboss.org/browse/WFLY-12267
Project: WildFly
Issue Type: Task
Components: Web Services
Affects Versions: 17.0.0.Final
Reporter: Jim Ma
Assignee: Jim Ma
Fix For: 18.0.0.Beta1
OpenSmal 3.3.0 depends on java-support 7.3.0.
We need to upgrade java-support dependency from 7.1.1 to 7.3.0
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 10 months
[JBoss JIRA] (DROOLS-4161) Scenario Test: UX for DMN Decision service
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-4161?page=com.atlassian.jira.plugi... ]
Klara Kufova commented on DROOLS-4161:
--------------------------------------
[~danielezonca], in that case, I suggest waiting for having DROOLS-3570 implemented before adding the option to the *Settings* panel (or anywhere else). At the moment, I don't think it is necessary to provide the option to switch from whole DMN model to decision service and vice versa. User can always create a completely new test scenario asset. We can create a Jira for adding this functionality, which would be blocked by DROOLS-3570. WDYT?
> Scenario Test: UX for DMN Decision service
> ------------------------------------------
>
> Key: DROOLS-4161
> URL: https://issues.jboss.org/browse/DROOLS-4161
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Tao Zhu
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
>
> As user I want to test my decision service from a DMN model.
> User needs to specify DMN model and decision service name to be tested.
> Note: a decision service contains only a subset of decisions so the template (header) need to be updated/recreated or the information needs to be available during template creation
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 10 months
[JBoss JIRA] (DROOLS-4161) Scenario Test: UX for DMN Decision service
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-4161?page=com.atlassian.jira.plugi... ]
Klara Kufova edited comment on DROOLS-4161 at 7/2/19 3:18 AM:
--------------------------------------------------------------
[~danielezonca], in that case, I suggest waiting for having DROOLS-3570 implemented before adding the option to the *Settings* panel (or anywhere else). At the moment, I don't think it is necessary to provide the option to switch from a whole DMN model to a decision service and vice versa. User can always create a completely new test scenario asset. We can create a Jira for adding this functionality, which would be blocked by DROOLS-3570. WDYT?
was (Author: kkufova):
[~danielezonca], in that case, I suggest waiting for having DROOLS-3570 implemented before adding the option to the *Settings* panel (or anywhere else). At the moment, I don't think it is necessary to provide the option to switch from whole DMN model to decision service and vice versa. User can always create a completely new test scenario asset. We can create a Jira for adding this functionality, which would be blocked by DROOLS-3570. WDYT?
> Scenario Test: UX for DMN Decision service
> ------------------------------------------
>
> Key: DROOLS-4161
> URL: https://issues.jboss.org/browse/DROOLS-4161
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Tao Zhu
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
>
> As user I want to test my decision service from a DMN model.
> User needs to specify DMN model and decision service name to be tested.
> Note: a decision service contains only a subset of decisions so the template (header) need to be updated/recreated or the information needs to be available during template creation
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 10 months