[JBoss JIRA] (LOGMGR-177) Introduce delayed initialization strategy
by James Perkins (Jira)
[ https://issues.redhat.com/browse/LOGMGR-177?page=com.atlassian.jira.plugi... ]
James Perkins updated LOGMGR-177:
---------------------------------
Fix Version/s: 2.2.0.Final
> Introduce delayed initialization strategy
> -----------------------------------------
>
> Key: LOGMGR-177
> URL: https://issues.redhat.com/browse/LOGMGR-177
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Components: core
> Reporter: David Lloyd
> Assignee: James Perkins
> Priority: Critical
> Fix For: 2.2.0.Final, 3.0.0.Final
>
>
> h2. Synopsis
> The logmanager eagerly initializes as soon as logging is first used. In many cases this is undesirable because of circular dependency problems which do not allow the logging configuration to be fully available until other systems are booted for a variety of reasons:
> * WildFly logging configuration is done in a subsystem which is not available at first boot
> * Logging handlers may depend on other systems (which use logging) to initialize (like Elytron for SSL)
> * Java 9+ may make it difficult to initialize logging very early
> So we need a multi-stage initialization process.
> h2. Requirements
> h3. Requirement 1: Performance must not be impacted
> One of the primary reasons for the existence of the log manager is performance. Therefore, performance impact must be as minimal as possible during the initialization process and effectively zero post-initialization.
> h3. Requirement 2: Process in correct order
> Late initialization must allow all log messages to be processed in a correct order. Note that there is more than one possible correct order, however any log message B that was logged observably after log message A must appear in the log after A.
> h3. Requirement 3: No lost messages
> When initialization is complete, all log messages which occurred before initialization must be logged and none lost.
> h3. Requirement 4: No mutations
> Messages recorded during initialization cannot be mutated in any way compared to what would have been logged post-initialization; therefore, any log message produced before initialization is complete must have a full copy of its contextual information (caller and MDC/NDC). Note that this requirement is in natural tension with Requirement 1.
> h3. Requirement 5: Tracing
> Capturing full context on every log record, including those at TRACE level, will certainly impose too severe a performance impact for normal usage. A reasonable optimization would be to choose a "safe" level like "INFO" during the initialization process, thereby requiring full capture of only a small number of log records. However this would in turn make debugging during this early stage quite difficult. So, it must be possible to inform the log manager that boot logging must accept messages of any valid level, including TRACE or ALL. The default should lean towards performance, but it should be easily overridable (say, via a system property).
> h3. Requirement 6: Opt-in
> In most common cases, like unit testing, it is desirable to simply start logging from the properties configuration. So, delayed initialization should be opt-in as it is generally a container or advanced feature, and the application in question likely has to take action in order to complete logging initialization.
> h2. Implementation strategy
> A possible implementation strategy would be to create a layer of indirection, centrally managed through the log manager instance, through which all logging is dispatched. This could be done by way of one of the {{org.jboss.logmanager.Logger#logRaw}} or {{org.jboss.logmanager.LoggerNode#publish}} methods.
> h3. State machine
> The layer of indirection could have multiple stages:
> * Uninitialized:
> ** All log records are enqueued
> ** The root logger level is initialized to the level configured by the initial system property
> * Initializing:
> ** All log records are enqueued
> ** Loggers and handlers are configured by the container or user as they wish
> ** At the end of this stage, an "initializationComplete" method on the log manager is called, causing a transition to...
> * Starting:
> ** All log records are enqueued as long as the queue is not "clear", at which point log records are dispatched normally
> ** At the same time, the queue is played back in order and the log messages are dispatched according to their final configuration
> ** When the queue is empty, it is atomically tagged as "clear", and the state is changed to...
> * Running:
> ** All log records are dispatched normally
> Note that Requirement 3 can only be met if the configured initial log level is finer than the minimum level in the final configuration.
> h3. Safety checks
> The initialization message queue should have a configurable (via system property again) limit. A default of, say, 10,000 messages would not be unreasonable and would allow for fairly fine-grained logging. If the cap of enqueued messages is reached, the error handler should report (one time) that the cap was reached and that some messages were lost, and it should suggest that either the level system prop be made coarser, or the limit should be increased, in order to prevent the situation from occurring.
> h3. No delayed initialization desired
> A system property should be added to determine whether the log manager delays its initialization. Per requirements, it should default to false. If true, then default configuration should not be done at all; it is assumed in this case that the user will perform configuration tasks.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-2222) Stunner: Ensure "copy/paste" (nodes) supports DMN's deep definition
by Roger Martinez (Jira)
[ https://issues.redhat.com/browse/DROOLS-2222?page=com.atlassian.jira.plug... ]
Roger Martinez commented on DROOLS-2222:
----------------------------------------
Hey [~manstis] [~karreiro] [~vpellegr]
Lemme share a few ideas behind this task, maybe those help to clarify how to achieve this.
Consider these general ideas:
* All actions/operations in Stunner are _command_ based - everything that the user does, can be a click, can be dragging something, or clicking on some button, it ends up in a command instance, which gets executed and results on some changes on the model/canvas. This way, commands are reusable and can be undone, redone, etc
* So focusing on the _clone_ operation - it also exist a command in the Stunner core for clonning model instances, see [CloneNodeCommand|https://github.com/kiegroup/kie-wb-common/blob/8eb1af188...]
* Also consider that each domain, it can be BPMN or DMN, can declare its own command implementations, it means that we can use different implementation when cloning a node, depending on the domain
Soo I would rely on commands in order to implement the custom cloning behavior for DMN:
* Create a new CloneNodeCommand implementation for DMN, and use it in the DMNCommandFactory
* This new CloneNodeCommand implementation for DMN can inject or declare a custom CloneManager instance as well, or use whatever clone algorithm you've avaiblable
Note about _CloneManager_ and its CDI related usage :
* By looking at actual code I've seen that the CloneManager is being injected by the DefinitionManager, so the CloneNodeCommand is just using this instance, but this means that you cannot rely on CDI to obtain a different CloneManager instance
* It's because on the implementation for any command class, there is no CDI context, you cannot create injection points in the Command classes itself, they're statefull and portable, and no context dependencies are expected
* So if you're plannign to create a "custom" CloneManager for DMN, we'll have to see how to use it in the command class, maybe we can change some getter in the DefinitionManager to allow it...
Please try to read and understand the points above and let's see next steps and how this fit, let's keep in touch!
Thanks!
> Stunner: Ensure "copy/paste" (nodes) supports DMN's deep definition
> -------------------------------------------------------------------
>
> Key: DROOLS-2222
> URL: https://issues.redhat.com/browse/DROOLS-2222
> Project: Drools
> Issue Type: Sub-task
> Components: DMN Editor, Stunner
> Reporter: Michael Anstis
> Assignee: Tiago Dolphine
> Priority: Major
>
> As discussed on DROOLS-2214 Stunner needs to support (or provide extension points) for DMN's "copy/paste" of a {{Node}} to also deep-clone the definition. Please either (a) use this JIRA to record any changes needed in Stunner, (b) provide an explanation of how DMN can override the copy/paste to deep-clone definitions. Thanks.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13379) Redirect after "j_security_check" login does not work if URL has no trailing slash
by Wolfgang Knauf (Jira)
[ https://issues.redhat.com/browse/WFLY-13379?page=com.atlassian.jira.plugi... ]
Wolfgang Knauf updated WFLY-13379:
----------------------------------
Description:
Attached file "Security.ear" contains a web application with a single jsp page "index.jsp" and form based login, which is secured by a Database Identity Store (Elytron).
When calling the root URL of the webapp without specifiying any page and {color:red}*no*{color} trailing slash (http://localhost:8080/SecurityWeb), on WildFly 11 the login form is shown, and then the welcome file "index.jsp" is shown.
On WildFly 19, the login form is shown, and after successful login, there is an error message "404 - Not Found", and the URL in the adress bar changes to http://localhost:8080/j_security_check
It works if the URL is "http://localhost:8080/SecurityWeb/" (trailing slash). It seems WildFly 11 appends the "/" automatically when redirecting to the login form, while WildFly 19 keeps this URL.
To run the sample, you have to add the Elytron config - the script "configure.cli" can be used for this:
jboss-cli.bat --file=path_to\configure.cli
The script "restore-configuration.cli" undoes this configuration.
Username/Password are e.g. "admin"/"admin" - the sample creates a user table based on an ejb and "import.sql" inserts users.
was:
Attached file "Security.ear" contains a web application with a single jsp page "index.jsp" and form based login, which is secured by a Database Identity Store (Elytron).
When calling the root URL of the webapp without specifiying any page and {color:red}*no *{color} trailing slash (http://localhost:8080/SecurityWeb), on WildFly 11 the login form is shown, and then the welcome file "index.jsp" is shown.
On WildFly 19, the login form is shown, and after successful login, there is an error message "404 - Not Found", and the URL in the adress bar changes to http://localhost:8080/j_security_check
It works if the URL is "http://localhost:8080/SecurityWeb/" (trailing slash). It seems WildFly 11 appends the "/" automatically when redirecting to the login form, while WildFly 19 keeps this URL.
To run the sample, you have to add the Elytron config - the script "configure.cli" can be used for this:
jboss-cli.bat --file=path_to\configure.cli
The script "restore-configuration.cli" undoes this configuration.
Username/Password are e.g. "admin"/"admin" - the sample creates a user table based on an ejb and "import.sql" inserts users.
> Redirect after "j_security_check" login does not work if URL has no trailing slash
> ----------------------------------------------------------------------------------
>
> Key: WFLY-13379
> URL: https://issues.redhat.com/browse/WFLY-13379
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 19.0.0.Final
> Reporter: Wolfgang Knauf
> Assignee: Brian Stansberry
> Priority: Major
> Attachments: Security.ear, configure.cli, restore-configuration.cli
>
>
> Attached file "Security.ear" contains a web application with a single jsp page "index.jsp" and form based login, which is secured by a Database Identity Store (Elytron).
> When calling the root URL of the webapp without specifiying any page and {color:red}*no*{color} trailing slash (http://localhost:8080/SecurityWeb), on WildFly 11 the login form is shown, and then the welcome file "index.jsp" is shown.
> On WildFly 19, the login form is shown, and after successful login, there is an error message "404 - Not Found", and the URL in the adress bar changes to http://localhost:8080/j_security_check
> It works if the URL is "http://localhost:8080/SecurityWeb/" (trailing slash). It seems WildFly 11 appends the "/" automatically when redirecting to the login form, while WildFly 19 keeps this URL.
> To run the sample, you have to add the Elytron config - the script "configure.cli" can be used for this:
> jboss-cli.bat --file=path_to\configure.cli
> The script "restore-configuration.cli" undoes this configuration.
> Username/Password are e.g. "admin"/"admin" - the sample creates a user table based on an ejb and "import.sql" inserts users.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13379) Redirect after "j_security_check" login does not work if URL has no trailing slash
by Wolfgang Knauf (Jira)
Wolfgang Knauf created WFLY-13379:
-------------------------------------
Summary: Redirect after "j_security_check" login does not work if URL has no trailing slash
Key: WFLY-13379
URL: https://issues.redhat.com/browse/WFLY-13379
Project: WildFly
Issue Type: Bug
Components: Server
Affects Versions: 19.0.0.Final
Reporter: Wolfgang Knauf
Assignee: Brian Stansberry
Attachments: Security.ear, configure.cli, restore-configuration.cli
Attached file "Security.ear" contains a web application with a single jsp page "index.jsp" and form based login, which is secured by a Database Identity Store (Elytron).
When calling the root URL of the webapp without specifiying any page and {color:red}*no *{color} trailing slash (http://localhost:8080/SecurityWeb), on WildFly 11 the login form is shown, and then the welcome file "index.jsp" is shown.
On WildFly 19, the login form is shown, and after successful login, there is an error message "404 - Not Found", and the URL in the adress bar changes to http://localhost:8080/j_security_check
It works if the URL is "http://localhost:8080/SecurityWeb/" (trailing slash). It seems WildFly 11 appends the "/" automatically when redirecting to the login form, while WildFly 19 keeps this URL.
To run the sample, you have to add the Elytron config - the script "configure.cli" can be used for this:
jboss-cli.bat --file=path_to\configure.cli
The script "restore-configuration.cli" undoes this configuration.
Username/Password are e.g. "admin"/"admin" - the sample creates a user table based on an ejb and "import.sql" inserts users.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13132) Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client
by Ilia Vassilev (Jira)
[ https://issues.redhat.com/browse/WFLY-13132?page=com.atlassian.jira.plugi... ]
Ilia Vassilev updated WFLY-13132:
---------------------------------
Labels: downstream_dependency (was: )
> Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client
> -----------------------------------------------------------
>
> Key: WFLY-13132
> URL: https://issues.redhat.com/browse/WFLY-13132
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 19.0.0.Beta2
> Reporter: Joerg Baesner
> Assignee: Richard Achmatowicz
> Priority: Major
> Labels: downstream_dependency
> Attachments: playground.zip
>
>
> h2. +Issue+
> h3. +General Client setup:+
> {code:java}
> Properties p = new Properties();
> p.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
> p.put(Context.PROVIDER_URL, {see below});
> p.put(Context.SECURITY_PRINCIPAL, USER);
> p.put(Context.SECURITY_CREDENTIALS, PWD);
> Context context = new InitialContext(p);
> {code}
> ----
> h3. +Standard server configuration:+
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:ejb3:5.0">
> ...
> <remote connector-ref="http-remoting-connector" thread-pool-name="default">
> <channel-creation-options>
> <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/>
> <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/>
> </channel-creation-options>
> </remote>
> ...
> </subsystem>
> ...
> <subsystem xmlns="urn:jboss:domain:remoting:4.0">
> <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm">
> <properties>
> <property name="SSL_ENABLED" value="false"/>
> </properties>
> </connector>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
> </subsystem>
> {code}
> h5. +invocation from remote client to server with:+
> * {{remote://localhost:4447}}
> * {{remote+http://localhost:8080}}
> h5. +Client side topology update always:+
> {noformat}
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node0
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:8080
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node1
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:8180
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-web
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-ejb
> {noformat}
> ----
> h3. +Legacy server configuration:+
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:ejb3:5.0">
> ...
> <remote connector-ref="remoting-connector" thread-pool-name="default">
> <channel-creation-options>
> <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/>
> <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/>
> </channel-creation-options>
> </remote>
> ...
> </subsystem>
> ...
> <subsystem xmlns="urn:jboss:domain:remoting:4.0">
> <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm">
> <properties>
> <property name="SSL_ENABLED" value="false"/>
> </properties>
> </connector>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
> </subsystem>
> {code}
> h5. +invocation from remote client to server with:+
> * {{remote://localhost:4447}}
> * {{remote+http://localhost:8080}}
> h5. +Client side topology update always:+
> {noformat}
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node0
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:4447
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node1
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:4547
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-web
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-ejb
> {noformat}
> h2. +Conclusion+
> Depending on what is configured as {{connector-ref}} in the {{remote}} of the _ejb3_ subsystem the {{CLUSTER_TOPOLOGY}} update is different. From a client perspective it would be expected that either the {{CLUSTER_TOPOLOGY}} update would _only_ contain destinations that are applicable for the _connector/protocol_ that has been used, or maybe even _ALL_ available destinations, as the client could potentially run a mix of protocols between invocations...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-5242) Executable model silently ignores a malformed modify statement
by Mario Fusco (Jira)
Mario Fusco created DROOLS-5242:
-----------------------------------
Summary: Executable model silently ignores a malformed modify statement
Key: DROOLS-5242
URL: https://issues.redhat.com/browse/DROOLS-5242
Project: Drools
Issue Type: Bug
Reporter: Mario Fusco
Assignee: Mario Fusco
Normally a modify should be written like
{code}
modify($p) { setName("Mark") }
{code}
and in fact in drl if you try to use the name of the modifed variable also inside the modify block like in
{code}
modify($p) { $p.setName("Mark") }
{code}
it emits a compile time error. Conversely the executable model generator just ignores the modify statement and generates a model without it which is misleading. It has to also emit a compile time error.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFCORE-4923) read-resource operation does not resolve expressions recursively
by Tamás Ábele (Jira)
[ https://issues.redhat.com/browse/WFCORE-4923?page=com.atlassian.jira.plug... ]
Tamás Ábele commented on WFCORE-4923:
-------------------------------------
Hi Jeff!
The mention one line modification solved the problem for me. Dou you think this can be included in the next release? Should I do a pull or merge request on GITHUB?
> read-resource operation does not resolve expressions recursively
> ----------------------------------------------------------------
>
> Key: WFCORE-4923
> URL: https://issues.redhat.com/browse/WFCORE-4923
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 12.0.0.Beta1
> Reporter: Tamás Ábele
> Assignee: Jeff Mesnil
> Priority: Major
> Attachments: hal-error1.png, hal-error2.png
>
>
> The problem affects all versions. The wildfly controller does not resolve expression resursively which causes improper behaviour of the jbos CLI.
> {code:json}
> [standalone@localhost:9992 /] /subsystem=batch-jberet:read-resource(include-runtime=true,recursive=true,resolve-expressions=true)
> {
> "outcome" => "success",
> "result" => {
> "restart-jobs-on-resume" => true,
> "security-domain" => undefined,
> "default-job-repository" => "in-memory",
> "default-thread-pool" => "batch",
> "in-memory-job-repository" => {"in-memory" => {}},
> "jdbc-job-repository" => undefined,
> "thread-factory" => undefined,
> "thread-pool" => {"batch" => {
> "active-count" => 0,
> "completed-task-count" => 0L,
> "current-thread-count" => 0,
> "keepalive-time" => {
> "time" => 30L,
> "unit" => "SECONDS"
> },
> "largest-thread-count" => 0,
> "max-threads" => expression "${batch-max-threads}",
> "name" => "batch",
> "queue-size" => 0,
> "rejected-count" => 0,
> "task-count" => 0L,
> "thread-factory" => undefined
> }}
> }
> }
> {code}
> The missing recursive expression resolvation also causes runtime errors in the wildfly console (HAL) if you use properties your configuration XML-s (standalone.xml, domain.xml, ...) Two examples can be found in the attachements.
> The solution would be only adding the
> {code:java}
> rrOp.get(ModelDescriptionConstants.RESOLVE_EXPRESSIONS).set(resolve);
> {code}
> line after
> {code:java}
> rrOp.get(ModelDescriptionConstants.INCLUDE_DEFAULTS).set(defaults);
> {code}
> in the doExecuteInternal method of the
> \controller\src\main\java\org\jboss\as\controller\operations\global\ReadResourceHandler.java
> The wildfly console (HAL) source code is also buggy, which when creates an operation like this
> {code:java}
> Operation operation = new Operation.Builder(address, READ_RESOURCE_OPERATION)
> {code}
> in several places I found does not contain the line
> {code:java}
> .param(RESOLVE_EXPRESSIONS, true)
> {code}
> and this will cause unresolved expressions to be returned and later numeric error to be thrown while trying to read them.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years