[JBoss JIRA] (WFCORE-1737) rrd on data-source=*/statistics=pool throws NPE
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1737?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1737:
------------------------------------------
This is all about the classic double meaning of the '*' character problem.
There is a ManagementResourceRegistration specifically for /subsystem=datasources/data-source=*. But it has no child for "statistics=pool". Which isn't handled correctly, hence the NPE.
But the '*' character can also mean, in the read-resource-description operation, "look for MRRs whose address matches this pattern", and that would also result in finding the override MRR for /subsystem=datasources/data-source=ExampleDS. And that one does have a child for "statistics=pool".
GlobalOperationHandlers$RegistrationAddressResolver needs to handle this scenario correctly. No NPE and find the matching MRR.
> rrd on data-source=*/statistics=pool throws NPE
> -----------------------------------------------
>
> Key: WFCORE-1737
> URL: https://issues.jboss.org/browse/WFCORE-1737
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Claudio Miranda
> Assignee: Brian Stansberry
>
> Run the following command in CLI it throws a NullPointerException
> As it is a rrd it should not require a resolved wildcard
> {code}
> /subsystem=datasources/data-source=*/statistics=pool:read-resource-description
> {code}
> Results
> {code}
> {
> "outcome" => "failed",
> "result" => [],
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
> "rolled-back" => true
> }
> {code}
> The exception throws at server.log
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("resolve") failed - address: ([]): java.lang.NullPointerException
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:422)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$RegistrationAddressResolver.executeSingleTargetChild(GlobalOperationHandlers.java:903)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:442)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$RegistrationAddressResolver.executeMultiTargetChildren(GlobalOperationHandlers.java:895)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:440)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$RegistrationAddressResolver.executeSingleTargetChild(GlobalOperationHandlers.java:903)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:442)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:337)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> This op works
> {code}
> /subsystem=datasources/data-source=*:read-resource-description
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFCORE-1742) Allow registering a custom handler for management interface
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1742?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1742:
----------------------------------------
Assignee: (was: Brian Stansberry)
> Allow registering a custom handler for management interface
> -----------------------------------------------------------
>
> Key: WFCORE-1742
> URL: https://issues.jboss.org/browse/WFCORE-1742
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Sebastian Łaskawiec
>
> When building [HealthCheck API for Infisnispan|https://github.com/infinispan/infinispan/pull/4499] we noticed there is no way to register a custom endpoint on Management REST interface. Without it, calling the API requires using HTTP POST method (since it includes runtime parameters) and the URL is very long (and not intuitive for our users):
> {noformat}
> curl --digest -L -D - "http://localhost:9990/management/subsystem/datagrid-infinispan/cache-cont..." --header "Content-Type: application/json" -u ispnadmin:ispnadmin
> HTTP/1.1 401 Unauthorized
> Connection: keep-alive
> WWW-Authenticate: Digest realm="ManagementRealm",domain="/management",nonce="AuZzFxz7uC4NMTQ3MDgyNTU1NTQ3OCfIJBHXVpPHPBdzGUy7Qts=",opaque="00000000000000000000000000000000",algorithm=MD5,qop="auth"
> Content-Length: 77
> Content-Type: text/html
> Date: Wed, 10 Aug 2016 10:39:15 GMT
> HTTP/1.1 200 OK
> Connection: keep-alive
> Authentication-Info: nextnonce="AuZzFxz7uC4NMTQ3MDgyNTU1NTQ3OCfIJBHXVpPHPBdzGUy7Qts=",qop="auth",rspauth="b518c3170e627bd732055c382ce5d970",cnonce="NGViOWM0NDY5OGJmNjY0MjcyOWE4NDkyZDU3YzNhYjY=",nc=00000001
> Content-Type: application/json; charset=utf-8
> Content-Length: 1927
> Date: Wed, 10 Aug 2016 10:39:15 GMT
> {
> "cache-health" : "GREEN",
> "cluster-health" : ["test"],
> "cluster-name" : "clustered",
> "free-memory" : 96778,
> "log-tail" : [
> "2016-08-10 11:54:14,706 INFO [org.infinispan.server.endpoint] (MSC service thread 1-5) DGENDPT10001: HotRodServer listening on 127.0.0.1:11222",
> "2016-08-10 11:54:14,706 INFO [org.infinispan.server.endpoint] (MSC service thread 1-1) DGENDPT10001: MemcachedServer listening on 127.0.0.1:11211",
> "2016-08-10 11:54:14,785 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___protobuf_metadata cache from clustered container",
> "2016-08-10 11:54:14,800 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___script_cache cache from clustered container",
> "2016-08-10 11:54:15,159 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-5) DGISPN0001: Started ___hotRodTopologyCache cache from clustered container",
> "2016-08-10 11:54:15,210 INFO [org.infinispan.rest.NettyRestServer] (MSC service thread 1-6) ISPN012003: REST server starting, listening on 127.0.0.1:8080",
> "2016-08-10 11:54:15,210 INFO [org.infinispan.server.endpoint] (MSC service thread 1-6) DGENDPT10002: REST mapped to /rest",
> "2016-08-10 11:54:15,306 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management",
> "2016-08-10 11:54:15,307 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990",
> "2016-08-10 11:54:15,307 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: Infinispan Server 9.0.0-SNAPSHOT (WildFly Core 2.2.0.CR9) started in 8681ms - Started 196 of 237 services (121 services are lazy, passive or on-demand)"
> ],
> "number-of-cpus" : 8,
> "number-of-nodes" : 1,
> "total-memory" : 235520
> }%
> {noformat}
> It would be very convenient to allow exposing such endpoints with optional authorization and using custom URLs (e.g. something like http://localhost:9990/health).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFCORE-1742) Allow registering a custom handler for management interface
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1742?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved WFLY-6994 to WFCORE-1742:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1742 (was: WFLY-6994)
Component/s: Domain Management
(was: Domain Management)
> Allow registering a custom handler for management interface
> -----------------------------------------------------------
>
> Key: WFCORE-1742
> URL: https://issues.jboss.org/browse/WFCORE-1742
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Sebastian Łaskawiec
> Assignee: Brian Stansberry
>
> When building [HealthCheck API for Infisnispan|https://github.com/infinispan/infinispan/pull/4499] we noticed there is no way to register a custom endpoint on Management REST interface. Without it, calling the API requires using HTTP POST method (since it includes runtime parameters) and the URL is very long (and not intuitive for our users):
> {noformat}
> curl --digest -L -D - "http://localhost:9990/management/subsystem/datagrid-infinispan/cache-cont..." --header "Content-Type: application/json" -u ispnadmin:ispnadmin
> HTTP/1.1 401 Unauthorized
> Connection: keep-alive
> WWW-Authenticate: Digest realm="ManagementRealm",domain="/management",nonce="AuZzFxz7uC4NMTQ3MDgyNTU1NTQ3OCfIJBHXVpPHPBdzGUy7Qts=",opaque="00000000000000000000000000000000",algorithm=MD5,qop="auth"
> Content-Length: 77
> Content-Type: text/html
> Date: Wed, 10 Aug 2016 10:39:15 GMT
> HTTP/1.1 200 OK
> Connection: keep-alive
> Authentication-Info: nextnonce="AuZzFxz7uC4NMTQ3MDgyNTU1NTQ3OCfIJBHXVpPHPBdzGUy7Qts=",qop="auth",rspauth="b518c3170e627bd732055c382ce5d970",cnonce="NGViOWM0NDY5OGJmNjY0MjcyOWE4NDkyZDU3YzNhYjY=",nc=00000001
> Content-Type: application/json; charset=utf-8
> Content-Length: 1927
> Date: Wed, 10 Aug 2016 10:39:15 GMT
> {
> "cache-health" : "GREEN",
> "cluster-health" : ["test"],
> "cluster-name" : "clustered",
> "free-memory" : 96778,
> "log-tail" : [
> "2016-08-10 11:54:14,706 INFO [org.infinispan.server.endpoint] (MSC service thread 1-5) DGENDPT10001: HotRodServer listening on 127.0.0.1:11222",
> "2016-08-10 11:54:14,706 INFO [org.infinispan.server.endpoint] (MSC service thread 1-1) DGENDPT10001: MemcachedServer listening on 127.0.0.1:11211",
> "2016-08-10 11:54:14,785 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___protobuf_metadata cache from clustered container",
> "2016-08-10 11:54:14,800 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___script_cache cache from clustered container",
> "2016-08-10 11:54:15,159 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-5) DGISPN0001: Started ___hotRodTopologyCache cache from clustered container",
> "2016-08-10 11:54:15,210 INFO [org.infinispan.rest.NettyRestServer] (MSC service thread 1-6) ISPN012003: REST server starting, listening on 127.0.0.1:8080",
> "2016-08-10 11:54:15,210 INFO [org.infinispan.server.endpoint] (MSC service thread 1-6) DGENDPT10002: REST mapped to /rest",
> "2016-08-10 11:54:15,306 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management",
> "2016-08-10 11:54:15,307 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990",
> "2016-08-10 11:54:15,307 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: Infinispan Server 9.0.0-SNAPSHOT (WildFly Core 2.2.0.CR9) started in 8681ms - Started 196 of 237 services (121 services are lazy, passive or on-demand)"
> ],
> "number-of-cpus" : 8,
> "number-of-nodes" : 1,
> "total-memory" : 235520
> }%
> {noformat}
> It would be very convenient to allow exposing such endpoints with optional authorization and using custom URLs (e.g. something like http://localhost:9990/health).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFCORE-1731) Exception generated from command "connection-info" with embedded server
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1731?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1731:
-------------------------------------
Summary: Exception generated from command "connection-info" with embedded server (was: Exception generated from command "connection-info")
> Exception generated from command "connection-info" with embedded server
> -----------------------------------------------------------------------
>
> Key: WFCORE-1731
> URL: https://issues.jboss.org/browse/WFCORE-1731
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management, Security
> Affects Versions: 3.0.0.Alpha5
> Environment: JBoss Admin Command-line Interface
> JBOSS_HOME: C:\dev\jboss-eap-7.0.1
> JBoss AS release: 2.1.6.Final-redhat-1 "Kenny"
> JBoss AS product: JBoss EAP 7.0.1.GA
> JAVA_HOME: c:\java\jdk1.8.0_45
> java.version: 1.8.0_45
> java.vm.vendor: Oracle Corporation
> java.vm.version: 25.45-b02
> os.name: Windows 7
> os.version: 6.1
> Reporter: Petr Kremensky
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> I started the embedded server and tried to obtain the connection information. An exception occurred:
> {code}
> [standalone@embedded /] connection-info
> 13:14:59,095 ERROR [org.jboss.as.controller.management-operation] (AeshProcess: 32) WFLYCTL0013: Operation ("whoami") failed - address: ([]): java.lang.IllegalArgumentException: newValue is null
> at org.jboss.dmr.ModelNode.set(ModelNode.java:499)
> at org.jboss.as.domain.management.security.WhoAmIOperation.execute(WhoAmIOperation.java:95)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204)
> at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:659)
> at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:649)
> at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.execute(DelegatingModelControllerClient.java:63)
> at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.execute(ThreadContextsModelControllerClient.java:59)
> at org.jboss.as.cli.handlers.ConnectionInfoHandler.doHandle(ConnectionInfoHandler.java:74)
> at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88)
> at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:776)
> at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:799)
> at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:412)
> at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: newValue is null
> Failed to handle 'connection-info': java.lang.NullPointerException
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFLY-7017) add-user.sh script should have better help message
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7017?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev moved JBEAP-5782 to WFLY-7017:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7017 (was: JBEAP-5782)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
Scripts
(was: Domain Management)
(was: Scripts)
Affects Version/s: 10.1.0.Final
(was: 7.1.0.DR3)
> add-user.sh script should have better help message
> --------------------------------------------------
>
> Key: WFLY-7017
> URL: https://issues.jboss.org/browse/WFLY-7017
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Scripts
> Affects Versions: 10.1.0.Final
> Reporter: Ilia Vassilev
> Assignee: Ilia Vassilev
>
> add-user.sh script should have better help message. There is no general description about this script. There is only list of attributes.
> {code:bash}
> ./add-user.sh -h
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (ELY-428) HTTP Mechanism configuration during deployment
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-428?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse resolved ELY-428.
----------------------------------
Resolution: Rejected
This issue has been discussed.
The Elytron HTTP mechanism framework is based around mechanisms being stateless so there is no 'on deployment' step from the perspective of the mechanism. Mechanisms however can store state in scopes and so on first access if required information is not in the scope generate it and store it.
Within the application server alternative mechanism factories can be provided by other subsystems which have the option of subsystem level configuration instead of configuraton bundled within a deployment.
> HTTP Mechanism configuration during deployment
> ----------------------------------------------
>
> Key: ELY-428
> URL: https://issues.jboss.org/browse/ELY-428
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: HTTP
> Affects Versions: 1.0.2.Final
> Reporter: Pedro Igor
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 1.1.0.Beta9
>
>
> It should be possible to configure a HTTP mechanism during deployment in order to parse/load configuration and reuse it in subsequent requests to an application.
> The most common use case for that is around mechanisms that need to read some configuration from inside a deployment (or provided by the mech config) when it is being deployed to the server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFCORE-1726) CLI support for response attachments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1726?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1726:
------------------------------------------
I've opened WFCORE-1741 for the read-content problem and linked it to this one.
> CLI support for response attachments
> ------------------------------------
>
> Key: WFCORE-1726
> URL: https://issues.jboss.org/browse/WFCORE-1726
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> CLI doesn't support the streams attached to a response. Incremental deployment support offers today the ability to read the content of a deployment. It would be interesting to operate it from the CLI. Some resource (such as the log file) expose some attributes as stream.
> The following operations are returning streams:
> /subsystem=logging/log-file=server.log:read-attribute(name=stream)
> /subsystem=logging/log-file=server.log:read-resource(include-runtime)
> /deployment=toto:read-content(path=index.html)
> As we can see, streams can be located in attributes, as operation response, inside a resource.
> The CLI offers 2 way to approach the problem:
> 1) Extend the Low level operation support with a way to save/display attached streams. This would require some XML configuration and possibly UI workflow to prompt user for the right action. Making from stream to file path would be not ideal and far from being user friendly. The good side is tha tit would work in any case (batch, non batch). The XML configuration can be a bit complex and prompting user is not an ideal workflow.
> 2) Define a new high level command that would cope with any operation.
> Such command would look like:
> attachment save --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream) --file=/my/local/path/to/file
> attachment display --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream)
> - No risk to impact existing scripts. This is a new feature, so people would have to update their scripts to add the command.
> - The challenge is located in mapping a Stream to a file name. The user provides the name he wants. Furthermore, in interactive mode, the user can use completion to complete this target file.
> - No more prompting, the user knows ahead of time what he wants to do.
> - Problem is that batch mode doesn't re-dispatch each step response to each input command. So some logic should be needed to properly handle streams in batch.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFCORE-1741) read-content operation does not return the uuid of the stream as the operation result
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1741:
----------------------------------------
Summary: read-content operation does not return the uuid of the stream as the operation result
Key: WFCORE-1741
URL: https://issues.jboss.org/browse/WFCORE-1741
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: ehsavoie Hugonnet
Fix For: 3.0.0.Alpha6
See the tail end of the discussion on WFCORE-1726.
The rules around streams in responses are:
1) If the thing providing the stream is an attribute, the attribute value set by the read OperationStepHandler must be the uuid of the stream.
2) If the thing providing the stream is a custom operation like :read-content, the result value in the response must be the uuid of the stream.
Metadata about streams is propagated to the client using a response-header. But since a particular request can result in more than one attached stream, the normal non-response-header part of the result for a step must provide the uuid of the stream set by that step. This allows the client to correlate the various streams with the steps that provided them.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFLY-7016) Wildfly 10.1 IllegalStateException when starting applications when getting a session in a listener
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7016?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7016:
-----------------------------------
Summary: Wildfly 10.1 IllegalStateException when starting applications when getting a session in a listener (was: Wildfly 10.1 now crashes when starting applications when getting a session in a listener )
> Wildfly 10.1 IllegalStateException when starting applications when getting a session in a listener
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-7016
> URL: https://issues.jboss.org/browse/WFLY-7016
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Reporter: Matthew Casperson
> Assignee: Stuart Douglas
>
> We have the following code in a ServletRequestListener:
> {code}
> final HttpSession httpSession = httpRequest.getSession(false);
> {code}
> This code is the line:
> {code}
> [Server:main-server] at au.com.agic.settings.listener.SessionInvalidatorListener.clearSession(SessionInvalidatorListener.java:94)
> {code}
> in the stack trace below.
> We have been running applications with this listener in WildFly 10 for months without any issues, but when we migrated to WildFly 10.1, Infinispan started throwing exceptions when opening the app for the first time. The exception doesn't always happen, but often enough to make WildFly 10.1 unusable.
> The configuration was copied directly from WildFly 10 to WildFly 10.1, so there are no configuration changes between the two versions.
> {code}
> [Server:main-server] 2016-08-26 15:03:10+1000 ERROR [[io.undertow.request]] [[default task-32]] UT005023: Exception handling request to /app/retrieve_quote.jsp: java.lang.IllegalStateException: Transaction TransactionImple < ac, BasicAction: 0:ffff0a1617d4:6cdfa442:57bfb3cd:31b status: ActionStatus.COMMITTED > is not in a valid state to be invoking cache operations on.
> [Server:main-server] at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:395)
> [Server:main-server] at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:351)
> [Server:main-server] at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:345)
> [Server:main-server] at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:331)
> [Server:main-server] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [Server:main-server] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [Server:main-server] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [Server:main-server] at org.infinispan.statetransfer.StateTransferInterceptor.visitReadCommand(StateTransferInterceptor.java:177)
> [Server:main-server] at org.infinispan.statetransfer.StateTransferInterceptor.visitGetKeyValueCommand(StateTransferInterceptor.java:154)
> [Server:main-server] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [Server:main-server] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:114)
> [Server:main-server] at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:83)
> [Server:main-server] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [Server:main-server] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [Server:main-server] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [Server:main-server] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [Server:main-server] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335)
> [Server:main-server] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
> [Server:main-server] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:403)
> [Server:main-server] at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> [Server:main-server] at org.wildfly.clustering.server.registry.CacheRegistry.getEntry(CacheRegistry.java:128)
> [Server:main-server] at org.wildfly.clustering.web.infinispan.session.InfinispanRouteLocator.locate(InfinispanRouteLocator.java:58)
> [Server:main-server] at org.wildfly.clustering.web.undertow.session.DistributableSessionIdentifierCodec.encode(DistributableSessionIdentifierCodec.java:48)
> [Server:main-server] at org.wildfly.extension.undertow.session.CodecSessionConfig.findSessionId(CodecSessionConfig.java:60)
> [Server:main-server] at io.undertow.servlet.spec.ServletContextImpl$ServletContextSessionConfig.findSessionId(ServletContextImpl.java:1084)
> [Server:main-server] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:778)
> [Server:main-server] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:370)
> [Server:main-server] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:375)
> [Server:main-server] at au.com.agic.settings.listener.SessionInvalidatorListener.clearSession(SessionInvalidatorListener.java:94)
> [Server:main-server] at au.com.agic.settings.listener.SessionInvalidatorListener.requestInitialized(SessionInvalidatorListener.java:52)
> [Server:main-server] at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:246)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:291)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> [Server:main-server] at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> [Server:main-server] at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> [Server:main-server] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> [Server:main-server] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:main-server] at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFCORE-1726) CLI support for response attachments
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1726?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1726:
----------------------------------------------
Implementation went well. Works in all workflow (nominal, batch, if, try).
Branch is: https://github.com/jfdenise/wildfly-core/tree/streams-read-content
The command is attachment {display|save} --operation=<operation> [--file=<path to file>]
The read-content will have to be updated to contain somewhere the uuid.
> CLI support for response attachments
> ------------------------------------
>
> Key: WFCORE-1726
> URL: https://issues.jboss.org/browse/WFCORE-1726
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> CLI doesn't support the streams attached to a response. Incremental deployment support offers today the ability to read the content of a deployment. It would be interesting to operate it from the CLI. Some resource (such as the log file) expose some attributes as stream.
> The following operations are returning streams:
> /subsystem=logging/log-file=server.log:read-attribute(name=stream)
> /subsystem=logging/log-file=server.log:read-resource(include-runtime)
> /deployment=toto:read-content(path=index.html)
> As we can see, streams can be located in attributes, as operation response, inside a resource.
> The CLI offers 2 way to approach the problem:
> 1) Extend the Low level operation support with a way to save/display attached streams. This would require some XML configuration and possibly UI workflow to prompt user for the right action. Making from stream to file path would be not ideal and far from being user friendly. The good side is tha tit would work in any case (batch, non batch). The XML configuration can be a bit complex and prompting user is not an ideal workflow.
> 2) Define a new high level command that would cope with any operation.
> Such command would look like:
> attachment save --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream) --file=/my/local/path/to/file
> attachment display --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream)
> - No risk to impact existing scripts. This is a new feature, so people would have to update their scripts to add the command.
> - The challenge is located in mapping a Stream to a file name. The user provides the name he wants. Furthermore, in interactive mode, the user can use completion to complete this target file.
> - No more prompting, the user knows ahead of time what he wants to do.
> - Problem is that batch mode doesn't re-dispatch each step response to each input command. So some logic should be needed to properly handle streams in batch.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months