[JBoss JIRA] (DROOLS-4847) [DMN Designer] Entries are expanded when user edit structures in a row
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-4847?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-4847:
--------------------------------
Attachment: edit-in-a-row.webm
> [DMN Designer] Entries are expanded when user edit structures in a row
> -----------------------------------------------------------------------
>
> Key: DROOLS-4847
> URL: https://issues.redhat.com/browse/DROOLS-4847
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.31.0.Final
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Minor
> Labels: drools-tools
> Attachments: edit-in-a-row.webm
>
>
> There is scenario causing user is not able to save the DMN file anymore. If is editing some multilevel structure field, but he decides in the middle of editing to remove whole top level structure, the save button of the designer remains disabled. See the attached video.
> We should either fix this scenario or drop the *disable save button* feature.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (DROOLS-4846) [DMN Designer] User is unable to save model when multilevel structure is removed
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-4846?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-4846:
--------------------------------
Priority: Minor (was: Major)
> [DMN Designer] User is unable to save model when multilevel structure is removed
> --------------------------------------------------------------------------------
>
> Key: DROOLS-4846
> URL: https://issues.redhat.com/browse/DROOLS-4846
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.31.0.Final
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Minor
> Labels: drools-tools
> Attachments: multilevel-structure.webm
>
>
> There is scenario causing user is not able to save the DMN file anymore. If is editing some multilevel structure field, but he decides in the middle of editing to remove whole top level structure, the save button of the designer remains disabled. See the attached video.
> We should either fix this scenario or drop the *disable save button* feature.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (DROOLS-4846) [DMN Designer] User is unable to save model when multilevel structure is removed
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-4846?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-4846:
--------------------------------
Description:
There is scenario causing user is not able to save the DMN file anymore. If is editing some multilevel structure field, but he decides in the middle of editing to remove whole top level structure, the save button of the designer remains disabled. See the attached video.
We should either fix this scenario or drop the *disable save button* feature.
was:
There is scenario causing user is not able to save the DMN file anymore. If is editing some structure field, but he decides in the middle of editing to rmeove whole structure, the save button of the designer remains disabled.
We should either fix this scenario or drop the *disable save button* feature.
> [DMN Designer] User is unable to save model when multilevel structure is removed
> --------------------------------------------------------------------------------
>
> Key: DROOLS-4846
> URL: https://issues.redhat.com/browse/DROOLS-4846
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.31.0.Final
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
> Attachments: multilevel-structure.webm
>
>
> There is scenario causing user is not able to save the DMN file anymore. If is editing some multilevel structure field, but he decides in the middle of editing to remove whole top level structure, the save button of the designer remains disabled. See the attached video.
> We should either fix this scenario or drop the *disable save button* feature.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (DROOLS-4846) [DMN Designer] User is unable to save model when multilevel structure is removed
by Jozef Marko (Jira)
Jozef Marko created DROOLS-4846:
-----------------------------------
Summary: [DMN Designer] User is unable to save model when multilevel structure is removed
Key: DROOLS-4846
URL: https://issues.redhat.com/browse/DROOLS-4846
Project: Drools
Issue Type: Bug
Components: DMN Editor
Affects Versions: 7.31.0.Final
Reporter: Jozef Marko
Assignee: Daniel José dos Santos
Attachments: multilevel-structure.webm
There is scenario causing user is not able to save the DMN file anymore. If is editing some structure field, but he decides in the middle of editing to rmeove whole structure, the save button of the designer remains disabled.
We should either fix this scenario or drop the *disable save button* feature.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (DROOLS-4846) [DMN Designer] User is unable to save model when multilevel structure is removed
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-4846?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-4846:
--------------------------------
Attachment: multilevel-structure.webm
> [DMN Designer] User is unable to save model when multilevel structure is removed
> --------------------------------------------------------------------------------
>
> Key: DROOLS-4846
> URL: https://issues.redhat.com/browse/DROOLS-4846
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.31.0.Final
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
> Attachments: multilevel-structure.webm
>
>
> There is scenario causing user is not able to save the DMN file anymore. If is editing some structure field, but he decides in the middle of editing to rmeove whole structure, the save button of the designer remains disabled.
> We should either fix this scenario or drop the *disable save button* feature.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFWIP-278) MP Fault Tolerance - @Retry(maxRetries = 1) does not work
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFWIP-278?page=com.atlassian.jira.plugin... ]
Radoslav Husar commented on WFWIP-278:
--------------------------------------
This is certainly a smallrye implementation issue probably not covered by the TCK, will investigate upstream and with the spec TCK.
> MP Fault Tolerance - @Retry(maxRetries = 1) does not work
> ---------------------------------------------------------
>
> Key: WFWIP-278
> URL: https://issues.redhat.com/browse/WFWIP-278
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Fault Tolerance
> Reporter: Miroslav Novak
> Assignee: Radoslav Husar
> Priority: Critical
>
> if method in MP FT deployment is annotated by {{@Retry(maxRetries = -1)}} then it should it should retry forever until the method returns without exception. However it does not work.
> Actual result: Exception is thrown from annotated {{@Retry(maxRetries = -1)}}
> Expected result: Retry forever until the method returns without exception.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFWIP-279) FaultTolerance subsystem gets MP Config properties values too many times
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFWIP-279?page=com.atlassian.jira.plugin... ]
Radoslav Husar commented on WFWIP-279:
--------------------------------------
[~istraka] Does your server profile in the test have the microprofile-config subsystem added?
> FaultTolerance subsystem gets MP Config properties values too many times
> ------------------------------------------------------------------------
>
> Key: WFWIP-279
> URL: https://issues.redhat.com/browse/WFWIP-279
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Config, MP Fault Tolerance
> Reporter: Ivan Straka
> Assignee: Radoslav Husar
> Priority: Blocker
>
> I have a fail safe service that would normally return a value provided by a provider A or a value from provider B on fallback (in case the provider A throws an exception). Providers return values based on MP Config property. Source of the properties is a ConfigSource class that reads a property file.
> The issue is ConfigSource#getProperties method is called too may times that results to Too many open files exception:
> {code:java}
> 13:41:48,959 ERROR [stderr] (MSC service thread 1-4) java.io.FileNotFoundException: /home/istraka/repositories/github/eap-microprofile-test-suite/microprofile-metrics/target/test-classes/org/jboss/eap/qe/microprofile/metrics/integration/ft/ft-custom-metric.properties (Too many open files)
> 13:41:48,960 ERROR [stderr] (MSC service thread 1-4) at java.io.FileInputStream.open0(Native Method)
> 13:41:48,960 ERROR [stderr] (MSC service thread 1-4) at java.io.FileInputStream.open(FileInputStream.java:195)
> 13:41:48,960 ERROR [stderr] (MSC service thread 1-4) at java.io.FileInputStream.<init>(FileInputStream.java:138)
> 13:41:48,960 ERROR [stderr] (MSC service thread 1-4) at java.io.FileInputStream.<init>(FileInputStream.java:93)
> 13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at org.jboss.eap.qe.microprofile.metrics.integration.ft.FTCustomConfigSource.getProperties(FTCustomConfigSource.java:25)
> 13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at org.jboss.eap.qe.microprofile.metrics.integration.ft.FTCustomConfigSource.getValue(FTCustomConfigSource.java:37)
> 13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at io.smallrye.config.SmallRyeConfig.getValue(SmallRyeConfig.java:84)
> 13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at io.smallrye.config.SmallRyeConfig.getOptionalValue(SmallRyeConfig.java:106)
> 13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at io.smallrye.faulttolerance.config.FaultToleranceOperation.getConfigStatus(FaultToleranceOperation.java:250)
> 13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at io.smallrye.faulttolerance.config.FaultToleranceOperation.getConfig(FaultToleranceOperation.java:209)
> 13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at io.smallrye.faulttolerance.config.FaultToleranceOperation.of(FaultToleranceOperation.java:51)
> 13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at io.smallrye.faulttolerance.HystrixExtension.collectFaultToleranceOperations(HystrixExtension.java:112)
> 13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
> 13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at java.lang.reflect.Method.invoke(Method.java:498)
> 13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:95)
> 13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:85)
> 13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:168)
> 13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:330)
> 13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:123)
> 13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:308)
> 13:41:48,984 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:286)
> 13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at javax.enterprise.inject.spi.ObserverMethod.notify(ObserverMethod.java:124)
> 13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.util.Observers.notify(Observers.java:166)
> 13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:285)
> 13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:273)
> 13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:177)
> 13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:171)
> 13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:53)
> 13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:44)
> 13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.bootstrap.events.ProcessManagedBeanImpl.fire(ProcessManagedBeanImpl.java:31)
> 13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessBean(ContainerLifecycleEvents.java:246)
> 13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessBean(ContainerLifecycleEvents.java:240)
> 13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.bootstrap.AbstractBeanDeployer.fireProcessBeanEvents(AbstractBeanDeployer.java:128)
> 13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.bootstrap.BeanDeployer.deploy(BeanDeployer.java:331)
> 13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:264)
> 13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:453)
> 13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:86)
> 13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:97)
> 13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> 13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> 13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> 13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> 13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> 13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> 13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> 13:41:48,985 ERROR [stderr] (MSC service thread 1-4) at java.lang.Thread.run(Thread.java:748)
> {code}
> This happens when a deployment is deployed. There is no issue with ConfigSource class as it reads the file correctly on the first time.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months