[JBoss JIRA] (DROOLS-2305) Drools compiler does not recognize Java 9
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2305?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-2305:
--------------------------------
Sprint: 2018 Week 05-06
Environment: (was:
)
Fixed in Drools 7.6.0 by https://github.com/kiegroup/drools/commit/7fa9700566ce9d197644435d8a66521...
> Drools compiler does not recognize Java 9
> -----------------------------------------
>
> Key: DROOLS-2305
> URL: https://issues.jboss.org/browse/DROOLS-2305
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.5.0.Final
> Reporter: Jon Kranes
> Assignee: Mario Fusco
>
> The Drools compiler class org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration
> does not include Java 9 as a valid language level. Instead, when run using Java 9, the assumed java version is set to the default value of "1.7".
> As a consequence, when compiling a rules file requiring Java 8 specific language features, the compilation will fail. For example, if a rule RHS contains the statement:
> {code:java}
> Arrays.asList("a","b","c").forEach(System.out::println);
> {code}
> The rule compilation fails with the error:
> {code:java}
> [ERROR] Unable to build KieBaseModel:default
> Rule Compilation error : [Rule name='test']
> defaultpkg/Rule_test959974052.java (7:387) : Method references are allowed only at source level 1.8 or above
> {code}
> The problem can be worked around by adding a configuration file META-INF/kie.properties.conf containing the line:
> {code:java}
> drools.dialect.java.compiler.lnglevel = 1.8
> {code}
> The Drools compiler code will use this value instead of the System "java.version" value, avoiding the problem.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2305) Drools compiler does not recognize Java 9
by Jon Kranes (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2305?page=com.atlassian.jira.plugi... ]
Jon Kranes commented on DROOLS-2305:
------------------------------------
Another side effect of the same core issue is that the Drools Eclipse Plugin rules editor will throw the exception "value '9' is not a valid language level" when opening a .drl file. I was unable to find any workaround to this issue (other than configuring the project to use a lower compiler version). Looking at the source code the Eclipse plugin gets the java version directly from the project compliance level setting and does not seem to allow the use of any properties to override that value.
> Drools compiler does not recognize Java 9
> -----------------------------------------
>
> Key: DROOLS-2305
> URL: https://issues.jboss.org/browse/DROOLS-2305
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.5.0.Final
> Environment:
> Reporter: Jon Kranes
> Assignee: Mario Fusco
>
> The Drools compiler class org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration
> does not include Java 9 as a valid language level. Instead, when run using Java 9, the assumed java version is set to the default value of "1.7".
> As a consequence, when compiling a rules file requiring Java 8 specific language features, the compilation will fail. For example, if a rule RHS contains the statement:
> {code:java}
> Arrays.asList("a","b","c").forEach(System.out::println);
> {code}
> The rule compilation fails with the error:
> {code:java}
> [ERROR] Unable to build KieBaseModel:default
> Rule Compilation error : [Rule name='test']
> defaultpkg/Rule_test959974052.java (7:387) : Method references are allowed only at source level 1.8 or above
> {code}
> The problem can be worked around by adding a configuration file META-INF/kie.properties.conf containing the line:
> {code:java}
> drools.dialect.java.compiler.lnglevel = 1.8
> {code}
> The Drools compiler code will use this value instead of the System "java.version" value, avoiding the problem.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3450) CLI - avoid required attributes to be hard to see when using tab completion
by Ingo Weiss (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3450?page=com.atlassian.jira.plugi... ]
Ingo Weiss commented on WFCORE-3450:
------------------------------------
[~rsvoboda], is there a system or mechanism I can use to test this matrix?
> CLI - avoid required attributes to be hard to see when using tab completion
> ----------------------------------------------------------------------------
>
> Key: WFCORE-3450
> URL: https://issues.jboss.org/browse/WFCORE-3450
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Miroslav Novak
> Assignee: Ingo Weiss
>
> This is follow up for WFCORE-2283 which marked required attributes by "*" when using tab completion. Still if there are many attributes, it's hard to see all required attributes, for example in:
> {code}
> [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster:add(
> ! check-period connector-name* max-retry-interval notification-interval retry-interval-multiplier
> allow-direct-connections-only cluster-connection-address* discovery-group* message-load-balancing-type producer-window-size static-connectors*
> call-failover-timeout confirmation-window-size initial-connect-attempts min-large-message-size reconnect-attempts use-duplicate-detection
> call-timeout connection-ttl max-hops notification-attempts retry-interval
> {code}
> it's not clear at the first look how many required attributes there are.
> Suggestion is to group required attributes together and then provide list of other attributes, for example on the next line. Another options might be considered as well. For example to show required attributes when double pressing <tab>.
> Discussed on https://developer.jboss.org/wiki/CLI-BetterCompletionForArguments?et=watc...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2286) [DMN engine] Java Object in DMNContext not working properly with Filter function.
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2286?page=com.atlassian.jira.plugi... ]
Matteo Mortari reopened DROOLS-2286:
------------------------------------
> [DMN engine] Java Object in DMNContext not working properly with Filter function.
> ---------------------------------------------------------------------------------
>
> Key: DROOLS-2286
> URL: https://issues.jboss.org/browse/DROOLS-2286
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.4.1.Final, 7.5.0.Final
> Reporter: Thomas Mantegazzi
> Assignee: Matteo Mortari
> Attachments: FilterJohns.dmn, FilterOnObjectListBug.java
>
>
> When trying to evaluate a FEEL expression like:
> {code:java}
> personList[name = "John"]
> {code}
> by inserting into the _DMNContext_ a _Java Object_, the _DMN engine_ doesn't seem to be able to fetch the _name_ field from the object. This doesn't happen if instead of _Java Objects_ we insert a Map.
> While trying to debug, it seems that the problem is happening in the following method of _FilterExpressionNode_.
> {code:java}
> private void evaluateExpressionInContext(EvaluationContext ctx, List results, Object v) {
> try {
> ctx.enterFrame();
> // handle it as a predicate
> ctx.setValue( "item", v );
> // if it is a Map, need to add all string keys as variables in the context
> if( v instanceof Map ) {
> Set<Map.Entry> set = ((Map) v).entrySet();
> for( Map.Entry ce : set ) {
> if( ce.getKey() instanceof String ) {
> ctx.setValue( (String) ce.getKey(), ce.getValue() );
> }
> }
> }
> Object r = this.filter.evaluate( ctx );
> if( r instanceof Boolean && ((Boolean)r) == Boolean.TRUE ) {
> results.add( v );
> }
> } finally {
> ctx.exitFrame();
> }
> }
> {code}
> Also attatched java and DMN test files that showcases the issue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2286) [DMN engine] Java Object in DMNContext not working properly with Filter function.
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2286?page=com.atlassian.jira.plugi... ]
Matteo Mortari resolved DROOLS-2286.
------------------------------------
Resolution: Done
Fixed with https://github.com/kiegroup/drools/pull/1745/commits/7e8d26a596e5ef5cebe2...
> [DMN engine] Java Object in DMNContext not working properly with Filter function.
> ---------------------------------------------------------------------------------
>
> Key: DROOLS-2286
> URL: https://issues.jboss.org/browse/DROOLS-2286
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.4.1.Final, 7.5.0.Final
> Reporter: Thomas Mantegazzi
> Assignee: Matteo Mortari
> Attachments: FilterJohns.dmn, FilterOnObjectListBug.java
>
>
> When trying to evaluate a FEEL expression like:
> {code:java}
> personList[name = "John"]
> {code}
> by inserting into the _DMNContext_ a _Java Object_, the _DMN engine_ doesn't seem to be able to fetch the _name_ field from the object. This doesn't happen if instead of _Java Objects_ we insert a Map.
> While trying to debug, it seems that the problem is happening in the following method of _FilterExpressionNode_.
> {code:java}
> private void evaluateExpressionInContext(EvaluationContext ctx, List results, Object v) {
> try {
> ctx.enterFrame();
> // handle it as a predicate
> ctx.setValue( "item", v );
> // if it is a Map, need to add all string keys as variables in the context
> if( v instanceof Map ) {
> Set<Map.Entry> set = ((Map) v).entrySet();
> for( Map.Entry ce : set ) {
> if( ce.getKey() instanceof String ) {
> ctx.setValue( (String) ce.getKey(), ce.getValue() );
> }
> }
> }
> Object r = this.filter.evaluate( ctx );
> if( r instanceof Boolean && ((Boolean)r) == Boolean.TRUE ) {
> results.add( v );
> }
> } finally {
> ctx.exitFrame();
> }
> }
> {code}
> Also attatched java and DMN test files that showcases the issue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2286) [DMN engine] Java Object in DMNContext not working properly with Filter function.
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2286?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-2286:
-----------------------------------
Sprint: 2018 Week 05-06
> [DMN engine] Java Object in DMNContext not working properly with Filter function.
> ---------------------------------------------------------------------------------
>
> Key: DROOLS-2286
> URL: https://issues.jboss.org/browse/DROOLS-2286
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.4.1.Final, 7.5.0.Final
> Reporter: Thomas Mantegazzi
> Assignee: Matteo Mortari
> Attachments: FilterJohns.dmn, FilterOnObjectListBug.java
>
>
> When trying to evaluate a FEEL expression like:
> {code:java}
> personList[name = "John"]
> {code}
> by inserting into the _DMNContext_ a _Java Object_, the _DMN engine_ doesn't seem to be able to fetch the _name_ field from the object. This doesn't happen if instead of _Java Objects_ we insert a Map.
> While trying to debug, it seems that the problem is happening in the following method of _FilterExpressionNode_.
> {code:java}
> private void evaluateExpressionInContext(EvaluationContext ctx, List results, Object v) {
> try {
> ctx.enterFrame();
> // handle it as a predicate
> ctx.setValue( "item", v );
> // if it is a Map, need to add all string keys as variables in the context
> if( v instanceof Map ) {
> Set<Map.Entry> set = ((Map) v).entrySet();
> for( Map.Entry ce : set ) {
> if( ce.getKey() instanceof String ) {
> ctx.setValue( (String) ce.getKey(), ce.getValue() );
> }
> }
> }
> Object r = this.filter.evaluate( ctx );
> if( r instanceof Boolean && ((Boolean)r) == Boolean.TRUE ) {
> results.add( v );
> }
> } finally {
> ctx.exitFrame();
> }
> }
> {code}
> Also attatched java and DMN test files that showcases the issue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9768) Upgrade Weld to 3.0.3.Final and enable CDI-API bridge
by Matej Novotny (JIRA)
Matej Novotny created WFLY-9768:
-----------------------------------
Summary: Upgrade Weld to 3.0.3.Final and enable CDI-API bridge
Key: WFLY-9768
URL: https://issues.jboss.org/browse/WFLY-9768
Project: WildFly
Issue Type: Component Upgrade
Components: CDI / Weld
Reporter: Matej Novotny
Assignee: Matej Novotny
Fix For: 12.0.0.Alpha1
Weld 3.0.3.Final will be released in coming days.
This version, along with some changes on WFLY side, is needed to make the CDI multiversion real (EE 7 and 8 switching).
I'll send the WFLY changes along with component upgrade.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2308) Investigate FieldActionInspector hasValue implementation
by Jozef Marko (JIRA)
Jozef Marko created DROOLS-2308:
-----------------------------------
Summary: Investigate FieldActionInspector hasValue implementation
Key: DROOLS-2308
URL: https://issues.jboss.org/browse/DROOLS-2308
Project: Drools
Issue Type: Task
Components: Guided Decision Table Editor
Affects Versions: 6.5.0.Final
Reporter: Jozef Marko
Assignee: Toni Rikkola
The current implementation of {{[FieldActionInspector#hasValue|https://github.com/kiegroup/drools-wb/blob/6.5.x/drools-wb-screens/drools-wb-guided-dtable-editor/drools-wb-guided-dtable-editor-client/src/main/java/org/drools/workbench/screens/guided/dtable/client/widget/analysis/action/FieldActionInspector.java]}} is like:
{code:java}
switch (value.getDataType()) {
case NUMERIC:
case NUMERIC_BIGDECIMAL:
case NUMERIC_BIGINTEGER:
case NUMERIC_BYTE:
case NUMERIC_DOUBLE:
case NUMERIC_FLOAT:
case NUMERIC_INTEGER:
case NUMERIC_LONG:
case NUMERIC_SHORT:
return value.getNumericValue() != null;
case BOOLEAN:
return value.getBooleanValue() != null;
default:
return value.getStringValue() != null && !value.getStringValue().isEmpty();
}
{code}
Please investigate, if the switch above shouldn't handle also Date data type.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2304) [DMN Designer] Add context entry from literal expression cell
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2304?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2304:
--------------------------------
QE Status: VERIFIED (was: ON_QA)
> [DMN Designer] Add context entry from literal expression cell
> -------------------------------------------------------------
>
> Key: DROOLS-2304
> URL: https://issues.jboss.org/browse/DROOLS-2304
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.6.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
>
> If the context entry is specified as literal expression, then user can not add context entry while this literal expression cell is selected. It can be seen in the last row of context entry table, where last entry is pair *default : literal expression cell*.
> If user clicks on *default*, the table offers show button *add entry* over the table, however if user clicks to *literal expression cell* next to *default* this button is not shown.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3580) /host=xxx:add is required now after embedding the host controller
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3580?page=com.atlassian.jira.plugi... ]
Ken Wills commented on WFCORE-3580:
-----------------------------------
It is worth noting that omitting the empty-host etc parameters and providing a non-empty host.xml should boot the host and call /add using the default host name. Since these parameters are new, and not present in any released version, I'm not quite sure this is a change in behavour.
> /host=xxx:add is required now after embedding the host controller
> -----------------------------------------------------------------
>
> Key: WFCORE-3580
> URL: https://issues.jboss.org/browse/WFCORE-3580
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Affects Versions: 4.0.0.Alpha9
> Reporter: Alexey Loubyansky
> Assignee: Jason Greene
>
> This is just to report a change in behavior. This is not a critical issue for what I personally am doing.
> The issue is that I used to have a script that would generate a domain.xml configuration (let's say for the core distribution) that would start like this
> {code:java}
> embed-host-controller --empty-host-config --remove-existing-host-config --empty-domain-config --remove-existing-domain-config --host-config=pm-tmp-host.xml --domain-config=domain.xml
> /interface=public:add(inet-address=${jboss.bind.address:127.0.0.1})
> /interface=management:add(inet-address=${jboss.bind.address.management:127.0.0.1})
> ...
> {code}
> A script like this will fail now because we need to explicitly add a host before executing any management operation. E.g.
> {code:java}
> embed-host-controller --empty-host-config --remove-existing-host-config --empty-domain-config --remove-existing-domain-config --host-config=pm-tmp-host.xml --domain-config=domain.xml
> /host=tmp:add
> /interface=public:add(inet-address=${jboss.bind.address:127.0.0.1})
> /interface=management:add(inet-address=${jboss.bind.address.management:127.0.0.1})
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months