[JBoss JIRA] (WFCORE-721) Create a ModelNode to CLI call transformation facility
by Harald Pehl (JIRA)
[ https://issues.jboss.org/browse/WFCORE-721?page=com.atlassian.jira.plugin... ]
Harald Pehl commented on WFCORE-721:
------------------------------------
This is the very basic / limited ModelNode to CLI transformation we use in HAL:
https://github.com/hal/hal.next/blob/develop/dmr/src/main/java/org/jboss/...
> Create a ModelNode to CLI call transformation facility
> ------------------------------------------------------
>
> Key: WFCORE-721
> URL: https://issues.jboss.org/browse/WFCORE-721
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Jason Greene
> Assignee: Ken Wills
>
> Add a transformation function that can convert a ModelNode representation of an operation into a CLI low level operation. In the case of a composite operation, this should result in a CLI batch command with multiple CLI low level operations.
> This capability involves introducing a transformation API (ModelNodeTransformer?), and perhaps an SPI to support pluggable transformation algorithms.
> Future transformations might be:
> - Java code - Transformation of a ModelNode based management operation into Java code using the jboss-dmr API to build a ModelNode and use the ModelController client API
> - Python code - Transformation of a ModelNode based management operation into Python code that builds a JSON representation of the model node and some demo code calling an HTTP API in python to make the invocation
> - Curl code - Transformation of a ModelNode based management operation into a curl statement(s) that can be cut and paste into a console
> - XHR JS code - Transformation of a ModelNode based management operation into JS XHR calls
> This functionality belongs in a new library, and once completed should be directly ported to HAL(console) as a prototype (this would enable HAL to record and display operations, CLI calls, or even code of the work performance based on user selection)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (WFCORE-721) Create a ModelNode to CLI call transformation facility
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-721?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-721:
-----------------------------------------
Possibly the ModelNode to CLI transformation could deal with a few well known commands as well. For example
{code}
{ "operation" => "reload"}
{code}
becomes the CLI "reload" command instead of the "/:reload" low level operation.
Same thing with shutdown.
I'm not suggesting any broadly scoped DMR to high-level-command facility. This is really about the few operations that result in breaking the CLI's connection to the server. The high level CLI commands deal with that properly.
> Create a ModelNode to CLI call transformation facility
> ------------------------------------------------------
>
> Key: WFCORE-721
> URL: https://issues.jboss.org/browse/WFCORE-721
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Jason Greene
> Assignee: Ken Wills
>
> Add a transformation function that can convert a ModelNode representation of an operation into a CLI low level operation. In the case of a composite operation, this should result in a CLI batch command with multiple CLI low level operations.
> This capability involves introducing a transformation API (ModelNodeTransformer?), and perhaps an SPI to support pluggable transformation algorithms.
> Future transformations might be:
> - Java code - Transformation of a ModelNode based management operation into Java code using the jboss-dmr API to build a ModelNode and use the ModelController client API
> - Python code - Transformation of a ModelNode based management operation into Python code that builds a JSON representation of the model node and some demo code calling an HTTP API in python to make the invocation
> - Curl code - Transformation of a ModelNode based management operation into a curl statement(s) that can be cut and paste into a console
> - XHR JS code - Transformation of a ModelNode based management operation into JS XHR calls
> This functionality belongs in a new library, and once completed should be directly ported to HAL(console) as a prototype (this would enable HAL to record and display operations, CLI calls, or even code of the work performance based on user selection)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (WFCORE-721) Create a ModelNode to CLI call transformation facility
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-721?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-721:
------------------------------------
Description:
Add a transformation function that can convert a ModelNode representation of an operation into a CLI low level operation. In the case of a composite operation, this should result in a CLI batch command with multiple CLI low level operations.
This capability involves introducing a transformation API (ModelNodeTransformer?), and perhaps an SPI to support pluggable transformation algorithms.
Future transformations might be:
- Java code - Transformation of a ModelNode based management operation into Java code using the jboss-dmr API to build a ModelNode and use the ModelController client API
- Python code - Transformation of a ModelNode based management operation into Python code that builds a JSON representation of the model node and some demo code calling an HTTP API in python to make the invocation
- Curl code - Transformation of a ModelNode based management operation into a curl statement(s) that can be cut and paste into a console
- XHR JS code - Transformation of a ModelNode based management operation into JS XHR calls
This functionality belongs in a new library, and once completed should be directly ported to HAL(console) as a prototype (this would enable HAL to record and display operations, CLI calls, or even code of the work performance based on user selection)
was:
Add a transformation function that can convert a ModelNode representation of an operation into a CLI command. In the case of a composite operation, this should result in a CLI batch with multiple CLI commands.
This capability involves introducing a transformation API (ModelNodeTransformer?), and perhaps an SPI to support pluggable transformation algorithms.
Future transformations might be:
- Java code - Transformation of a ModelNode based management operation into Java code using the jboss-dmr API to build a ModelNode and use the ModelController client API
- Python code - Transformation of a ModelNode based management operation into Python code that builds a JSON representation of the model node and some demo code calling an HTTP API in python to make the invocation
- Curl code - Transformation of a ModelNode based management operation into a curl statement(s) that can be cut and paste into a console
- XHR JS code - Transformation of a ModelNode based management operation into JS XHR calls
This functionality belongs in a new library, and once completed should be directly ported to HAL(console) as a prototype (this would enable HAL to record and display operations, CLI calls, or even code of the work performance based on user selection)
> Create a ModelNode to CLI call transformation facility
> ------------------------------------------------------
>
> Key: WFCORE-721
> URL: https://issues.jboss.org/browse/WFCORE-721
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Jason Greene
> Assignee: Ken Wills
>
> Add a transformation function that can convert a ModelNode representation of an operation into a CLI low level operation. In the case of a composite operation, this should result in a CLI batch command with multiple CLI low level operations.
> This capability involves introducing a transformation API (ModelNodeTransformer?), and perhaps an SPI to support pluggable transformation algorithms.
> Future transformations might be:
> - Java code - Transformation of a ModelNode based management operation into Java code using the jboss-dmr API to build a ModelNode and use the ModelController client API
> - Python code - Transformation of a ModelNode based management operation into Python code that builds a JSON representation of the model node and some demo code calling an HTTP API in python to make the invocation
> - Curl code - Transformation of a ModelNode based management operation into a curl statement(s) that can be cut and paste into a console
> - XHR JS code - Transformation of a ModelNode based management operation into JS XHR calls
> This functionality belongs in a new library, and once completed should be directly ported to HAL(console) as a prototype (this would enable HAL to record and display operations, CLI calls, or even code of the work performance based on user selection)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (DROOLS-1592) Deleted facts retained in memory, but removed after (de)serialization
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1592?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-1592:
--------------------------------
Component/s: core engine
> Deleted facts retained in memory, but removed after (de)serialization
> ---------------------------------------------------------------------
>
> Key: DROOLS-1592
> URL: https://issues.jboss.org/browse/DROOLS-1592
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Nikolay Plekhanov
> Assignee: Mario Fusco
> Attachments: drools-memleak.zip
>
>
> Given:
> two agenda groups: A1 and A2.
> Rule R1 in agenda group A1 and rule R2 in agenda group A2.
> R1 matches facts of type T1, deletes them and creates facts of type T2.
> R2 matches facts of type T2 and does soemthing with them (it doesn't matter, because issue happens even if R2 never fired).
> Scenario:
> * Create session, add R1 and R2 rules
> * add some facts of T1 type
> * set focus on A1 agenda group
> * invoke "fireAllRules" method
> * Invoke "getObjects" and assure that session contains only T2 facts
> * analyze objects in memory (by jmap + memory analyzing tool or just traversing references by reflection) and assure that T1 facts are still reachable via session object.
> * serialize session using marshaller and deserialize in again
> * analyze deserialized session and see that it doesn't contain T1 fact references anymore.
> Thoughts:
> I assumed that T1 references storing is feature, because they can be necessary in some cases (like reverse of their deletion due to logical inversion of truth - not sure, but maybe), but T1 deletion after (de)serialization points out the opposite.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (WFLY-8867) Legacy protocol property resource operations do not work for legacy protocols
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-8867?page=com.atlassian.jira.plugin.... ]
Paul Ferraro moved JBEAP-11254 to WFLY-8867:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8867 (was: JBEAP-11254)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
(was: Clustering)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR18)
(was: 7.1.0.DR19)
> Legacy protocol property resource operations do not work for legacy protocols
> -----------------------------------------------------------------------------
>
> Key: WFLY-8867
> URL: https://issues.jboss.org/browse/WFLY-8867
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Blocker
>
> QE Cc [~mnovak], [~okalman], [~mstyk], [~pkremens]
> Cc [~kabirkhan], [~jason.greene]
> See steps to reproduce. The question is, to what degree should CLI commands be backward compatible with 7.0? XML configurations pasted from 7.0 are OK in this case.
> I previously thought these changes were OK (once documented in migration guide), but after discussion with the rest of the QE team, the most common opinion is that CLI commands should be 100% backward compatible with 7.0, which is not the case here.
> [~bilge] since this is not stated anywhere I know, can you confirm that CLI commands in 7.1 need to be backward compatible with 7.0?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (WFLY-8866) Legacy add-protocol/remove-protocol operations do not work for legacy protocols
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-8866?page=com.atlassian.jira.plugin.... ]
Paul Ferraro moved JBEAP-11255 to WFLY-8866:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8866 (was: JBEAP-11255)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
(was: Clustering)
> Legacy add-protocol/remove-protocol operations do not work for legacy protocols
> -------------------------------------------------------------------------------
>
> Key: WFLY-8866
> URL: https://issues.jboss.org/browse/WFLY-8866
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Blocker
>
> As discussed in JBEAP-11190, this concerns the following use case:
> {noformat:title=#4 Adding TCPPING via add-protocol operation - NOK}
> /subsystem="jgroups"/stack="tcpping":add-protocol(type="TCPPING")
> # throws with DR19
> {noformat}
> which no longer works in DR19 because it requires socket bindings to be defined.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (DROOLS-1592) Deleted facts retained in memory, but removed after (de)serialization
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1592?page=com.atlassian.jira.plugi... ]
Edson Tirelli reassigned DROOLS-1592:
-------------------------------------
Assignee: Mario Fusco (was: Edson Tirelli)
> Deleted facts retained in memory, but removed after (de)serialization
> ---------------------------------------------------------------------
>
> Key: DROOLS-1592
> URL: https://issues.jboss.org/browse/DROOLS-1592
> Project: Drools
> Issue Type: Bug
> Reporter: Nikolay Plekhanov
> Assignee: Mario Fusco
> Attachments: drools-memleak.zip
>
>
> Given:
> two agenda groups: A1 and A2.
> Rule R1 in agenda group A1 and rule R2 in agenda group A2.
> R1 matches facts of type T1, deletes them and creates facts of type T2.
> R2 matches facts of type T2 and does soemthing with them (it doesn't matter, because issue happens even if R2 never fired).
> Scenario:
> * Create session, add R1 and R2 rules
> * add some facts of T1 type
> * set focus on A1 agenda group
> * invoke "fireAllRules" method
> * Invoke "getObjects" and assure that session contains only T2 facts
> * analyze objects in memory (by jmap + memory analyzing tool or just traversing references by reflection) and assure that T1 facts are still reachable via session object.
> * serialize session using marshaller and deserialize in again
> * analyze deserialized session and see that it doesn't contain T1 fact references anymore.
> Thoughts:
> I assumed that T1 references storing is feature, because they can be necessary in some cases (like reverse of their deletion due to logical inversion of truth - not sure, but maybe), but T1 deletion after (de)serialization points out the opposite.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months