[JBoss JIRA] (DROOLS-4160) Make DRL codegen enabled by default
by Edoardo Vacchi (Jira)
Edoardo Vacchi created DROOLS-4160:
--------------------------------------
Summary: Make DRL codegen enabled by default
Key: DROOLS-4160
URL: https://issues.jboss.org/browse/DROOLS-4160
Project: Drools
Issue Type: Task
Reporter: Edoardo Vacchi
Assignee: Edoardo Vacchi
Fix For: 8.0.0.Final
set YES as the default value for generateModel -- make sure it works as expected and creates no conflicts (I recall conflicts with BPMN in KieBuilderImpl)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-4042) [DMN Designer] Add support for importing and consuming PMML models 7.5
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4042?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-4042:
--------------------------------
Affects Version/s: 7.24.0.Final
> [DMN Designer] Add support for importing and consuming PMML models 7.5
> ----------------------------------------------------------------------
>
> Key: DROOLS-4042
> URL: https://issues.jboss.org/browse/DROOLS-4042
> Project: Drools
> Issue Type: Epic
> Components: DMN Editor
> Affects Versions: 7.24.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Critical
> Labels: drools-tools
>
> We need the ability to import PMML _documents_. This should be via the "Imported models" tab. Once a _document_ has been imported (and an alias assigned) selection of the _document_ and a _model_ held therein should be possible via the PMML Function boxed expression editor.
> h2. Requirement
> - As user, via included models tab, remove included pmml model, even if used somewhere
> - As user, via included models tab, rename included pmml model, even if used somewhere
> - As user, via included models tab, include multiple pmml models
> - As user, via included models tab, include multiple pmml models at the same time eternal dmn
> - As user, via included models tab, include multiple pmml models at the same time external dmn, kinds are visually distinguished
> - As user, via dmn designer, if Document or Model of included pmml was changed, the lisboxes in dmn offers new values
> - As user, via included models tab, no restriction for included pmml model name
> - As user, via new test scenarios, test dmn model that uses pmml inside
> - As user, via kie-server, query kie container that has dmn model with pmml
> h2. UX design
> - Selectbox in place of Document and Model selection
> h2. Documentation
> - Mention what pmml model can be imported into dmn
> - Mention where it can be used
> - Mention if something more needed to dpeloy such project on kie server
> h2. Acceptance test
> - Include two pmml models
> - In dmn, select one in function grid
> - Change the selected one to second
> - Finish the dmn model
> - build deploy on kie-server
> - Interact with kie container via rest
> - Create new test scenario for created dmn model
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-4042) [DMN Designer] Add support for importing and consuming PMML models 7.5
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4042?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-4042:
--------------------------------
Affects Version/s: (was: 7.21.0.Final)
> [DMN Designer] Add support for importing and consuming PMML models 7.5
> ----------------------------------------------------------------------
>
> Key: DROOLS-4042
> URL: https://issues.jboss.org/browse/DROOLS-4042
> Project: Drools
> Issue Type: Epic
> Components: DMN Editor
> Affects Versions: 7.24.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Critical
> Labels: drools-tools
>
> We need the ability to import PMML _documents_. This should be via the "Imported models" tab. Once a _document_ has been imported (and an alias assigned) selection of the _document_ and a _model_ held therein should be possible via the PMML Function boxed expression editor.
> h2. Requirement
> - As user, via included models tab, remove included pmml model, even if used somewhere
> - As user, via included models tab, rename included pmml model, even if used somewhere
> - As user, via included models tab, include multiple pmml models
> - As user, via included models tab, include multiple pmml models at the same time eternal dmn
> - As user, via included models tab, include multiple pmml models at the same time external dmn, kinds are visually distinguished
> - As user, via dmn designer, if Document or Model of included pmml was changed, the lisboxes in dmn offers new values
> - As user, via included models tab, no restriction for included pmml model name
> - As user, via new test scenarios, test dmn model that uses pmml inside
> - As user, via kie-server, query kie container that has dmn model with pmml
> h2. UX design
> - Selectbox in place of Document and Model selection
> h2. Documentation
> - Mention what pmml model can be imported into dmn
> - Mention where it can be used
> - Mention if something more needed to dpeloy such project on kie server
> h2. Acceptance test
> - Include two pmml models
> - In dmn, select one in function grid
> - Change the selected one to second
> - Finish the dmn model
> - build deploy on kie-server
> - Interact with kie container via rest
> - Create new test scenario for created dmn model
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-12095) Use HTTPS and only HTTPS for management interfaces in default configuration
by Jan Stourac (Jira)
[ https://issues.jboss.org/browse/WFLY-12095?page=com.atlassian.jira.plugin... ]
Jan Stourac updated WFLY-12095:
-------------------------------
Description:
Current default configuration of WildFly uses plaintext HTTP for management interfaces that are used for web-console access. Even though, that it is possible to switch to HTTPS after login to web-console, I believe we should incorporate HTTPS and only HTTPS configuration of management interfaces in our default WildFly configuration as it brings in more secure approach.
Note that there is digest-auth used for web-console login, thus password is not sent in a plain-text over the network, although there is still possibility of MITM attack, as such one can see what management operations are performed (actual request payload is binary, although I presume that it is easy to decode when one knows how to do it).
Yes, I understand that by default, there will be just a self-signed certificate generated for server on first HTTPS request, but I believe it is still an improvement.
Such change will affect both Web-Console and also CLI so both will operate over HTTPS. In case of self-signed certificate - if not already added in trusted certs, one has to accept certificate during the first login/access via Web-Console or CLI.
was:
Current default configuration of WildFly uses plaintext HTTP for management interfaces that are used for web-console access. Even though, that it is possible to switch to HTTPS after login to web-console, I believe we should incorporate HTTPS and only HTTPS configuration of management interfaces in our default WildFly configuration.
Note that there is digest-auth used for web-console login, thus password is not sent in a plain-text over the network, although there is still possibility of MITM attack, as such one can see what management operations are performed (actual request payload is binary, although I presume that it is easy to decode when one knows how to do it).
Yes, I understand that by default, there will be just a self-signed certificate generated for server on first HTTPS request, but I believe it is still an improvement.
> Use HTTPS and only HTTPS for management interfaces in default configuration
> ---------------------------------------------------------------------------
>
> Key: WFLY-12095
> URL: https://issues.jboss.org/browse/WFLY-12095
> Project: WildFly
> Issue Type: Enhancement
> Components: Management, Security
> Affects Versions: 16.0.0.Final
> Reporter: Jan Stourac
> Priority: Major
>
> Current default configuration of WildFly uses plaintext HTTP for management interfaces that are used for web-console access. Even though, that it is possible to switch to HTTPS after login to web-console, I believe we should incorporate HTTPS and only HTTPS configuration of management interfaces in our default WildFly configuration as it brings in more secure approach.
> Note that there is digest-auth used for web-console login, thus password is not sent in a plain-text over the network, although there is still possibility of MITM attack, as such one can see what management operations are performed (actual request payload is binary, although I presume that it is easy to decode when one knows how to do it).
> Yes, I understand that by default, there will be just a self-signed certificate generated for server on first HTTPS request, but I believe it is still an improvement.
> Such change will affect both Web-Console and also CLI so both will operate over HTTPS. In case of self-signed certificate - if not already added in trusted certs, one has to accept certificate during the first login/access via Web-Console or CLI.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-10872) Confusing error message when writing simple-load-provider attribute when dynamic load provider is present
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-10872?page=com.atlassian.jira.plugin... ]
Radoslav Husar updated WFLY-10872:
----------------------------------
Affects Version/s: 17.0.0.Final
> Confusing error message when writing simple-load-provider attribute when dynamic load provider is present
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10872
> URL: https://issues.jboss.org/browse/WFLY-10872
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 14.0.0.Beta2, 17.0.0.Final
> Reporter: Jan Kasik
> Assignee: Radoslav Husar
> Priority: Major
> Fix For: 18.0.0.Beta1
>
>
> Following should add simple load provider with factor=0:
> {code}
> /subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=simple-load-provider, value=0)
> {code}
> Instead, this error shows up:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"subsystem\" => \"modcluster\"),
> (\"proxy\" => \"default\"),
> (\"load-provider\" => \"simple\")
> ]' not found",
> "rolled-back" => true
> }
> {code}
> There is missing translation to create the resource, same is the situation for undefine operation.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-10872) Confusing error message when writing simple-load-provider attribute when dynamic load provider is present
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-10872?page=com.atlassian.jira.plugin... ]
Radoslav Husar updated WFLY-10872:
----------------------------------
Fix Version/s: 18.0.0.Beta1
> Confusing error message when writing simple-load-provider attribute when dynamic load provider is present
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10872
> URL: https://issues.jboss.org/browse/WFLY-10872
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 14.0.0.Beta2, 17.0.0.Final
> Reporter: Jan Kasik
> Assignee: Radoslav Husar
> Priority: Major
> Fix For: 18.0.0.Beta1
>
>
> Following should add simple load provider with factor=0:
> {code}
> /subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=simple-load-provider, value=0)
> {code}
> Instead, this error shows up:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"subsystem\" => \"modcluster\"),
> (\"proxy\" => \"default\"),
> (\"load-provider\" => \"simple\")
> ]' not found",
> "rolled-back" => true
> }
> {code}
> There is missing translation to create the resource, same is the situation for undefine operation.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-4042) [DMN Designer] Add support for importing and consuming PMML models 7.5
by Stetson Robinson (Jira)
[ https://issues.jboss.org/browse/DROOLS-4042?page=com.atlassian.jira.plugi... ]
Stetson Robinson commented on DROOLS-4042:
------------------------------------------
[~jomarko], yes, those are the basic questions/components I would focus on for documentation. One thing: This epic still has the affected version of 7.21.0.Final. I assume we want to update that at some point.
> [DMN Designer] Add support for importing and consuming PMML models 7.5
> ----------------------------------------------------------------------
>
> Key: DROOLS-4042
> URL: https://issues.jboss.org/browse/DROOLS-4042
> Project: Drools
> Issue Type: Epic
> Components: DMN Editor
> Affects Versions: 7.21.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Critical
> Labels: drools-tools
>
> We need the ability to import PMML _documents_. This should be via the "Imported models" tab. Once a _document_ has been imported (and an alias assigned) selection of the _document_ and a _model_ held therein should be possible via the PMML Function boxed expression editor.
> h2. Requirement
> - As user, via included models tab, remove included pmml model, even if used somewhere
> - As user, via included models tab, rename included pmml model, even if used somewhere
> - As user, via included models tab, include multiple pmml models
> - As user, via included models tab, include multiple pmml models at the same time eternal dmn
> - As user, via included models tab, include multiple pmml models at the same time external dmn, kinds are visually distinguished
> - As user, via dmn designer, if Document or Model of included pmml was changed, the lisboxes in dmn offers new values
> - As user, via included models tab, no restriction for included pmml model name
> - As user, via new test scenarios, test dmn model that uses pmml inside
> - As user, via kie-server, query kie container that has dmn model with pmml
> h2. UX design
> - Selectbox in place of Document and Model selection
> h2. Documentation
> - Mention what pmml model can be imported into dmn
> - Mention where it can be used
> - Mention if something more needed to dpeloy such project on kie server
> h2. Acceptance test
> - Include two pmml models
> - In dmn, select one in function grid
> - Change the selected one to second
> - Finish the dmn model
> - build deploy on kie-server
> - Interact with kie container via rest
> - Create new test scenario for created dmn model
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-4155) [DMN Designer] Placeholder doesn't fit a column
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-4155?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-4155:
-----------------------------------
Story Points: 3
Sprint: 2019 Week 23-25
> [DMN Designer] Placeholder doesn't fit a column
> -----------------------------------------------
>
> Key: DROOLS-4155
> URL: https://issues.jboss.org/browse/DROOLS-4155
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.24.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
> Labels: drools-tools
> Attachments: placeholder.png
>
>
> If user included a *PMML* model into a DMN diagram, then he has possibility to define PMML function invocation. Grid for such invocation contains placeholders saying that document and model needs to be specified. The issue is placeholders doesn't column width and thus are not readable. See the attached picture.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFCORE-4514) ProxyMetadataSource breaks contract of ClassMetadataSource#getDeclaredMethods (resulting in "illegal reflective access operation" in Java 11)
by Jaikiran Pai (Jira)
[ https://issues.jboss.org/browse/WFCORE-4514?page=com.atlassian.jira.plugi... ]
Jaikiran Pai commented on WFCORE-4514:
--------------------------------------
By the way, this warning message can be easily reproduced by deploying a EJB application (even the ones from wildfly quickstarts, like the ejb-in-war) on a WildFly instance that's running with Java 11.
> ProxyMetadataSource breaks contract of ClassMetadataSource#getDeclaredMethods (resulting in "illegal reflective access operation" in Java 11)
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4514
> URL: https://issues.jboss.org/browse/WFCORE-4514
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Affects Versions: 9.0.1.Final
> Environment: Java 11
> Reporter: Jaikiran Pai
> Assignee: Jeff Mesnil
> Priority: Major
>
> While investigating this issue reported in the forum thread[1], where the user states that using Java 11 shows up a warning about illegal reflective access:
> {code}
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.jboss.invocation.proxy.AbstractProxyFactory$1 (jar:file:/C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/invocation/main/jboss-invocation-1.5.2.Final.jar!/) to method java.lang.Object.clone()
> WARNING: Please consider reporting this to the maintainers of org.jboss.invocation.proxy.AbstractProxyFactory$1
> WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {code}
> I realized that, that issue is in fact triggered by, what I believe, is a bug and a violation of an (internal) API contract in WildFly.
> What seems to be happening is - when the proxy class is being defined for (EJB) component, in the jboss-invocation library here[2], the implementation there overrides the component classes' methods. It does that for the entire class hierarchy of the component class and stops at the Object.class (rightly so) through the use of this check[3] (currentClass != Object.class). In this implementation, within the loop, it then calls:
> {code}
> ClassMetadataSource data = reflectionMetadataSource.getClassMetadata(currentClass);
> {code}
> which is an API exposed by the org.jboss.invocation.proxy.reflection.ReflectionMetadataSource interface. The returned ClassMetadataSource is then used within that loop as follows:
> {code}
> for (Method method : data.getDeclaredMethods()) {
> ....
> {code}
> The getDeclaredMethods() API, exposed by ClassMetadataSource[5] is expected to (only) return the methods that are declared by that class. Turns out, the implementation in WildFly[6], for this interface, doesn't honour that contract and instead returns all methods (including the ones that are in the super class) on that class:
> {code}
> public Collection<Method> getDeclaredMethods() {
> return index.getClassMethods();
> }
> {code}
> The index.getClassMethods() is a call to the ClassReflectionIndex#getClassMethods() whose implementation[7] walks through the entire class hierarchy and returns all the methods on that class.
> This (unexpected) implemetation of ProxyMetadataSource#getDeclaredMethods()[6] causes the check in [3] to end up being irrelevant and as a result the code in [2] ends up trying to take control over methods on the Object class (by calling method.setAccessible(true)[8]) and one such method is the "clone" method. This ultimately results in that illegal reflective access warning.
> Looking at the history of ProxyMetadataSource#getDeclaredMethods() in WildFly, it looks like the implementation was changed to accomodate/fix this issue https://issues.jboss.org/browse/WFCORE-579 in this commit https://github.com/wildfly/wildfly-core/commit/4382f0c28dab2d0494926b8a34.... The previous implementation was returning the correct methods (only the declared ones). Looking at that JIRA and linked bugzilla to it, I think the original issue might need a different fix. I haven't yet had a chance to look more into that issue.
> Of course, one way to solve the current issue at hand (the illegal reflective access one) would be to add a check in
> jboss-invocation's AbstractProxyFactory similar to this https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/..., but IMO, that would be more of a hack than an actual fix since the API contract violation in ProxyMetadataSource will still be an issue and can (and probably does) cause some unexpected problems.
> [1] https://developer.jboss.org/message/989623#989623
> [2] https://github.com/jbossas/jboss-invocation/blob/master/src/main/java/org...
> [3] https://github.com/jbossas/jboss-invocation/blob/master/src/main/java/org...
> [4] https://github.com/jbossas/jboss-invocation/blob/master/src/main/java/org...
> [5] https://github.com/jbossas/jboss-invocation/blob/master/src/main/java/org...
> [6] https://github.com/wildfly/wildfly-core/blob/5391b40b79f72d2a57d4e32234af...
> [7] https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/...
> [8] https://github.com/jbossas/jboss-invocation/blob/master/src/main/java/org...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month