[JBoss JIRA] (DROOLS-5434) Incorrect warning about file declaring wrong package
by Magnus Larsson (Jira)
[ https://issues.redhat.com/browse/DROOLS-5434?page=com.atlassian.jira.plug... ]
Magnus Larsson updated DROOLS-5434:
-----------------------------------
Description:
I am running Drools in a Spring-Boot jar and get the following warning statement _File 'BOOT-INF/classes/com/example/test/TEST.drl' is in folder 'BOOT-INF/classes/com/example/test' but declares package 'com.example.test'. It is advised to have a correspondance between package and folder names_. The package name in the drl file is correct, the problem is just that _BOOT-INF.classes._ isn't considered when evaluating if printing the warning or not.
I have tracked it down to *KieBuilderImpl.java*, method *isFileInKieBase*. The last 2 lines in that method calls:
{code:java}
// packageNameForFile prints warning if package in .drl file is not same as flatted directory structure
// Does not care about SUPPORTED_RESOURCES_ROOTS, thus prints the warning
String pkgNameForFile = packageNameForFile( fileName, folderNameForFile, !useFolders, file );
// Does care about SUPPORTED_RESOURCES_ROOTS, so the drl file is loaded
return isPackageInKieBase( kieBase, pkgNameForFile );
{code}
As it is implemented right now, the warning might either be a false-positive (and still get loaded), or the package is wrong (and the file is not loaded).
Voting to include the SUPPORTED_RESOURCES_ROOTS as valid prefixes when checking if the warning should be printed.
was:
I am running Drools in a Spring-Boot jar and get the following warning statement _File 'BOOT-INF/classes/com/example/test/TEST.drl' is in folder 'BOOT-INF/classes/com/example/test' but declares package 'com.example.test'. It is advised to have a correspondance between package and folder names_. The package name in the drl file is correct, the problem is just that _BOOT-INF.classes._ isn't considered when evaluating if printing the warning or not.
I have tracked it down to *KieBuilderImpl.java*, method *isFileInKieBase*. The last 2 lines in that method calls:
{code:java}
// Does not care about SUPPORTED_RESOURCES_ROOTS, thus prints the warning
String pkgNameForFile = packageNameForFile( fileName, folderNameForFile, !useFolders, file );
// Does care about SUPPORTED_RESOURCES_ROOTS, so the drl file is loaded
return isPackageInKieBase( kieBase, pkgNameForFile );
{code}
As it is implemented right now, the warning might either be a false-positive (and still get loaded), or the package is wrong (and the file is not loaded).
Voting to include the SUPPORTED_RESOURCES_ROOTS as valid prefixes when checking if the warning should be printed.
> Incorrect warning about file declaring wrong package
> ----------------------------------------------------
>
> Key: DROOLS-5434
> URL: https://issues.redhat.com/browse/DROOLS-5434
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Magnus Larsson
> Assignee: Mario Fusco
> Priority: Major
>
> I am running Drools in a Spring-Boot jar and get the following warning statement _File 'BOOT-INF/classes/com/example/test/TEST.drl' is in folder 'BOOT-INF/classes/com/example/test' but declares package 'com.example.test'. It is advised to have a correspondance between package and folder names_. The package name in the drl file is correct, the problem is just that _BOOT-INF.classes._ isn't considered when evaluating if printing the warning or not.
> I have tracked it down to *KieBuilderImpl.java*, method *isFileInKieBase*. The last 2 lines in that method calls:
> {code:java}
> // packageNameForFile prints warning if package in .drl file is not same as flatted directory structure
> // Does not care about SUPPORTED_RESOURCES_ROOTS, thus prints the warning
> String pkgNameForFile = packageNameForFile( fileName, folderNameForFile, !useFolders, file );
> // Does care about SUPPORTED_RESOURCES_ROOTS, so the drl file is loaded
> return isPackageInKieBase( kieBase, pkgNameForFile );
> {code}
> As it is implemented right now, the warning might either be a false-positive (and still get loaded), or the package is wrong (and the file is not loaded).
> Voting to include the SUPPORTED_RESOURCES_ROOTS as valid prefixes when checking if the warning should be printed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFLY-6938) Startup error messages caused by expression where expressions are not allowed are confusing
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-6938?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-6938:
----------------------------------------
This looks like two separate issues.
The host.xml one would belong in WFCORE. Probably good to check it's still an issue first though.
The main one, generally if an expression is not supported it's because the attribute is a model reference, and for such an attribute the wiring should be converted to use capabilities, which will result in a capability violation message. I think has been done for EE concurrency.
I'm reluctant to start blanket rejecting text that looks like an expression because we think it's wrong, as perhaps it's valid text for some case. Perhaps the capability resolution handling could handle that a bit better though and provide a slightly different failure message if it finds expression text in the unresolvable capability name. That too would be something that should be tracked in WFCORE.
> Startup error messages caused by expression where expressions are not allowed are confusing
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-6938
> URL: https://issues.redhat.com/browse/WFLY-6938
> Project: WildFly
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 10.1.0.CR1
> Reporter: Ondrej Chaloupka
> Assignee: Lukas Vydra
> Priority: Minor
>
> When a property expression is used at place where expression usage is not allowed then error message which is shown is quite confusing. From user point of view (especially the newcomer) it would be nice if the error message shows the real reason - usage of expression at place where is not permitted.
> Maybe CLI could warn on usage of expression on place where is not allowed too.
> Documentation recommends configuration with CLI, editing of XML file is common too. More of it there are some tasks which are harder to be done with CLI and editing XML is faster/easier.
> Examples:
> Setting
> {code}
> /subsystem=ee/managed-executor-service=default:write-attribute(name=context-service, value="${my.context.service}")
> {code}
> ends with this error message during startup
> {code}
> 14:13:21,076 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "ee"),
> ("managed-executor-service" => "default")
> ]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.concurrent.ee.context.service.${my.context.service}"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.concurrent.ee.executor.default is missing [jboss.concurrent.ee.context.service.${my.context.service}]"]}
> {code}
> another confusion is setting name of host in {{host-slave.xml}} file. When set as
> {code}
> <host xmlns="urn:jboss:domain:4.2" host="${host.name}">
> {code}
> then NullPointerException is thrown.
> {code}
> [Host Controller] 14:18:45,238 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0033: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
> at org.jboss.as.host.controller.HostControllerConfigurationPersister.load(HostControllerConfigurationPersister.java:188)
> at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:594)
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299)
> at java.lang.Thread.run(Thread.java:745)[Host Controller] Caused by: javax.xml.stream.XMLStreamException: ParseError
> at [row,col]:[3,1][Host Controller] Message: WFLYCTL0197: Unexpected attribute 'host' encountered
> at org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:117)
> at org.jboss.as.host.controller.parsing.HostXml_4.readHostElement(HostXml_4.java:311)
> at org.jboss.as.host.controller.parsing.HostXml_4.readElement(HostXml_4.java:170)
> at org.jboss.as.host.controller.parsing.HostXml.readElement(HostXml.java:79)
> at org.jboss.as.host.controller.parsing.HostXml.readElement(HostXml.java:50)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) ... 4 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFLY-6938) Startup error messages caused by expression where expressions are not allowed are confusing
by Lukas Vydra (Jira)
[ https://issues.redhat.com/browse/WFLY-6938?page=com.atlassian.jira.plugin... ]
Lukas Vydra reassigned WFLY-6938:
---------------------------------
Assignee: Lukas Vydra
> Startup error messages caused by expression where expressions are not allowed are confusing
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-6938
> URL: https://issues.redhat.com/browse/WFLY-6938
> Project: WildFly
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 10.1.0.CR1
> Reporter: Ondrej Chaloupka
> Assignee: Lukas Vydra
> Priority: Minor
>
> When a property expression is used at place where expression usage is not allowed then error message which is shown is quite confusing. From user point of view (especially the newcomer) it would be nice if the error message shows the real reason - usage of expression at place where is not permitted.
> Maybe CLI could warn on usage of expression on place where is not allowed too.
> Documentation recommends configuration with CLI, editing of XML file is common too. More of it there are some tasks which are harder to be done with CLI and editing XML is faster/easier.
> Examples:
> Setting
> {code}
> /subsystem=ee/managed-executor-service=default:write-attribute(name=context-service, value="${my.context.service}")
> {code}
> ends with this error message during startup
> {code}
> 14:13:21,076 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "ee"),
> ("managed-executor-service" => "default")
> ]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.concurrent.ee.context.service.${my.context.service}"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.concurrent.ee.executor.default is missing [jboss.concurrent.ee.context.service.${my.context.service}]"]}
> {code}
> another confusion is setting name of host in {{host-slave.xml}} file. When set as
> {code}
> <host xmlns="urn:jboss:domain:4.2" host="${host.name}">
> {code}
> then NullPointerException is thrown.
> {code}
> [Host Controller] 14:18:45,238 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0033: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
> at org.jboss.as.host.controller.HostControllerConfigurationPersister.load(HostControllerConfigurationPersister.java:188)
> at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:594)
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299)
> at java.lang.Thread.run(Thread.java:745)[Host Controller] Caused by: javax.xml.stream.XMLStreamException: ParseError
> at [row,col]:[3,1][Host Controller] Message: WFLYCTL0197: Unexpected attribute 'host' encountered
> at org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:117)
> at org.jboss.as.host.controller.parsing.HostXml_4.readHostElement(HostXml_4.java:311)
> at org.jboss.as.host.controller.parsing.HostXml_4.readElement(HostXml_4.java:170)
> at org.jboss.as.host.controller.parsing.HostXml.readElement(HostXml.java:79)
> at org.jboss.as.host.controller.parsing.HostXml.readElement(HostXml.java:50)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) ... 4 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (DROOLS-5291) Import of empty scesim file leads to Unexpected error
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-5291?page=com.atlassian.jira.plug... ]
Yeser Amer updated DROOLS-5291:
-------------------------------
Labels: drools-tools (was: drools-tools kogito-tooling)
> Import of empty scesim file leads to Unexpected error
> -----------------------------------------------------
>
> Key: DROOLS-5291
> URL: https://issues.redhat.com/browse/DROOLS-5291
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.36.0.Final
> Reporter: Anna Dupliak
> Assignee: Yeser Amer
> Priority: Minor
> Labels: drools-tools
> Fix For: 7.40.0.Final
>
> Attachments: Traffic.zip, errorlog.txt, image-2020-04-17-16-47-29-261.png, image-2020-04-17-16-47-32-047.png
>
>
> If user generate a scesim file using vs code extention it is not comparable with BC.
> Use Vscode generated files [^Traffic.zip]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (DROOLS-5147) [DMN Designer] DMN Decision Table - Input/Output clauses enhancements (UX)
by Elizabeth Clayton (Jira)
[ https://issues.redhat.com/browse/DROOLS-5147?page=com.atlassian.jira.plug... ]
Elizabeth Clayton updated DROOLS-5147:
--------------------------------------
Labels: UXTeam drools-tools kogito-tooling (was: UXTeam drools-tools)
> [DMN Designer] DMN Decision Table - Input/Output clauses enhancements (UX)
> --------------------------------------------------------------------------
>
> Key: DROOLS-5147
> URL: https://issues.redhat.com/browse/DROOLS-5147
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Reporter: Guilherme Gomes
> Assignee: Elizabeth Clayton
> Priority: Minor
> Labels: UXTeam, drools-tools, kogito-tooling
> Attachments: prototype.png
>
>
> Currently, the DMN Decision Tables input/output clauses work fine, but they have the following unpractical scenarios:
> - When users have a structure input node "associated" with an input clause (input column), they frequently need to go back to the data types page and remember the name of some field.
> - When users select a structure data type as the type of an output clause, they need to create sub-columns for each field manually.
> The goal for this JIRA is to get input from UX to enhance interactions with input and output clauses.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (DROOLS-5291) Import of empty scesim file leads to Unexpected error
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-5291?page=com.atlassian.jira.plug... ]
Yeser Amer updated DROOLS-5291:
-------------------------------
Sprint: (was: 2020 Week 25-27 (from Jun 15))
> Import of empty scesim file leads to Unexpected error
> -----------------------------------------------------
>
> Key: DROOLS-5291
> URL: https://issues.redhat.com/browse/DROOLS-5291
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.36.0.Final
> Reporter: Anna Dupliak
> Assignee: Yeser Amer
> Priority: Minor
> Labels: drools-tools, kogito-tooling
> Fix For: 7.40.0.Final
>
> Attachments: Traffic.zip, errorlog.txt, image-2020-04-17-16-47-29-261.png, image-2020-04-17-16-47-32-047.png
>
>
> If user generate a scesim file using vs code extention it is not comparable with BC.
> Use Vscode generated files [^Traffic.zip]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFCORE-5009) Request for enhancement in the JBoss EAP CLI generic type "command"
by Jean Francois Denise (Jira)
[ https://issues.redhat.com/browse/WFCORE-5009?page=com.atlassian.jira.plug... ]
Jean Francois Denise moved EAP7-1508 to WFCORE-5009:
----------------------------------------------------
Project: WildFly Core (was: JBoss EAP Planning for version 7 and above)
Key: WFCORE-5009 (was: EAP7-1508)
Issue Type: Feature Request (was: Requirement)
Workflow: GIT Pull Request workflow (was: EAP Agile Workflow 2.0)
Component/s: CLI
(was: CLI)
EAP PT Pre-Checked (PC): (was: TODO)
Target Release: (was: 7.4.0.GA)
EAP PT Community Docs (CD): (was: TODO)
EAP PT Product Docs (PD): (was: New)
Affects Version/s: (was: 7.3.0.GA)
EAP PT Test Dev (TD): (was: TODO)
EAP PT Docs Analysis (DA): (was: TODO)
EAP PT Test Plan (TP): (was: TODO)
EAP PT Analysis Document (AD): (was: TODO)
> Request for enhancement in the JBoss EAP CLI generic type "command"
> -------------------------------------------------------------------
>
> Key: WFCORE-5009
> URL: https://issues.redhat.com/browse/WFCORE-5009
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean Francois Denise
> Assignee: Jean Francois Denise
> Priority: Major
> Labels: Previous_RFE
>
> One of our strategic customers, requested an enhancement in the JBoss EAP CLI. Currently they are using in their scripts the Generic type Command (https://developer.jboss.org/wiki/GenericTypeCLICommands) to set the properties of a resource.
> Unfortunately that does not work in several cases. For example when they need to set attributes like the following:
> /core-service=management/access=authorization:write-attribute(name=permission-combination-policy,value=permissive)
> /core-service=management/access=authorization:write-attribute(name=provider,value=rbac)
> This can not be done with the command syntax:
> [standalone@127.0.0.1:9999 /] command add --node-type=/core-service=management/access --command-name=access
> Failed to validate input: operation response doesn't contain result info.
> It would be extremely helpful for us to have an improvement in the CLI that allows setting multiple attributes on resources referenced by 'command'.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months