[JBoss JIRA] (DROOLS-4972) Buttons stay disabled when switching to textual collection editor
by Jozef Marko (Jira)
Jozef Marko created DROOLS-4972:
-----------------------------------
Summary: Buttons stay disabled when switching to textual collection editor
Key: DROOLS-4972
URL: https://issues.redhat.com/browse/DROOLS-4972
Project: Drools
Issue Type: Bug
Affects Versions: 7.32.0.Final
Reporter: Jozef Marko
Assignee: Mario Fusco
Attachments: define-list-and-save.webm
If user starts to create list using UI editor, then he decides to switch to textual editor - define list as expression, the buttons are disabled if user didn't canceled items 'in progress' in the UI editor. See the attached video.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-11963) ejb3 thread-pool thread-factory should be shown deprecated in management api
by Moulali Shikalwadi (Jira)
[ https://issues.redhat.com/browse/WFLY-11963?page=com.atlassian.jira.plugi... ]
Moulali Shikalwadi commented on WFLY-11963:
-------------------------------------------
Hi [~soul2zimate],
Are you working on this? Can I take it on me.
> ejb3 thread-pool thread-factory should be shown deprecated in management api
> ----------------------------------------------------------------------------
>
> Key: WFLY-11963
> URL: https://issues.redhat.com/browse/WFLY-11963
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 16.0.0.Final
> Reporter: Chao Wang
> Priority: Major
>
> ejb3 thread-pool thread-factory should be shown deprecated in management api
> The threads subsystem was deprecated and is not in the EAP 7.x configurations, so the thread-factory attribute on the ejb3 thread-pool configuration should indicate it is deprecated and should not be used.
> {code}
> /subsystem=ejb3/thread-pool=default:read-resource-description(
> "thread-factory" => {
> "type" => STRING,
> "description" => "Specifies the name of a specific thread factory to use to create worker threads. If not defined an appropriate default thread factory will be used.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-11548) RemoteExceptions and subclasses treated as ApplicationExceptions
by Moulali Shikalwadi (Jira)
[ https://issues.redhat.com/browse/WFLY-11548?page=com.atlassian.jira.plugi... ]
Moulali Shikalwadi reassigned WFLY-11548:
-----------------------------------------
Assignee: Moulali Shikalwadi
> RemoteExceptions and subclasses treated as ApplicationExceptions
> ----------------------------------------------------------------
>
> Key: WFLY-11548
> URL: https://issues.redhat.com/browse/WFLY-11548
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 13.0.0.Final
> Environment: - Windows
> - Wildfly 13 final
> - Java sdk 1.8
> Reporter: Omar Hefnawi
> Assignee: Moulali Shikalwadi
> Priority: Major
>
> Remote Exceptions should be treated as if they are System Exceptions
> So in very old projects where they used to extend RemoteException for their own exceptions, code was written under the assumption that when one of these is caught in the container, the transaction should be rolled back as per the spec (system exceptions cause a rollback).
> Currently if an ejb method throws a remote exception, this will be translated to be an Application Exception (on line 275 in EJBComponent.java) and transactions that are currently happening will no longer be rolled back; which was against the old spec, I'm unsure of what ejb 3.X says about this, but currently I felt it would make sense to mimic what happened in older application containers.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-11548) RemoteExceptions and subclasses treated as ApplicationExceptions
by Moulali Shikalwadi (Jira)
[ https://issues.redhat.com/browse/WFLY-11548?page=com.atlassian.jira.plugi... ]
Moulali Shikalwadi commented on WFLY-11548:
-------------------------------------------
Looking into it.
> RemoteExceptions and subclasses treated as ApplicationExceptions
> ----------------------------------------------------------------
>
> Key: WFLY-11548
> URL: https://issues.redhat.com/browse/WFLY-11548
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 13.0.0.Final
> Environment: - Windows
> - Wildfly 13 final
> - Java sdk 1.8
> Reporter: Omar Hefnawi
> Assignee: Moulali Shikalwadi
> Priority: Major
>
> Remote Exceptions should be treated as if they are System Exceptions
> So in very old projects where they used to extend RemoteException for their own exceptions, code was written under the assumption that when one of these is caught in the container, the transaction should be rolled back as per the spec (system exceptions cause a rollback).
> Currently if an ejb method throws a remote exception, this will be translated to be an Application Exception (on line 275 in EJBComponent.java) and transactions that are currently happening will no longer be rolled back; which was against the old spec, I'm unsure of what ejb 3.X says about this, but currently I felt it would make sense to mimic what happened in older application containers.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (DROOLS-4971) [DMN Designer] Adding entries to structure
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-4971?page=com.atlassian.jira.plug... ]
Michael Anstis reassigned DROOLS-4971:
--------------------------------------
Assignee: Guilherme Gomes (was: Michael Anstis)
> [DMN Designer] Adding entries to structure
> ------------------------------------------
>
> Key: DROOLS-4971
> URL: https://issues.redhat.com/browse/DROOLS-4971
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.32.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Gomes
> Priority: Minor
> Labels: drools-tools
> Attachments: Screenshot from 2020-01-24 09-29-26.png, Screenshot from 2020-01-24 09-30-15.png, Screenshot from 2020-01-24 09-30-40.png, offerings-reproducer.dmn
>
>
> There is unexpected ordering of entries in Data Type editor when user add structure into structure. See the attached dmn model and screenshots.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months