[Red Hat JIRA] (WFLY-14437) Add tests to the Mail subsystem for attributes that allow expressions
by Yeray Borges Santana (Jira)
Yeray Borges Santana created WFLY-14437:
-------------------------------------------
Summary: Add tests to the Mail subsystem for attributes that allow expressions
Key: WFLY-14437
URL: https://issues.redhat.com/browse/WFLY-14437
Project: WildFly
Issue Type: Task
Components: Mail
Reporter: Yeray Borges Santana
Assignee: Yeray Borges Santana
The mail subsystem practically allows any attribute to use expressions, however, not all attributes are being tested at the moment.
Specifically, the use of an expression on the following attributes are not being tested automatically:
* mail-session/jndi-name
* mail-session/from
* mail-session/debug
* server-definition/outbound-socket-binding-ref
* server-definition/tls
* server-definition/ssl
* server-definition/properties
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (DROOLS-5973) Java enum values don't match DNM enumerations when input passed as POJO
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5973?page=com.atlassian.jira.plug... ]
Matteo Mortari edited comment on DROOLS-5973 at 2/15/21 11:31 AM:
------------------------------------------------------------------
Hi Andrew, thank you for raising this report but I believe there is actually no bug.
I believe the engine is behaving as expected, and there is only a confusion about enumeration over the Drools DMN Engine API interface.
I will close this JIRA based on this, and as detailed below. Feel free to reopen this JIRA if the below details are not answering your enquiry.
In DMN there is no Enumeration as a type per-se.
Possibly when reported, there has been some confusion about some wording in the Editor.
In DMN one can only define some constraints on an existing type in the domain.
For instance one might want to constrain {{FEEL:string}} to some specific values:
!screenshot-1.png|thumbnail!
or equivalently:
!screenshot-2.png|thumbnail!
but the ItemDefinition would still be a {{FEEL:string}}, just constrained to some specific values.
Similarly in Java, a {{java.lang.Enum}} is NOT a {{java.lang.String}}.
Or for another DMN example, one might want to constrain {{FEEL:number}} to some specific values:
!screenshot-3.png|thumbnail!
or equivalently:
!screenshot-4.png|thumbnail!
but once again, the ItemDefinition would still be a {{FEEL:number}}, just constrained to some specific values.
so when using the Drools DMN Engine API, one would need to set the DMNContext for the equivalent Java types accordingly to the spec, for instance:
{code:java}
final DMNContext context = dmnRuntime.newContext();
context.set( "InputData-periodicity", "Weekly" );
context.set( "InputData-numericBase", 8 );
{code}
Of course we try to have some convenience, so the value {{8}} is eventually internally converted as BigDecimal as required by the spec, but there is no doubt that for the InputData, the Number is still supplied as requird.
Nothing prevents to define the ItemDefinition values in a related java.lang.Enum, but then it is up to the end-user providing the necessary conversions, for instance by using .toString() or .name() calls, for example:
{code:java}
public enum Periodicity {
DAILY("Daily"),
WEEKLY("Weekly"),
MONTHLY("Monthly");
private String v;
private Periodicity(String val) {
this.v = val;
}
public String asString() {
return v;
}
}
...
final DMNContext context = dmnRuntime.newContext();
context.set("InputData-periodicity", Periodicity.WEEKLY.asString());
{code}
I am happy to take a further look if I missed anything, but just based on the currently provided data I conclude there is no bug.
Hope this helps, please let us know!
was (Author: tari_manga):
Hi Andrew, thank you for raising this report but I believe there is actually no bug.
I believe the engine is behaving as expected, and there is only a confusion about enumeration over the Drools DMN Engine API interface.
I will close this JIRA based on this, and as detailed below. Feel free to reopen this JIRA if the below details are not answering your enquiry.
In DMN there is no Enumeration as a type per-se.
Possibly when reported, there has been some confusion about some wording in the Editor.
In DMN one can only define some constraints on an existing type in the domain.
For instance one might want to constrain {{FEEL:string}} to some specific values:
!screenshot-1.png|thumbnail!
or equivalently:
!screenshot-2.png|thumbnail!
but the ItemDefinition would still be a {{FEEL:string}}, just constrained to some specific values.
Similarly in Java, a {{java.lang.Enum}} is NOT a {{java.lang.String}}.
Or for another DMN example, one might want to constrain {{FEEL:number}} to some specific values:
!screenshot-3.png|thumbnail!
or equivalently:
!screenshot-4.png|thumbnail!
but once again, the ItemDefinition would still be a {{FEEL:number}}, just constrained to some specific values.
so when using the Drools DMN Engine API, one would need to set the DMNContext for the equivalent Java types accordingly to the spec, for instance:
{code:java}
final DMNContext context = DMNFactory.newContext();
context.set( "InputData-periodicity", "Weekly" );
context.set( "InputData-numericBase", 8 );
{code}
Of course we try to have some convenience, so the value {{8}} is eventually internally converted as BigDecimal as required by the spec, but there is no doubt that for the InputData, the Number is still supplied as requird.
Nothing prevents to define the ItemDefinition values in a related java.lang.Enum, but then it is up to the end-user providing the necessary conversions, for instance by using .toString() or .name() calls, for example:
{code:java}
public enum Periodicity {
DAILY("Daily"),
WEEKLY("Weekly"),
MONTHLY("Monthly");
private String v;
private Periodicity(String val) {
this.v = val;
}
public String asString() {
return v;
}
}
...
final DMNContext context = DMNFactory.newContext();
context.set("InputData-periodicity", Periodicity.WEEKLY.asString());
{code}
I am happy to take a further look if I missed anything, but just based on the currently provided data I conclude there is no bug.
Hope this helps, please let us know!
> Java enum values don't match DNM enumerations when input passed as POJO
> -----------------------------------------------------------------------
>
> Key: DROOLS-5973
> URL: https://issues.redhat.com/browse/DROOLS-5973
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.48.0.Final
> Reporter: Andrew K
> Assignee: Matteo Mortari
> Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, screenshot-4.png
>
>
> When passing an input object into the DMN engine as a POJO, enumerations represented in the POJO as Java enums do not correctly match DMN string enumerations.
> This can be worked around by converting the input to a Map using Jackson:
> {code:java}
> new ObjectMapper().convertValue(pojo, Map.class){code}
> but this should not be necessary.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (DROOLS-5973) Java enum values don't match DNM enumerations when input passed as POJO
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5973?page=com.atlassian.jira.plug... ]
Matteo Mortari resolved DROOLS-5973.
------------------------------------
Tester: Daniel Rosa
Resolution: Not a Bug
> Java enum values don't match DNM enumerations when input passed as POJO
> -----------------------------------------------------------------------
>
> Key: DROOLS-5973
> URL: https://issues.redhat.com/browse/DROOLS-5973
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.48.0.Final
> Reporter: Andrew K
> Assignee: Matteo Mortari
> Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, screenshot-4.png
>
>
> When passing an input object into the DMN engine as a POJO, enumerations represented in the POJO as Java enums do not correctly match DMN string enumerations.
> This can be worked around by converting the input to a Map using Jackson:
> {code:java}
> new ObjectMapper().convertValue(pojo, Map.class){code}
> but this should not be necessary.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFCORE-333) Provide a management operation to list the servers in a server group (domain mode)
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFCORE-333?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz closed WFCORE-333.
--------------------------------------
Resolution: Out of Date
> Provide a management operation to list the servers in a server group (domain mode)
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-333
> URL: https://issues.redhat.com/browse/WFCORE-333
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Management
> Reporter: Richard Achmatowicz
> Priority: Minor
> Labels: domain-mode
>
> In domain mode, an end user might want to start one or more servers by hand in a named server group. Obtaining the list of servers in a server group is not readily available: the "group" attribute is embedded in server-config, so we have to drill down into every /host=*/server-config=* combination to find out which servers belong to a specific server group.
> It would improve the user experience to have an operation which shows which servers are in a given server group.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (DROOLS-5973) Java enum values don't match DNM enumerations when input passed as POJO
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5973?page=com.atlassian.jira.plug... ]
Matteo Mortari edited comment on DROOLS-5973 at 2/15/21 11:06 AM:
------------------------------------------------------------------
Hi Andrew, thank you for raising this report but I believe there is actually no bug.
I believe the engine is behaving as expected, and there is only a confusion about enumeration over the Drools DMN Engine API interface.
I will close this JIRA based on this, and as detailed below. Feel free to reopen this JIRA if the below details are not answering your enquiry.
In DMN there is no Enumeration as a type per-se.
Possibly when reported, there has been some confusion about some wording in the Editor.
In DMN one can only define some constraints on an existing type in the domain.
For instance one might want to constrain {{FEEL:string}} to some specific values:
!screenshot-1.png|thumbnail!
or equivalently:
!screenshot-2.png|thumbnail!
but the ItemDefinition would still be a {{FEEL:string}}, just constrained to some specific values.
Similarly in Java, a {{java.lang.Enum}} is NOT a {{java.lang.String}}.
Or for another DMN example, one might want to constrain {{FEEL:number}} to some specific values:
!screenshot-3.png|thumbnail!
or equivalently:
!screenshot-4.png|thumbnail!
but once again, the ItemDefinition would still be a {{FEEL:number}}, just constrained to some specific values.
so when using the Drools DMN Engine API, one would need to set the DMNContext for the equivalent Java types accordingly to the spec, for instance:
{code:java}
final DMNContext context = DMNFactory.newContext();
context.set( "InputData-periodicity", "Weekly" );
context.set( "InputData-numericBase", 8 );
{code}
Of course we try to have some convenience, so the value {{8}} is eventually internally converted as BigDecimal as required by the spec, but there is no doubt that for the InputData, the Number is still supplied as requird.
Nothing prevents to define the ItemDefinition values in a related java.lang.Enum, but then it is up to the end-user providing the necessary conversions, for instance by using .toString() or .name() calls, for example:
{code:java}
public enum Periodicity {
DAILY("Daily"),
WEEKLY("Weekly"),
MONTHLY("Monthly");
private String v;
private Periodicity(String val) {
this.v = val;
}
public String asString() {
return v;
}
}
...
final DMNContext context = DMNFactory.newContext();
context.set("InputData-periodicity", Periodicity.WEEKLY.asString());
{code}
I am happy to take a further look if I missed anything, but just based on the currently provided data I conclude there is no bug.
Hope this helps, please let us know!
was (Author: tari_manga):
Hi Andrew, thank you for raising this report but I believe there is actually no bug.
I believe the engine is behaving as expected, and there is only a confusion about enumeration over the Drools DMN Engine API interface.
I will close this JIRA based on this, and as detailed below. Feel free to reopen this JIRA if the below details are not answering your enquiry.
In DMN there is no Enumeration as a type per-se.
Possibly when reported, there has been some confusion about some wording in the Editor.
In DMN one can only define some constraints on an existing type in the domain.
For instance one might want to constrain {{FEEL:string}} to some specific values:
!screenshot-1.png|thumbnail!
or equivalently:
!screenshot-2.png|thumbnail!
but the ItemDefinition would still be a {{FEEL:string}}, just constrained to some specific values.
Similarly in Java, a {{java.lang.Enum}} is NOT a {{java.lang.String}}.
Or for another DMN example, one might want to constrain {{FEEL:number}} to some specific values:
!screenshot-3.png|thumbnail!
or equivalently:
!screenshot-4.png|thumbnail!
but once again, the ItemDefinition would still be a {{FEEL:number}}, just constrained to some specific values.
so when using the Drools DMN Engine API, one would need to set the DMNContext for the equivalent Java types accordingly to the spec, for instance:
{code:java}
final DMNContext context = DMNFactory.newContext();
context.set( "InputData-periodicity", "Weekly" );
context.set( "InputData-numericBase", 8 );
{code}
Of course we try to have some convenience, so the value {8} is eventually internally converted as BigDecimal as required by the spec, but there is no doubt that for the InputData, the Number is still supplied as requird.
Nothing prevents to define the ItemDefinition values in a related java.lang.Enum, but then it is up to the end-user providing the necessary conversions, for instance by using .toString() or .name() calls, for example:
{code:java}
public enum Periodicity {
DAILY("Daily"),
WEEKLY("Weekly"),
MONTHLY("Monthly");
private String v;
private Periodicity(String val) {
this.v = val;
}
public String asString() {
return v;
}
}
...
final DMNContext context = DMNFactory.newContext();
context.set("InputData-periodicity", Periodicity.WEEKLY.asString());
{code}
I am happy to take a further look if I missed anything, but just based on the currently provided data I conclude there is no bug.
Hope this helps, please let us know!
> Java enum values don't match DNM enumerations when input passed as POJO
> -----------------------------------------------------------------------
>
> Key: DROOLS-5973
> URL: https://issues.redhat.com/browse/DROOLS-5973
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.48.0.Final
> Reporter: Andrew K
> Assignee: Matteo Mortari
> Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, screenshot-4.png
>
>
> When passing an input object into the DMN engine as a POJO, enumerations represented in the POJO as Java enums do not correctly match DMN string enumerations.
> This can be worked around by converting the input to a Map using Jackson:
> {code:java}
> new ObjectMapper().convertValue(pojo, Map.class){code}
> but this should not be necessary.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (DROOLS-5973) Java enum values don't match DNM enumerations when input passed as POJO
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5973?page=com.atlassian.jira.plug... ]
Matteo Mortari edited comment on DROOLS-5973 at 2/15/21 11:06 AM:
------------------------------------------------------------------
Hi Andrew, thank you for raising this report but I believe there is actually no bug.
I believe the engine is behaving as expected, and there is only a confusion about enumeration over the Drools DMN Engine API interface.
I will close this JIRA based on this, and as detailed below. Feel free to reopen this JIRA if the below details are not answering your enquiry.
In DMN there is no Enumeration as a type per-se.
Possibly when reported, there has been some confusion about some wording in the Editor.
In DMN one can only define some constraints on an existing type in the domain.
For instance one might want to constrain {{FEEL:string}} to some specific values:
!screenshot-1.png|thumbnail!
or equivalently:
!screenshot-2.png|thumbnail!
but the ItemDefinition would still be a {{FEEL:string}}, just constrained to some specific values.
Similarly in Java, a {{java.lang.Enum}} is NOT a {{java.lang.String}}.
Or for another DMN example, one might want to constrain {{FEEL:number}} to some specific values:
!screenshot-3.png|thumbnail!
or equivalently:
!screenshot-4.png|thumbnail!
but once again, the ItemDefinition would still be a {{FEEL:number}}, just constrained to some specific values.
so when using the Drools DMN Engine API, one would need to set the DMNContext for the equivalent Java types accordingly to the spec, for instance:
{code:java}
final DMNContext context = DMNFactory.newContext();
context.set( "InputData-periodicity", "Weekly" );
context.set( "InputData-numericBase", 8 );
{code}
Of course we try to have some convenience, so the value {8} is eventually internally converted as BigDecimal as required by the spec, but there is no doubt that for the InputData, the Number is still supplied as requird.
Nothing prevents to define the ItemDefinition values in a related java.lang.Enum, but then it is up to the end-user providing the necessary conversions, for instance by using .toString() or .name() calls, for example:
{code:java}
public enum Periodicity {
DAILY("Daily"),
WEEKLY("Weekly"),
MONTHLY("Monthly");
private String v;
private Periodicity(String val) {
this.v = val;
}
public String asString() {
return v;
}
}
...
final DMNContext context = DMNFactory.newContext();
context.set("InputData-periodicity", Periodicity.WEEKLY.asString());
{code}
I am happy to take a further look if I missed anything, but just based on the currently provided data I conclude there is no bug.
Hope this helps, please let us know!
was (Author: tari_manga):
Hi Andrew, thank you for raising this report but I believe there is actually no bug.
I believe the engine is behaving as expected, and there is only a confusion about enumeration over the Drools DMN Engine API interface.
I will close this JIRA based on this, and as detailed below. Feel free to reopen this JIRA if the below details are not answering your enquiry.
In DMN there is no Enumeration as a type per-se.
Possibly when reported, there has been some confusion about some wording in the Editor.
In DMN one can only define some constraints on an existing type in the domain.
For instance one might want to constrain {FEEL:string} to some specific values:
!screenshot-1.png|thumbnail!
or equivalently:
!screenshot-2.png|thumbnail!
but the ItemDefinition would still be a {FEEL:string}, just constrained to some specific values.
Similarly in Java, a {java.lang.Enum} is NOT a {java.lang.String}.
Or for another DMN example, one might want to constrain {FEEL:number} to some specific values:
!screenshot-3.png|thumbnail!
or equivalently:
!screenshot-4.png|thumbnail!
but once again, the ItemDefinition would still be a {FEEL:number}, just constrained to some specific values.
so when using the Drools DMN Engine API, one would need to set the DMNContext for the equivalent Java types accordingly to the spec, for instance:
{code:java}
final DMNContext context = DMNFactory.newContext();
context.set( "InputData-periodicity", "Weekly" );
context.set( "InputData-numericBase", 8 );
{code}
Of course we try to have some convenience, so the value {8} is eventually internally converted as BigDecimal as required by the spec, but there is no doubt that for the InputData, the Number is still supplied as requird.
Nothing prevents to define the ItemDefinition values in a related java.lang.Enum, but then it is up to the end-user providing the necessary conversions, for instance by using .toString() or .name() calls, for example:
{code:java}
public enum Periodicity {
DAILY("Daily"),
WEEKLY("Weekly"),
MONTHLY("Monthly");
private String v;
private Periodicity(String val) {
this.v = val;
}
public String asString() {
return v;
}
}
...
final DMNContext context = DMNFactory.newContext();
context.set("InputData-periodicity", Periodicity.WEEKLY.asString());
{code}
I am happy to take a further look if I missed anything, but just based on the currently provided data I conclude there is no bug.
Hope this helps, please let us know!
> Java enum values don't match DNM enumerations when input passed as POJO
> -----------------------------------------------------------------------
>
> Key: DROOLS-5973
> URL: https://issues.redhat.com/browse/DROOLS-5973
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.48.0.Final
> Reporter: Andrew K
> Assignee: Matteo Mortari
> Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, screenshot-4.png
>
>
> When passing an input object into the DMN engine as a POJO, enumerations represented in the POJO as Java enums do not correctly match DMN string enumerations.
> This can be worked around by converting the input to a Map using Jackson:
> {code:java}
> new ObjectMapper().convertValue(pojo, Map.class){code}
> but this should not be necessary.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (DROOLS-5973) Java enum values don't match DNM enumerations when input passed as POJO
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5973?page=com.atlassian.jira.plug... ]
Matteo Mortari commented on DROOLS-5973:
----------------------------------------
Hi Andrew, thank you for raising this report but I believe there is actually no bug.
I believe the engine is behaving as expected, and there is only a confusion about enumeration over the Drools DMN Engine API interface.
I will close this JIRA based on this, and as detailed below. Feel free to reopen this JIRA if the below details are not answering your enquiry.
In DMN there is no Enumeration as a type per-se.
Possibly when reported, there has been some confusion about some wording in the Editor.
In DMN one can only define some constraints on an existing type in the domain.
For instance one might want to constrain {FEEL:string} to some specific values:
!screenshot-1.png|thumbnail!
or equivalently:
!screenshot-2.png|thumbnail!
but the ItemDefinition would still be a {FEEL:string}, just constrained to some specific values.
Similarly in Java, a {java.lang.Enum} is NOT a {java.lang.String}.
Or for another DMN example, one might want to constrain {FEEL:number} to some specific values:
!screenshot-3.png|thumbnail!
or equivalently:
!screenshot-4.png|thumbnail!
but once again, the ItemDefinition would still be a {FEEL:number}, just constrained to some specific values.
so when using the Drools DMN Engine API, one would need to set the DMNContext for the equivalent Java types accordingly to the spec, for instance:
{code:java}
final DMNContext context = DMNFactory.newContext();
context.set( "InputData-periodicity", "Weekly" );
context.set( "InputData-numericBase", 8 );
{code}
Of course we try to have some convenience, so the value {8} is eventually internally converted as BigDecimal as required by the spec, but there is no doubt that for the InputData, the Number is still supplied as requird.
Nothing prevents to define the ItemDefinition values in a related java.lang.Enum, but then it is up to the end-user providing the necessary conversions, for instance by using .toString() or .name() calls, for example:
{code:java}
public enum Periodicity {
DAILY("Daily"),
WEEKLY("Weekly"),
MONTHLY("Monthly");
private String v;
private Periodicity(String val) {
this.v = val;
}
public String asString() {
return v;
}
}
...
final DMNContext context = DMNFactory.newContext();
context.set("InputData-periodicity", Periodicity.WEEKLY.asString());
{code}
I am happy to take a further look if I missed anything, but just based on the currently provided data I conclude there is no bug.
Hope this helps, please let us know!
> Java enum values don't match DNM enumerations when input passed as POJO
> -----------------------------------------------------------------------
>
> Key: DROOLS-5973
> URL: https://issues.redhat.com/browse/DROOLS-5973
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.48.0.Final
> Reporter: Andrew K
> Assignee: Matteo Mortari
> Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, screenshot-4.png
>
>
> When passing an input object into the DMN engine as a POJO, enumerations represented in the POJO as Java enums do not correctly match DMN string enumerations.
> This can be worked around by converting the input to a Map using Jackson:
> {code:java}
> new ObjectMapper().convertValue(pojo, Map.class){code}
> but this should not be necessary.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months