[JBoss JIRA] (WFLY-7210) Expose JAX-RS resources as children of the subsystem
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7210?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-7210:
------------------------------------
Assignee: Lin Gao (was: Stuart Douglas)
> Expose JAX-RS resources as children of the subsystem
> ----------------------------------------------------
>
> Key: WFLY-7210
> URL: https://issues.jboss.org/browse/WFLY-7210
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Affects Versions: 10.1.0.Final
> Reporter: Guillermo González de Agüero
> Assignee: Lin Gao
> Attachments: hal-jaxrs.png
>
>
> Servlets, EJBs, WebSockets, JPA, etc expose its components as children of the subsystem in the management API. For example to list the stateless EJBs of a deployment:
> [standalone@localhost:9990 /] /deployment=cdivsejb.war/subsystem=ejb3:read-children-resources(child-type=stateless-session-bean)
> This makes it specially easy to navigate trough the web console (attached screenshot).
> To read JAX-RS resources, the command would be:
> [standalone@localhost:9990 /] /deployment=cdivsejb.war/subsystem=jaxrs:show-resources()
> I propose to make deprecate the show-resources operation and create a new "resources" child, containing the Rest resources.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFCORE-1868) wrong parse of double quote in `\\"`
by Hisanobu Okuda (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugi... ]
Hisanobu Okuda commented on WFCORE-1868:
----------------------------------------
As I mentioned in my PR comment,
---
@jfdenise I confirmed the issue is not reproduced in wildfly-core 3.0.0.x of https://github.com/jfdenise/wildfly-core/tree/WFCORE-1878. However, I'd like to merge this, because:
* EAP7.0.x is still based on wildfly-core 2.0.x and not guaranteed to move to wildfly-core 3.0.
* this fix is good for other aesh application.
* this is harmless to wildfly-core 3.0.
> wrong parse of double quote in `\\"`
> -------------------------------------
>
> Key: WFCORE-1868
> URL: https://issues.jboss.org/browse/WFCORE-1868
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Environment: JBoss EAP 7.0.0
> Reporter: Hisanobu Okuda
> Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone@localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> >
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFCORE-1868) wrong parse of double quote in `\\"`
by Hisanobu Okuda (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugi... ]
Hisanobu Okuda updated WFCORE-1868:
-----------------------------------
Steps to Reproduce: Run cli command {code}/system-property=foo4:add(value="vvv\\"){code} in jboss-cli. (was: Run cli command `/system-property=foo4:add(value="vvv\\")` in jboss-cli.)
> wrong parse of double quote in `\\"`
> -------------------------------------
>
> Key: WFCORE-1868
> URL: https://issues.jboss.org/browse/WFCORE-1868
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Environment: JBoss EAP 7.0.0
> Reporter: Hisanobu Okuda
> Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone@localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> >
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFCORE-1886) Adding ldap-realm in Elytron sometimes register capability even if add operation failed
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1886?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1886:
------------------------------------------
I think https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO... is probably the solution to this.
I don't think the reproducer steps work any more though. I don't see why that op would even get to the point of registering a capability since the attribute validation should fail before then.
In any case the fix for this needs a multi-threaded reproducer test in CapabilityRegistryTestCase.
> Adding ldap-realm in Elytron sometimes register capability even if add operation failed
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-1886
> URL: https://issues.jboss.org/browse/WFCORE-1886
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Reporter: Ondrej Lukas
> Assignee: Brian Stansberry
> Priority: Critical
>
> In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.
> I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.
> Exception in server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("ldap-realm" => "ldap")
> ]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.security-realm.ldap' is already registered in context 'global'.
> at org.jboss.as.controller.CapabilityRegistry.registerCapability(CapabilityRegistry.java:158)
> at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1449)
> at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1441)
> at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:274)
> at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 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 message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7364) java.lang.IllegalArgumentException: UT000068: Servlet path match failed
by william teskey (JIRA)
[ https://issues.jboss.org/browse/WFLY-7364?page=com.atlassian.jira.plugin.... ]
william teskey updated WFLY-7364:
---------------------------------
Description:
[0m[31m16:24:45,861 ERROR [io.undertow.request] (default I/O-6) UT005071: Undertow request failed HttpServerExchange{ GET china2000fineart.com request {Accept=[*/*], User-Agent=[Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36], Referer=[http://china2000fineart.com], Host=[china2000fineart.com]} response {}}: java.lang.IllegalArgumentException: UT000068: Servlet path match failed
at io.undertow.servlet.handlers.ServletPathMatchesData.getServletHandlerByPath(ServletPathMatchesData.java:83)
at io.undertow.servlet.handlers.ServletPathMatches.getServletHandlerByPath(ServletPathMatches.java:83)
at io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:151)
at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:39)
at io.undertow.server.handlers.HttpContinueReadHandler.handleRequest(HttpContinueReadHandler.java:65)
at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:94)
at org.wildfly.extension.undertow.Host$OptionsHandler.handleRequest(Host.java:295)
at io.undertow.server.handlers.HttpContinueReadHandler.handleRequest(HttpContinueReadHandler.java:65)
at org.wildfly.extension.undertow.Host$HostRootHandler.handleRequest(Host.java:303)
at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:54)
at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78)
at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:128)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
> java.lang.IllegalArgumentException: UT000068: Servlet path match failed
> -----------------------------------------------------------------------
>
> Key: WFLY-7364
> URL: https://issues.jboss.org/browse/WFLY-7364
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.1.0.Final
> Reporter: william teskey
> Assignee: Jason Greene
> Priority: Minor
>
> [0m[31m16:24:45,861 ERROR [io.undertow.request] (default I/O-6) UT005071: Undertow request failed HttpServerExchange{ GET china2000fineart.com request {Accept=[*/*], User-Agent=[Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36], Referer=[http://china2000fineart.com], Host=[china2000fineart.com]} response {}}: java.lang.IllegalArgumentException: UT000068: Servlet path match failed
> at io.undertow.servlet.handlers.ServletPathMatchesData.getServletHandlerByPath(ServletPathMatchesData.java:83)
> at io.undertow.servlet.handlers.ServletPathMatches.getServletHandlerByPath(ServletPathMatches.java:83)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:151)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:39)
> at io.undertow.server.handlers.HttpContinueReadHandler.handleRequest(HttpContinueReadHandler.java:65)
> at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:94)
> at org.wildfly.extension.undertow.Host$OptionsHandler.handleRequest(Host.java:295)
> at io.undertow.server.handlers.HttpContinueReadHandler.handleRequest(HttpContinueReadHandler.java:65)
> at org.wildfly.extension.undertow.Host$HostRootHandler.handleRequest(Host.java:303)
> at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:54)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78)
> at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
> at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:128)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFCORE-1836) Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1836?page=com.atlassian.jira.plugi... ]
Radoslav Husar resolved WFCORE-1836.
------------------------------------
Resolution: Rejected
We can use chained config for this use case, opened WFLY-7362 to reenable the test case.
> Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
> ----------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1836
> URL: https://issues.jboss.org/browse/WFCORE-1836
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Reporter: Paul Ferraro
> Assignee: Brian Stansberry
>
> For rejection-style transformer tests, the subsystem test framework stores expected rejected operations in a map keyed by PathAddress. This is fine when the subsystem's parser only generates add operations. However, if the parser generates an add operation as well as a a write-attribute operation, these 2 operations will have the same path address. If we expect one of these operations to be rejected, but not the other, we end up with an unexpected rejection - and the test fails.
> This is a little hard to explain in the abstract, so let me know if any of the above doesn't make sense.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFCORE-1886) Adding ldap-realm in Elytron sometimes register capability even if add operation failed
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1886?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1886:
------------------------------------------
[~ctomc] This sounds like the thing [~ehugonnet] was talking about on HipChat a few days ago, where he observed the deployment scanner background task triggering incorrect publication of capability changes. I figure the reason the delay is important in the reproducer steps above is because the scanner runs during that time.
Did you guys figure out anything about this?
> Adding ldap-realm in Elytron sometimes register capability even if add operation failed
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-1886
> URL: https://issues.jboss.org/browse/WFCORE-1886
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Reporter: Ondrej Lukas
> Assignee: Brian Stansberry
> Priority: Critical
>
> In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.
> I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.
> Exception in server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("ldap-realm" => "ldap")
> ]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.security-realm.ldap' is already registered in context 'global'.
> at org.jboss.as.controller.CapabilityRegistry.registerCapability(CapabilityRegistry.java:158)
> at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1449)
> at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1441)
> at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:274)
> at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 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 message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months