[JBoss JIRA] (WFLY-7024) show-resources operation of jaxrs subsystem must provide more informations and statistics about end-point
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-7024?page=com.atlassian.jira.plugin.... ]
Lin Gao moved JBEAP-5814 to WFLY-7024:
--------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7024 (was: JBEAP-5814)
Issue Type: Feature Request (was: Enhancement)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: REST
(was: REST)
> show-resources operation of jaxrs subsystem must provide more informations and statistics about end-point
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7024
> URL: https://issues.jboss.org/browse/WFLY-7024
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Reporter: Lin Gao
> Assignee: Lin Gao
> Priority: Critical
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> show-resources operation of jaxrs subsystem must provide more informations about end-point. Information about parameters and returned value should be provided.
> Example:
> {code:java}
> @GET
> @Path("entity/get")
> @Produces(MediaType.APPLICATION_JSON)
> public Person post3(@QueryParam("boolean") @DefaultValue("false") boolean v) {
> Person per = new Person();
> per.setName("per");
> per.setFamily("son");
> return per;
> }
> {code}
> Actual return value of {{/deployment=jaxrs-eap.war/subsystem=jaxrs:show-resources}}:
> {noformat}
> {
> "resource-class" => "org.resteasy.simple.deployment.AdvancedService",
> "resource-path" => "/sample/entity/get",
> "resource-methods" => ["GET /jaxrs-eap/a/sample/entity/get - org.resteasy.simple.deployment.AdvancedService.post3(...)"]
> },
> {noformat}
> There should be information about "boolean v" parameter and about returned type (Person).
> ---
> jax-rs subsystem should be able to collect some statistics about invocation of end-points (count of invocations, execution time, etc.)
> Some statistics could be be activated and printed, only if end-point is also EJB bean, example:
> {noformat}
> /subsystem=ejb3:write-attribute(name=enable-statistics,value=true)
> /deployment=cdiexp-1.0-SNAPSHOT.jar/subsystem=ejb3/stateless-session-bean=Servicer:read-resource(include-runtime=true)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (DROOLS-1256) ForceEagerActivationOption and "not()" LHS pattern does not invoke matchCreated listener
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1256?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-1256:
----------------------------------------
Typical steps of creation and usage of the session with the listener is as follows:
# create the KieSession
# register the listener
# fireAllRules() - or fireUntilHalt()
the same is also outlined in the reported test.
However with the rules as described here, and the option {{ForceEagerActivationOption.YES}} enabled, the matchCreated events are happening contextually to step 1, hence _before_ the listener gets to be actually registered.
> ForceEagerActivationOption and "not()" LHS pattern does not invoke matchCreated listener
> ----------------------------------------------------------------------------------------
>
> Key: DROOLS-1256
> URL: https://issues.jboss.org/browse/DROOLS-1256
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.0.0.Beta1
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Minor
>
> Given the following rules
> {code:java}
> rule ND
> when
> not ( Double() )
> then
> // do nothing.
> end
> rule ND2
> salience 1
> when
> not ( Double() )
> then
> insert( new Double(0) );
> end
> {code}
> and KieSession created with {{ForceEagerActivationOption.YES}} and a generic AgendaEventListener on fire all rules returns:
> {code:java}
> created: 0 cancelled: 1 fired: 1
> {code}
> hence incoherent as matchcreated .
> Expected: created=2, cancelled=1, fired=1.
> Reporting this as also I understand this eager option is used by jBPM.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-1093) TempFileProviderService threads consume high CPU
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1093?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1093:
-------------------------------------------------
Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 1277699|https://bugzilla.redhat.com/show_bug.cgi?id=1277699] from ON_QA to VERIFIED
> TempFileProviderService threads consume high CPU
> ------------------------------------------------
>
> Key: WFCORE-1093
> URL: https://issues.jboss.org/browse/WFCORE-1093
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Aaron Ogburn
> Assignee: Jason Greene
> Fix For: 2.0.3.Final
>
>
> TempFileProviderService threads consume high CPU as they poll their non empty task queue. This is ultimately due to a flaw in the JDK ThreadPoolExecutor code (https://bugs.openjdk.java.net/browse/JDK-8129861), impacting ScheduledThreadPoolExecutors that use a core size of 0 and a default 0 keepalive timeout.
> While the executor queue is not empty, the executor does not allow the pool to go below 1 thread. So the one remaining work thread keeps looping over its poll call with a 0 timeout. Options to protect JBoss from this are:
> 1) Set a keepalive timeout on the executor so the poll has a duration and the worker run loop isn't so busy
> 2) Or set the Executor core pool size to >0. The worker thread would then use a blocking take() call on its queue instead of a constant 0 second poll calls. The side effect of this change is that the thread pool wouldn't ever drop back down to 0.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (DROOLS-1221) Add fail-safe and scalability functionality to the Drools (CEP) rules engine
by Tom Pijl (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1221?page=com.atlassian.jira.plugi... ]
Tom Pijl commented on DROOLS-1221:
----------------------------------
Hi Youcef,
Thanks for the slide set about the Italian HACEP project. It makes it much more clear.
I intend to port the Italian HACEP solution to the Amazon cloud replacing Infinispan, ActiveMQ, Camel Route, etc. with Amazon equivalents. The grouping is done on Tenant (aka customer environment).
The domain is Business Event Monitoring in the cloud.
Are you going to use Apache Geode in your project as a replacement for Infinispan? If so, why?
> Add fail-safe and scalability functionality to the Drools (CEP) rules engine
> ----------------------------------------------------------------------------
>
> Key: DROOLS-1221
> URL: https://issues.jboss.org/browse/DROOLS-1221
> Project: Drools
> Issue Type: Feature Request
> Components: core engine
> Affects Versions: 6.4.0.Final
> Environment: Drools (CEP) Rule engine 6.4.0.Final
> Reporter: Tom Pijl
> Assignee: Mario Fusco
>
> The Drools Rule engine is currently not fail-safe and scalable which is a requirement for Cloud deployment.
> Add a possibility to persist the state of the working memory after each state change (perhaps linked to the fireAllRules()?) and related to that the possibility to restore the state in case of a crash (fail-safe requirement).
> This persistent state store can also be used to synchronize multiple engine instances (scalability requirement).
> Of course this has major impact on the performance of the engine, but it is the only way to make the engine useful in a multi-tenant Cloud environment
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-1750) [2.2.x] WFLYCTL0357 warning upon undeploying any deployment
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1750?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1750:
----------------------------------------
Assignee: Frank Langelage (was: Chao Wang)
Resolution: Done
> [2.2.x] WFLYCTL0357 warning upon undeploying any deployment
> -----------------------------------------------------------
>
> Key: WFCORE-1750
> URL: https://issues.jboss.org/browse/WFCORE-1750
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Affects Versions: 2.2.0.Final
> Reporter: Frank Langelage
> Assignee: Frank Langelage
> Fix For: 2.2.1.Final
>
>
> EAP produces following warning upon undeployment:
> {code}WARN [org.jboss.as.controller] (management-handler-thread - 4) WFLYCTL0357: Notification of type deployment-undeployed is not described for the resource at the address []{code}
> The warning is produced for both managed and unmanaged deployments.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[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 updated WFCORE-1737:
-------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1762
> 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
> Fix For: 3.0.0.Alpha6
>
>
> 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)
9 years, 7 months
[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 updated WFCORE-1737:
-------------------------------------
Fix Version/s: 3.0.0.Alpha6
> 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
> Fix For: 3.0.0.Alpha6
>
>
> 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)
9 years, 7 months
[JBoss JIRA] (WFLY-6192) JAXBUsageTestCase fails with security manager with security manager enabled
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6192?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-6192:
--------------------------------------
Why do you think we should not be unmarshalling inside a privileged block? Otherwise the whole deployment needs to be given the privileges. Unmarshalling inside this block will not grant any additional permissions to user code that is invoked in the unmarshalling process.
> JAXBUsageTestCase fails with security manager with security manager enabled
> ---------------------------------------------------------------------------
>
> Key: WFLY-6192
> URL: https://issues.jboss.org/browse/WFLY-6192
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Hynek Švábek
> Assignee: Ivo Studensky
>
> *org.jboss.as.test.integration.jaxb.unit.JAXBUsageTestCase#testJAXBServlet*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.jaxb.unit.JAXBUsageTestCase#testJAXBServlet}}
> Fails with:
> {code}
> ERROR [io.undertow.request] (default task-46) UT005023: Exception handling request to /jaxb-webapp//jaxbServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/jaxb-webapp.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.Thread.getContextClassLoader(Thread.java:500)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:279)
> at org.jboss.as.test.integration.jaxb.JAXBUsageServlet.doGet(JAXBUsageServlet.java:50)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
> at java.security.AccessController.doPrivileged(AccessController.java:650)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-1751) read-resource-description cannot handle segmented multi-target requests
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1751?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1751:
-------------------------------------
Description:
This is really low priority; I'm just recording it as I discovered it while writing tests for WFCORE-1737. Anyone looking at it should talk to me first.
This doesn't work:
{code}
/] /subsystem=[undertow,logging]/server=*:read-resource-description
Failed to get the list of the operation properties: "WFLYCTL0030: No resource definition is registered for address [
("subsystem" => "[undertow,logging]"),
("server" => "*")
]"
{code}
This does though, finding the subsystem=undertow registration:
{code}
/subsystem=*/server=*:read-resource-description
{code}
The read-resource op works for segmented multi-target requests as GlobalOperationHandlers.ModelAddressResolver has specific logic for it in executeMultiTargetChildren. GlobalOperationHandlers.RegistrationAddressResolver does not.
was:
This is really low priority; I'm just recording it as I discovered it while writing tests for WFCORE-1737. Anyone looking at it should talk to me first.
This doesn't work:
{code}
/] /subsystem=[undertow,logging]/server=*:read-resource-description
Failed to get the list of the operation properties: "WFLYCTL0030: No resource definition is registered for address [
("subsystem" => "[undertow,logging]"),
("server" => "*")
]"
{code}
This does though, finding the subsystem=undertow registration:
/subsystem=*/server=*:read-resource-description
read-resource works for segmented multi-target requests as GlobalOperationHandlers.ModelAddressResolver has specific logic for it in executeMultiTargetChildren. GlobalOperationHandlers.RegistrationAddressResolver does not.
> read-resource-description cannot handle segmented multi-target requests
> -----------------------------------------------------------------------
>
> Key: WFCORE-1751
> URL: https://issues.jboss.org/browse/WFCORE-1751
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Priority: Minor
>
> This is really low priority; I'm just recording it as I discovered it while writing tests for WFCORE-1737. Anyone looking at it should talk to me first.
> This doesn't work:
> {code}
> /] /subsystem=[undertow,logging]/server=*:read-resource-description
> Failed to get the list of the operation properties: "WFLYCTL0030: No resource definition is registered for address [
> ("subsystem" => "[undertow,logging]"),
> ("server" => "*")
> ]"
> {code}
> This does though, finding the subsystem=undertow registration:
> {code}
> /subsystem=*/server=*:read-resource-description
> {code}
> The read-resource op works for segmented multi-target requests as GlobalOperationHandlers.ModelAddressResolver has specific logic for it in executeMultiTargetChildren. GlobalOperationHandlers.RegistrationAddressResolver does not.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months