[JBoss JIRA] (DROOLS-1551) Implement FEEL/DMN value marshaller
by Edson Tirelli (JIRA)
Edson Tirelli created DROOLS-1551:
-------------------------------------
Summary: Implement FEEL/DMN value marshaller
Key: DROOLS-1551
URL: https://issues.jboss.org/browse/DROOLS-1551
Project: Drools
Issue Type: Feature Request
Components: dmn engine
Affects Versions: 7.0.0.CR3
Reporter: Edson Tirelli
Assignee: Edson Tirelli
Fix For: 7.1.0.Final
Some value types in FEEL/DMN require special formatting when marshalling/unmarshalling. For instance:
{quote}
So it seems that ISO 8601 does not define negative intervals. I.e., ISO 8601 only supports things like "PT1H". XPath extends that with a leading optional sign, like "+PT1H" and "-PT1H". Java extends that allowing the sign to be used in each of the units in the duration like, "PT+1H", "PT-1H", besides the leading sign "-PT1H".
The FEEL spec on page 113 seems to follow the XPath lexical definition, so the leading sign "-PT1H" seems to be the correct format.
{quote}
Implement an object marshaller for DMN/FEEL that is capable of marshalling/unmarshalling objects. Most object types are straightforward, but a few of them (like durations) need special handling. In particular:
* negative duration should use a leading - sign instead of having the sign in the unit numbers
* durations need to be normalized before marshalled:
{quote}
A days and time duration in the semantic domain is a sequence of numbers for the days, hours, minutes, and seconds of duration, normalized such that the sum of these numbers is minimized.
{quote}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (DROOLS-1549) Extend date and time functions
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1549?page=com.atlassian.jira.plugi... ]
Edson Tirelli updated DROOLS-1549:
----------------------------------
Issue Type: Enhancement (was: Bug)
> Extend date and time functions
> ------------------------------
>
> Key: DROOLS-1549
> URL: https://issues.jboss.org/browse/DROOLS-1549
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Affects Versions: 7.0.0.CR3
> Reporter: Edson Tirelli
> Assignee: Edson Tirelli
> Fix For: 7.1.0.Final
>
>
> Extend date and time functions to support the following cases:
> * {{date( <dateTimeString> )}} should return a date ignoring the time component of the string
> * {{time( <dateTimeString> )}} should return a time ignoring the date component of the string
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (DROOLS-1547) Add tests to confirm that singleton lists can be treated as the element itself in filter results
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1547?page=com.atlassian.jira.plugi... ]
Edson Tirelli updated DROOLS-1547:
----------------------------------
Issue Type: Task (was: Bug)
> Add tests to confirm that singleton lists can be treated as the element itself in filter results
> ------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1547
> URL: https://issues.jboss.org/browse/DROOLS-1547
> Project: Drools
> Issue Type: Task
> Components: dmn engine
> Affects Versions: 7.0.0.CR3
> Reporter: Edson Tirelli
> Assignee: Edson Tirelli
> Fix For: 7.1.0.Final
>
>
> The specification has a provision that singleton lists should be treated as the element itself in some cases, like filter results. I.e., in some cases, {{[a] = a}}.
> This is not completely consistent, but we need to handle it for some cases, like filter results. In other words, the following assignment should work fine, assuming {{a flight}} is a flight variable and {{flight list}} is a list of flights, and the filter returns a single result.
> {code}
> {
> a flight : flight list[ number = "AC 531" ]
> }
> {code}
> We need to add tests to make sure it is working like that and fix it in case it is not.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (WFCORE-13) End users can call non-published management API operations
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.... ]
Brian Stansberry edited comment on WFCORE-13 at 5/6/17 12:47 PM:
-----------------------------------------------------------------
We now prevent end user access to EntryType.PRIVATE operations. Note the behavior of the 'describe' op is unchanged, as the existence of that op may have been communicated to users and I don't see an urgent need to possibly break compatibility by making it inaccessible. OTOH I don't see any need to make it accessible over JMX either. We can either make it fully public or completely private at some later point, or just leave it as is. I didn't want that particular op to be a primary focus here; I was more concerned with disabling access to private ops that would be more problematic if invoked by users.
was (Author: brian.stansberry):
We now prevent end user access to EntryType.PRIVATE operations. Note the behavior of the 'describe' op is unchanged, as that existence of that op may have been communicated to users and I don't see an urgent need to possibly break compatibility by making it inaccessible. OTOH I don't see any need to make it accessible over JMX either. We can either make it fully public or completely private at some later point, or just leave it as is. I didn't want that particular op to be a primary focus here; I was more concerned with disabling access to private ops that would be more problematic if invoked by users.
> End users can call non-published management API operations
> ----------------------------------------------------------
>
> Key: WFCORE-13
> URL: https://issues.jboss.org/browse/WFCORE-13
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Ladislav Thon
> Assignee: Brian Stansberry
> Labels: EAP
> Fix For: 3.0.0.Beta19
>
>
> It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces.
> The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen.
> What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized.
> I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (WFLY-8714) AZURE_PING does not integrate with Elytron's CredentialStore
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-8714:
------------------------------------
Summary: AZURE_PING does not integrate with Elytron's CredentialStore
Key: WFLY-8714
URL: https://issues.jboss.org/browse/WFLY-8714
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 11.0.0.Alpha1
Reporter: Radoslav Husar
Assignee: Radoslav Husar
Currently, the passphrases are stored in the server profile, however they need to be consumed from Elytron credential store.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (WFLY-8715) AZURE_PING does not integrate with Elytron's CredentialStore
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-8715:
------------------------------------
Summary: AZURE_PING does not integrate with Elytron's CredentialStore
Key: WFLY-8715
URL: https://issues.jboss.org/browse/WFLY-8715
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 11.0.0.Alpha1
Reporter: Radoslav Husar
Assignee: Radoslav Husar
Currently, the passphrases are stored in the server profile, however they need to be consumed from Elytron credential store.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months