[JBoss JIRA] (WFLY-7210) Expose JAX-RS resources as children of the subsystem
by Harald Pehl (JIRA)
[ https://issues.jboss.org/browse/WFLY-7210?page=com.atlassian.jira.plugin.... ]
Harald Pehl commented on WFLY-7210:
-----------------------------------
Looks good to me. Reading the current layout is no problem for the console.
Just a quick question: In the example there's a nested {{"sub-resource-locators" => undefined}} under the top-level {{"sub-resource-locators"}}. Is that just a copy-paste error or is this a valid use case?
> 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: after-wfly7024.png, 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
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (WFLY-7623) Multiple CredentialStores with ONE backed credential store file can rewrite values each other.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7623?page=com.atlassian.jira.plugin.... ]
Hynek Švábek reassigned WFLY-7623:
----------------------------------
Assignee: Peter Skopek (was: Darran Lofthouse)
> Multiple CredentialStores with ONE backed credential store file can rewrite values each other.
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-7623
> URL: https://issues.jboss.org/browse/WFLY-7623
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
>
> Multiple CredentialStores with ONE backed credential store file can rewrite values each other.
> *How to reproduce*
> {code}
> /subsystem=elytron/credential-store=credStore001:add(uri="cr-store://test/cs001.jceks?store.password=pass123;create.storage=true")
> /subsystem=elytron/credential-store=credStore001/alias="alias1":add(secret-value=Elytron)
> {code}
> {code}
> /subsystem=elytron/credential-store=credStore002:add(uri="cr-store://test/cs001.jceks?store.password=pass123")
> {code}
> check CS file
> there is "alias1" entry
> {code}
> /subsystem=elytron/credential-store=credStore001/alias="alias2":add(secret-value=Elytron)
> {code}
> check CS file
> there are "alias1" and "alias2" entries
> {code}
> /subsystem=elytron/credential-store=credStore002/alias="alias123":add(secret-value=Elytron)
> {code}
> check CS file
> there are "alias1" and "alias123" entries".
> *NOTE*
> It is problem, because we have one backed file. In memory we have right values for all Credential Stores, but after restart we can lost new entries.
> In my opinion reason for this behaviour is:
> We have CS loaded in memory and when we add new alias to CS then we save whole CS from memory to file.
> We can set CS as non-modifiable when we use same backed file for CredentialStore but we must find better default behaviour.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (WFLY-7623) Multiple CredentialStores with ONE backed credential store file can rewrite values each other.
by Hynek Švábek (JIRA)
Hynek Švábek created WFLY-7623:
----------------------------------
Summary: Multiple CredentialStores with ONE backed credential store file can rewrite values each other.
Key: WFLY-7623
URL: https://issues.jboss.org/browse/WFLY-7623
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Hynek Švábek
Assignee: Darran Lofthouse
Multiple CredentialStores with ONE backed credential store file can rewrite values each other.
*How to reproduce*
{code}
/subsystem=elytron/credential-store=credStore001:add(uri="cr-store://test/cs001.jceks?store.password=pass123;create.storage=true")
/subsystem=elytron/credential-store=credStore001/alias="alias1":add(secret-value=Elytron)
{code}
{code}
/subsystem=elytron/credential-store=credStore002:add(uri="cr-store://test/cs001.jceks?store.password=pass123")
{code}
check CS file
there is "alias1" entry
{code}
/subsystem=elytron/credential-store=credStore001/alias="alias2":add(secret-value=Elytron)
{code}
check CS file
there are "alias1" and "alias2" entries
{code}
/subsystem=elytron/credential-store=credStore002/alias="alias123":add(secret-value=Elytron)
{code}
check CS file
there are "alias1" and "alias123" entries".
*NOTE*
It is problem, because we have one backed file. In memory we have right values for all Credential Stores, but after restart we can lost new entries.
In my opinion reason for this behaviour is:
We have CS loaded in memory and when we add new alias to CS then we save whole CS from memory to file.
We can set CS as non-modifiable when we use same backed file for CredentialStore but we must find better default behaviour.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (WFCORE-1902) Error messages from CLI batch should be more informative
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1902?page=com.atlassian.jira.plugi... ]
Marek Kopecký commented on WFCORE-1902:
---------------------------------------
I agree with solution introduced in https://github.com/wildfly/wildfly-core/pull/1948
I did some tests:
{noformat}
:read-attribute(name=nonsence)
----------------------
WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:
Step: step-3
Operation: /:read-attribute(name=nonsence)
Failure: WFLYCTL0201: Unknown attribute 'nonsence'
===================================
subsystem=jmx:read-attribute(name=show-model2)
----------------------
WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:
Step: step-3
Operation: /subsystem=jmx:read-attribute(name=show-model2)
Failure: WFLYCTL0201: Unknown attribute 'show-model2'
===================================
/subsystem=nonsence:read-attribute(name=product-name)
----------------------
Exception for run-batch: org.jboss.as.cli.CommandFormatException: Failed to get the list of the operation properties: "WFLYCTL0030: No resource definition is registered for address [("subsystem" => "nonsence")]": Failed to get the list of the operation properties: "WFLYCTL0030: No resource definition is registered for address [("subsystem" => "nonsence")]"
{noformat}
In my point of view, this could help users with analysis of wrong CLI script. [~jdenise]: Thank you :)
> Error messages from CLI batch should be more informative
> --------------------------------------------------------
>
> Key: WFCORE-1902
> URL: https://issues.jboss.org/browse/WFCORE-1902
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI
> Affects Versions: 3.0.0.Alpha10
> Reporter: Marek Kopecký
> Assignee: Jean-Francois Denise
> Labels: user_experience
>
> *Description of problem:*
> Error messages from CLI batch should be more informative
> *Steps to Reproduce:*
> {noformat}
> cat <<EOF >a
> batch
> :read-attribute(name=product-version)
> :read-attribute(name=product-name)
> :read-attribute(name=nonsence)
> :read-attribute(name=product-name)
> run-batch
> EOF
> ./jboss-cli.sh -c --file=a
> {noformat}
> *Actual results:*
> {noformat}
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-3" => "WFLYCTL0201: Unknown attribute 'nonsence'"}}
> {noformat}
> *Expected results:*
> I can imagine content like following could be helpful for troubleshooting:
> {noformat}
> {
> "WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {
> "Operation step-3" => {
> "operation" => ":read-attribute(name=nonsence)"
> "response" => "WFLYCTL0201: Unknown attribute 'nonsence'"
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (WFLY-6703) Failover intermittently fails with WELD-000227: Bean identifier index inconsistency detected - the distributed container probably does not work with identical applications
by Övünç Sezer (JIRA)
[ https://issues.jboss.org/browse/WFLY-6703?page=com.atlassian.jira.plugin.... ]
Övünç Sezer commented on WFLY-6703:
-----------------------------------
Hi,
We had the similar issue in WildFly 10.0.0.Final. I could not understand your last comment, what should I do to overcomme the issue?
> Failover intermittently fails with WELD-000227: Bean identifier index inconsistency detected - the distributed container probably does not work with identical applications
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6703
> URL: https://issues.jboss.org/browse/WFLY-6703
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Tomas Remes
>
> {noformat}
> 13:57:41,855 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /clusterbench/session: org.jboss.weld.exceptions.IllegalStateException: WELD-000227: Bean identifier index inconsistency detected - the distributed container probably does not work with identical applications
> Expected hash: 1931672237
> Current index: BeanIdentifierIndex [hash=1185198536, indexed=13]
> 0: WELD%AbstractBuiltInBean%/content/clusterbench-ee7.ear/clusterbench-ee7-ejb.jar%HttpSession
> 1: WELD%AbstractBuiltInBean%/content/clusterbench-ee7.ear/clusterbench-ee7-web-default.war%HttpSession
> 2: WELD%AbstractBuiltInBean%/content/clusterbench-ee7.ear/clusterbench-ee7-web-granular.war%HttpSession
> 3: WELD%AbstractBuiltInBean%/content/clusterbench-ee7.ear/clusterbench-ee7-web-passivating.war%HttpSession
> 4: WELD%AbstractBuiltInBean%clusterbench-ee7.ear%HttpSession
> 5: WELD%AbstractBuiltInBean%com.sun.jsf-impl:main.additionalClasses%HttpSession
> 6: WELD%AbstractBuiltInBean%org.hibernate.validator.cdi:main.additionalClasses%HttpSession
> 7: WELD%AbstractBuiltInBean%org.jberet.jberet-core:main.additionalClasses%HttpSession
> 8: WELD%AbstractBuiltInBean%org.jboss.as.jsf:main.additionalClasses%HttpSession
> 9: WELD%AbstractBuiltInBean%org.jboss.resteasy.resteasy-cdi:main.additionalClasses%HttpSession
> 10: WELD%ManagedBean%clusterbench-ee7.ear|/content/clusterbench-ee7.ear/clusterbench-ee7-web-default.war|org.jboss.test.clusterbench.web.cdi.SessionScopedCdiSerialBean|null|false
> 11: WELD%ManagedBean%clusterbench-ee7.ear|/content/clusterbench-ee7.ear/clusterbench-ee7-web-passivating.war|org.jboss.test.clusterbench.web.cdi.SessionScopedCdiSerialBean|null|false
> 12: WELD%SessionBean%LocalStatefulSB%org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB
> at org.jboss.weld.context.http.HttpSessionContextImpl.checkBeanIdentifierIndexConsistency(HttpSessionContextImpl.java:101)
> at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:47)
> at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:23)
> at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:237)
> at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152)
> at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:245)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792)
> 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)
> 13:57:41,941 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-6,ee,node1) ISPN000094: Received new cluster view for channel server: [node1|2] (1) [node1]
> 13:57:41,942 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-6,ee,node1) ISPN000094: Received new cluster view for channel web: [node1|2] (1) [node1]
> 13:57:41,943 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-6,ee,node1) ISPN000094: Received new cluster view for channel hibernate: [node1|2] (1) [node1]
> 13:57:41,944 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-6,ee,node1) ISPN000094: Received new cluster view for channel ejb: [node1|2] (1) [node1]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (WFCORE-2013) Unable to access http management interface secured by legacy ldap realm
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2013?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-2013:
-------------------------------------
Affects Version/s: 3.0.0.Alpha12
> Unable to access http management interface secured by legacy ldap realm
> -----------------------------------------------------------------------
>
> Key: WFCORE-2013
> URL: https://issues.jboss.org/browse/WFCORE-2013
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Alpha12
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Alpha13
>
>
> When http management interface is secured with legacy security realm using ldap, user is not prompted to provide credentials as should be in case of BASIC http authentication mechanism. Instead {{403}} http status is returned directly.
> Users won't be able to migrate their current (6.4, 7.0) configuration to 7.1 without change.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (WFCORE-2013) Unable to access http management interface secured by legacy ldap realm
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2013?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-2013:
-------------------------------------
Fix Version/s: 3.0.0.Alpha13
> Unable to access http management interface secured by legacy ldap realm
> -----------------------------------------------------------------------
>
> Key: WFCORE-2013
> URL: https://issues.jboss.org/browse/WFCORE-2013
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Alpha12
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Alpha13
>
>
> When http management interface is secured with legacy security realm using ldap, user is not prompted to provide credentials as should be in case of BASIC http authentication mechanism. Instead {{403}} http status is returned directly.
> Users won't be able to migrate their current (6.4, 7.0) configuration to 7.1 without change.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (WFCORE-2013) Unable to access http management interface secured by legacy ldap realm
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2013?page=com.atlassian.jira.plugi... ]
Darran Lofthouse moved WFLY-7621 to WFCORE-2013:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-2013 (was: WFLY-7621)
Component/s: Security
(was: Security)
Affects Version/s: (was: 11.0.0.Alpha1)
> Unable to access http management interface secured by legacy ldap realm
> -----------------------------------------------------------------------
>
> Key: WFCORE-2013
> URL: https://issues.jboss.org/browse/WFCORE-2013
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Alpha13
>
>
> When http management interface is secured with legacy security realm using ldap, user is not prompted to provide credentials as should be in case of BASIC http authentication mechanism. Instead {{403}} http status is returned directly.
> Users won't be able to migrate their current (6.4, 7.0) configuration to 7.1 without change.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months