[JBoss JIRA] (DROOLS-2733) Support MVEL Dialect using custom inline accumulate code with external declarations in the executable model
by Luca Molteni (Jira)
[ https://issues.jboss.org/browse/DROOLS-2733?page=com.atlassian.jira.plugi... ]
Luca Molteni updated DROOLS-2733:
---------------------------------
Sprint: (was: 2019 Week 23-25)
> Support MVEL Dialect using custom inline accumulate code with external declarations in the executable model
> -----------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-2733
> URL: https://issues.jboss.org/browse/DROOLS-2733
> Project: Drools
> Issue Type: Feature Request
> Components: executable model
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Optional
>
> The executable model doesn't support custom inline accumulate code that uses external declarations such as
> {code:java}
> String str = "import " + Person.class.getCanonicalName() + ";\n" +
> "rule R dialect \"mvel\" when\n" +
> " String( $l : length )" +
> " $sum : Integer() from accumulate (\n" +
> " Person( age > 18, $age : age ), init( int sum = 0 * $l; ), action( sum += $age; ), reverse( sum -= $age; ), result( sum )\n" +
> " )" +
> "then\n" +
> " insert($sum);\n" +
> "end";
> {code}
> (Notice that in the init we multiply the sum value with the length of string)
> But it can support such style using the "classic" generation of accumulate classes which gets compiled among the executable model and instantiate during the execution of the DSL.
> This mechanism is broken with the MVEL dialect, as we don't have such generated classes.
> Probably what we should do instead is putting MVEL expressions in the DSL directly such as
> {code:java}
> accumulateScript("initCode", "accCode", "reverseCode");
> {code}
> and then during interpretation create a new MVEL context and execute the accumulate in memory
> See
> AccumulateUnsupportedTest.testMVELAccumulate
> AccumulateUnsupportedTest.testMVELAccumulate2WM
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (DROOLS-3819) Rule Units 2.0: evaluate 7.x behavior and consider new design
by Edoardo Vacchi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3819?page=com.atlassian.jira.plugi... ]
Edoardo Vacchi updated DROOLS-3819:
-----------------------------------
Description:
I have disabled generation of `unit()` API invocation on DRL compiler in order to make the Unit prototype work quickly. We are now assuming that 1 unit === 1 session, therefore some previous assumptions do not hold anymore. Previous assertions are therefore broken. It is also a good time to re-evaluate some previous considerations on how rule units are supposed to work (e.g. reconsider how guards work etc)
*Deliverable*: design document
was:
I have disabled generation of `unit()` API invocation on DRL compiler in order to make the Unit prototype work quickly. We are now assuming that 1 unit === 1 session, therefore some previous assumptions do not hold anymore. Previous assertions are therefore broken. It is also a good time to re-evaluate some previous considerations on how rule units are supposed to work (e.g. reconsider how guards work etc)
*Deliverable*: PR and (if possible) design document
> Rule Units 2.0: evaluate 7.x behavior and consider new design
> -------------------------------------------------------------
>
> Key: DROOLS-3819
> URL: https://issues.jboss.org/browse/DROOLS-3819
> Project: Drools
> Issue Type: Task
> Reporter: Edoardo Vacchi
> Assignee: Edoardo Vacchi
> Priority: Major
> Labels: drools-core, submarine
> Fix For: 8.0.0.Final
>
>
> I have disabled generation of `unit()` API invocation on DRL compiler in order to make the Unit prototype work quickly. We are now assuming that 1 unit === 1 session, therefore some previous assumptions do not hold anymore. Previous assertions are therefore broken. It is also a good time to re-evaluate some previous considerations on how rule units are supposed to work (e.g. reconsider how guards work etc)
> *Deliverable*: design document
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFCORE-4544) Missing license info
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFCORE-4544?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFCORE-4544:
--------------------------------
Fix Version/s: 9.0.2.Final
10.0.0.Beta1
> Missing license info
> --------------------
>
> Key: WFCORE-4544
> URL: https://issues.jboss.org/browse/WFCORE-4544
> Project: WildFly Core
> Issue Type: Bug
> Components: Build System
> Affects Versions: 9.0.1.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
> Fix For: 9.0.2.Final, 10.0.0.Beta1
>
>
> The docs/licenses/core-feature-pack-licenses.html file is missing most of the expected content. Seems to have only org.wildfly.core:wildfly-event-logger and various org.wildfly.security items.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-10554) OpenSAML 3.3.0 complains for missing class from "metrics-core"
by Jim Ma (Jira)
[ https://issues.jboss.org/browse/WFLY-10554?page=com.atlassian.jira.plugin... ]
Jim Ma edited comment on WFLY-10554 at 6/23/19 11:24 PM:
---------------------------------------------------------
{quote}BTW the suggested "export" change does not work as the class is required by OpenSAML module but not from the referring one.{quote}
Then the easy way to fix this could be create your own opensmal module which includes dropwizard jar file or package these jars in your application.
> OpenSAML 3.3.0 complains for missing class from "metrics-core"
> --------------------------------------------------------------
>
> Key: WFLY-10554
> URL: https://issues.jboss.org/browse/WFLY-10554
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 13.0.0.Final
> Reporter: Radoslav Ivanov
> Assignee: Jim Ma
> Priority: Critical
> Attachments: screenshot-1.png
>
>
> Module OpenSAML 3.3.0 requires depedency to module "io.dropwizard.metrics:metrics-core" but it does not present. As a result ClassNotFoundException is thrown.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months