[JBoss JIRA] (DROOLS-4651) Scenario: Review Save interaction in Settings panel.
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-4651?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton closed DROOLS-4651.
-------------------------------------
Resolution: Done
resolved
> Scenario: Review Save interaction in Settings panel.
> -----------------------------------------------------
>
> Key: DROOLS-4651
> URL: https://issues.jboss.org/browse/DROOLS-4651
> Project: Drools
> Issue Type: Enhancement
> Components: Test Scenarios Editor
> Reporter: Elizabeth Clayton
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: 2019-10-15-1.png, 2019-10-15.png
>
>
> The use of a Save button in the Settings panel is inconsistent with other "properties" panel in the overall application. The purpose of this jira is to revisit the use case scenarios to determine if the inclusion of the Save button here is appropriate.
> Verification conditions:
> * Documented rationale for the keeping the Save button, as is, with Team acceptance.
> or
> * Documented rationale for removing the Save button, with Team acceptance, in addition to any design changes needed as a result of its removal.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (WFLY-12793) Marshalling.river No standard field found for reverse order comparator
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-12793?page=com.atlassian.jira.plugin... ]
Paul Ferraro closed WFLY-12793.
-------------------------------
Resolution: Rejected
[~ropalka] His application bundles infinispan-jcache and its dependencies. Thus, his application should bundle the marshalling library appropriate for that particular version of Infinispan. WildFly's jboss-marshalling module is not actually being used.
[~emiliocuberos] Given the above, I'm going to close this, as this isn't a WildFly issue, but rather an issue with the libraries bundled with your application. If you are still stuck, open an issue against the ISPN project.
> Marshalling.river No standard field found for reverse order comparator
> ----------------------------------------------------------------------
>
> Key: WFLY-12793
> URL: https://issues.jboss.org/browse/WFLY-12793
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 17.0.1.Final
> Reporter: Emilio Cuberos
> Assignee: Paul Ferraro
> Priority: Major
>
> There are lots of reports of this issue, and they were closed with the workaround of including jboss-marshalling and jboss-marshalling-river 2.6.0.
> I still get the same error, even in Wildfly 17.0.1.Final, where jboss-marshalling 2.0.6 should be already included.
> The full error-stack is:
> {code}
> 14:16:53,582 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (ServerService Thread Pool -- 99) ISPN000136: Error executing command PutKeyValueCommand, writing keys [1]: java.lang.ExceptionInInitializerError
> at deployment.healthtrender-cloud-1.0.0.war//org.jboss.marshalling.river.RiverMarshaller.<clinit>(RiverMarshaller.java:1233)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.commons.marshall.jboss.JBossMarshallerFactory.createMarshaller(JBossMarshallerFactory.java:49)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller$PerThreadInstanceHolder.getMarshaller(AbstractJBossMarshaller.java:314)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.startObjectOutput(AbstractJBossMarshaller.java:90)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.marshall.core.VersionAwareMarshaller.startObjectOutput(VersionAwareMarshaller.java:110)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.commons.marshall.AbstractDelegatingMarshaller.startObjectOutput(AbstractDelegatingMarshaller.java:30)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.marshall.core.MarshalledValue.serialize(MarshalledValue.java:92)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.marshall.core.MarshalledValue.<init>(MarshalledValue.java:79)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.interceptors.MarshalledValueInterceptor.createMarshalledValue(MarshalledValueInterceptor.java:318)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.interceptors.MarshalledValueInterceptor.visitPutKeyValueCommand(MarshalledValueInterceptor.java:133)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:78)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:191)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:177)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:78)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:114)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:83)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:43)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:78)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1672)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.cache.impl.CacheImpl.putInternal(CacheImpl.java:1121)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1111)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.cache.impl.DecoratedCache.put(DecoratedCache.java:453)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.jcache.AbstractJCache.put(AbstractJCache.java:241)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.jcache.embedded.JCache.doPut(JCache.java:431)
> at deployment.healthtrender-cloud-1.0.0.war//org.infinispan.jcache.embedded.JCache.put(JCache.java:400)
> at deployment.healthtrender-cloud-1.0.0.war//com.hemocue.cloud.config.CacheSetup.lambda$loadCaches$10(CacheSetup.java:94)
> at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1654)
> at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
> at deployment.healthtrender-cloud-1.0.0.war//com.hemocue.cloud.config.CacheSetup.loadCaches(CacheSetup.java:92)
> at deployment.healthtrender-cloud-1.0.0.war//com.hemocue.cloud.config.CacheSetup.init(CacheSetup.java:85)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 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.as.ee@17.0.1.Final//org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:96)
> at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.as.weld.common@17.0.1.Final//org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:79)
> at org.jboss.as.weld.common@17.0.1.Final//org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doLifecycleInterception(Jsr299BindingsInterceptor.java:126)
> at org.jboss.as.weld.common@17.0.1.Final//org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:112)
> at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.core@3.1.1.Final//org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.common@17.0.1.Final//org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.weld@17.0.1.Final//org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:53)
> at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee@17.0.1.Final//org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.weld@17.0.1.Final//org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.weld@17.0.1.Final//org.jboss.as.weld.interceptors.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:111)
> at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee@17.0.1.Final//org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3@17.0.1.Final//org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:237)
> at org.jboss.as.ejb3@17.0.1.Final//org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:388)
> at org.jboss.as.ejb3@17.0.1.Final//org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:68)
> at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.weld@17.0.1.Final//org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3@17.0.1.Final//org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee@17.0.1.Final//org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3@17.0.1.Final//org.jboss.as.ejb3.component.singleton.StartupCountDownInterceptor.processInvocation(StartupCountDownInterceptor.java:25)
> at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee@17.0.1.Final//org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> at org.jboss.as.ee@17.0.1.Final//org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> at org.jboss.as.ee@17.0.1.Final//org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> at org.jboss.as.ejb3@17.0.1.Final//org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:127)
> at org.jboss.as.ejb3@17.0.1.Final//org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:141)
> at org.jboss.as.ee@17.0.1.Final//org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.base/java.lang.Thread.run(Thread.java:834)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: java.lang.IllegalStateException: No standard field found for reverse order comparator!
> at deployment.healthtrender-cloud-1.0.0.war//org.jboss.marshalling.river.Protocol.<clinit>(Protocol.java:220)
> ... 87 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (DROOLS-4724) [DMN Designer] Do not default to a LiteralExpression when no expression is defined
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-4724?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-4724:
----------------------------------------
Thanks [~tari_manga].
> [DMN Designer] Do not default to a LiteralExpression when no expression is defined
> ----------------------------------------------------------------------------------
>
> Key: DROOLS-4724
> URL: https://issues.jboss.org/browse/DROOLS-4724
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Major
> Attachments: image-2019-11-04-19-39-01-113.png, image-2019-11-04-19-40-27-201.png
>
>
> Currently, the DMN Editor will default to a blank LiteralExpression on Save if the user did not provide an expression for an element.
> However Error message is reported anyway to the user:
> !image-2019-11-04-19-39-01-113.png|thumbnail!
> This also as the (imho undesired) side-effect that if the user was to re-open later that file, instead of a empty element, it would be a blank LiteralExpression
> !image-2019-11-04-19-40-27-201.png|thumbnail!
> so the current behavior is not consistent across re-open of the editor.
> Let's revert this default.
> The DMN Editor on save should +not+ default to a blank LiteralExpression if the user did not provide an expression for the element.
> Once this change is applied from the f/e side, I am happy to be involved in order to assess which of the messages reported by the Validator or the Compiler are causing issue to the WB (if any).
> Currently, the DMN Compiler will throw 1 Warning.
> Currently, the DMN Validator will throw 1 Error (I can align this to be a Warn too).
> Currently, the DMN Validator schema check is not reporting any XSD violation.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (DROOLS-4724) [DMN Designer] Do not default to a LiteralExpression when no expression is defined
by Matteo Mortari (Jira)
[ https://issues.jboss.org/browse/DROOLS-4724?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-4724:
----------------------------------------
as of this morning I have already raised a PR which makes the validation Error a Warn to be consistent when a Decision is missing the expression. BKM will remain unvaried, as Error level.
I expect it will result in having only 1 message, at Warn, once the PR above is merged and the WB applies the changes described here --as the validator consolidate "duplicate" message coming from static-validation and compilation.
> [DMN Designer] Do not default to a LiteralExpression when no expression is defined
> ----------------------------------------------------------------------------------
>
> Key: DROOLS-4724
> URL: https://issues.jboss.org/browse/DROOLS-4724
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Major
> Attachments: image-2019-11-04-19-39-01-113.png, image-2019-11-04-19-40-27-201.png
>
>
> Currently, the DMN Editor will default to a blank LiteralExpression on Save if the user did not provide an expression for an element.
> However Error message is reported anyway to the user:
> !image-2019-11-04-19-39-01-113.png|thumbnail!
> This also as the (imho undesired) side-effect that if the user was to re-open later that file, instead of a empty element, it would be a blank LiteralExpression
> !image-2019-11-04-19-40-27-201.png|thumbnail!
> so the current behavior is not consistent across re-open of the editor.
> Let's revert this default.
> The DMN Editor on save should +not+ default to a blank LiteralExpression if the user did not provide an expression for the element.
> Once this change is applied from the f/e side, I am happy to be involved in order to assess which of the messages reported by the Validator or the Compiler are causing issue to the WB (if any).
> Currently, the DMN Compiler will throw 1 Warning.
> Currently, the DMN Validator will throw 1 Error (I can align this to be a Warn too).
> Currently, the DMN Validator schema check is not reporting any XSD violation.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (DROOLS-4724) [DMN Designer] Do not default to a LiteralExpression when no expression is defined
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-4724?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-4724:
----------------------------------------
[~tari_manga] FYI a PR has been submitted to remove the creation of a {{LiteralExpression}} by default in the workbench.
When a DMN file is saved in the workbench DMN validation is executed and an incremental compilation. Therefore, at present, the User is presented with two messages. As you state above; one ERROR and one WARNING. I'll leave it to you how best to consolidate.
> [DMN Designer] Do not default to a LiteralExpression when no expression is defined
> ----------------------------------------------------------------------------------
>
> Key: DROOLS-4724
> URL: https://issues.jboss.org/browse/DROOLS-4724
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Major
> Attachments: image-2019-11-04-19-39-01-113.png, image-2019-11-04-19-40-27-201.png
>
>
> Currently, the DMN Editor will default to a blank LiteralExpression on Save if the user did not provide an expression for an element.
> However Error message is reported anyway to the user:
> !image-2019-11-04-19-39-01-113.png|thumbnail!
> This also as the (imho undesired) side-effect that if the user was to re-open later that file, instead of a empty element, it would be a blank LiteralExpression
> !image-2019-11-04-19-40-27-201.png|thumbnail!
> so the current behavior is not consistent across re-open of the editor.
> Let's revert this default.
> The DMN Editor on save should +not+ default to a blank LiteralExpression if the user did not provide an expression for the element.
> Once this change is applied from the f/e side, I am happy to be involved in order to assess which of the messages reported by the Validator or the Compiler are causing issue to the WB (if any).
> Currently, the DMN Compiler will throw 1 Warning.
> Currently, the DMN Validator will throw 1 Error (I can align this to be a Warn too).
> Currently, the DMN Validator schema check is not reporting any XSD violation.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months