January 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1939) Tabulator in CLI could suggest actual values for attributes for operations

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1939?page=com.atlassian.jira.plugi... ] Jean-Francois Denise reassigned WFCORE-1939: -------------------------------------------- Assignee: Jean-Francois Denise > Tabulator in CLI could suggest actual values for attributes for operations > -------------------------------------------------------------------------- > > Key: WFCORE-1939 > URL: https://issues.jboss.org/browse/WFCORE-1939 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI, Domain Management > Reporter: Miroslav Novak > Assignee: Jean-Francois Denise > Labels: user_experience > > There are number of cases where is necessary to execute CLI operation to actually get value for attribute to another CLI operation. For example I want to list all messages for subscription on the topic then it's necessary to get names of all subscriptions by: > {code} > [standalone@172.16.10.17:9990 /] /subsystem=messaging-activemq/server=default/jms-topic=HQ_ProductFamilyT23:list-all-subscriptions > { > "outcome" => "success", > "result" => [ > { > "durable" => true, > "queueName" => "172\\.16\\.10\\.15_VM1_SPAgent55_0.SP_CallForOffersEH_55_EHID_1PF4", > "clientID" => "172.16.10.15_VM1_SPAgent55_0", > "messageCount" => 0, > "deliveringCount" => 0, > "name" => "SP_CallForOffersEH_55_EHID_1PF4", > "consumers" => [{ > "creationTime" => 1478261489444L, > "consumerID" => 4, > "browseOnly" => false, > "connectionID" => "-1638816479", > "sessionID" => "d1149360-a287-11e6-bb34-97e27f67b29e" > }] > }, > { > "durable" => true, > "queueName" => "172\\.16\\.10\\.18_VM1_SPAgent23_0.SP_CallForOffersEH_23_EHID_1PF0", > "clientID" => "172.16.10.18_VM1_SPAgent23_0", > "messageCount" => 0, > "deliveringCount" => 0, > "name" => "SP_CallForOffersEH_23_EHID_1PF0", > "consumers" => [{ > "creationTime" => 1478261516648L, > "consumerID" => 0, > "browseOnly" => false, > "connectionID" => "-1794279882", > "sessionID" => "e14e5343-a287-11e6-9311-4d8e66b2ef14" > }] > } > ] > } > {code} > > so name of subscription {{SP_CallForOffersEH_55_EHID_1PF4}} could be used in: {code} > [standalone@172.16.10.17:9990 /] /subsystem=messaging-activemq/server=default/jms-topic=HQ_ProductFamilyT23:list-messages-for-subscription(queue-name=SP_CallForOffersEH_55_EHID_1PF4){code} > The improvement would allow to just press tab in: {code} > [standalone@172.16.10.17:9990 /] /subsystem=messaging-activemq/server=default/jms-topic=HQ_ProductFamilyT23:list-messages-for-subscription(queue-name=... <-- tab here would suggest which queues are available {code} > and it would suggest queue names of available subscriptions. > There are more places like this - for example : > {code} > /subsystem=messaging-activemq/server=default:rollback-prepared-transaction(transaction-as-base-64=... <-- tab here > {code} > would provide available prepared transactions which can be commit. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1679) jconsole wildfly cli tab plugin not reacting to connect/disconnect button

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1679?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-1679: ---------------------------------------------- The Console plugin has not been updated when the connection/disconnection feature has been added to Console. The ModelControllerClient must be rebuilt when connection is reconnected. > jconsole wildfly cli tab plugin not reacting to connect/disconnect button > ------------------------------------------------------------------------- > > Key: WFCORE-1679 > URL: https://issues.jboss.org/browse/WFCORE-1679 > Project: WildFly Core > Issue Type: Bug > Components: CLI, JMX > Reporter: Enrique González Martínez > Assignee: Jean-Francois Denise > > The current plugin does not reac to the connect/dissconnect button. causing an error in the next use case: > 1) loing > 2) show the jconsole tb > 3) disconnect jconsole > 4) connect jconsole again > try to execute anything jconsole tab plugin -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1679) jconsole wildfly cli tab plugin not reacting to connect/disconnect button

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1679?page=com.atlassian.jira.plugi... ] Jean-Francois Denise reassigned WFCORE-1679: -------------------------------------------- Assignee: Jean-Francois Denise > jconsole wildfly cli tab plugin not reacting to connect/disconnect button > ------------------------------------------------------------------------- > > Key: WFCORE-1679 > URL: https://issues.jboss.org/browse/WFCORE-1679 > Project: WildFly Core > Issue Type: Bug > Components: CLI, JMX > Reporter: Enrique González Martínez > Assignee: Jean-Francois Denise > > The current plugin does not reac to the connect/dissconnect button. causing an error in the next use case: > 1) loing > 2) show the jconsole tb > 3) disconnect jconsole > 4) connect jconsole again > try to execute anything jconsole tab plugin -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2179) When in SUSPENDED state we shouldn't suspend on stopping

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2179?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet updated WFCORE-2179: -------------------------------------- Summary: When in SUSPENDED state we shouldn't suspend on stopping (was: When in USPENDED state we shouldn't suspend on stopping) > When in SUSPENDED state we shouldn't suspend on stopping > -------------------------------------------------------- > > Key: WFCORE-2179 > URL: https://issues.jboss.org/browse/WFCORE-2179 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha16 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > > If you start in suspended mode and reload the server, it will suspend even if we are already suspended. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2179) When in USPENDED state we shouldn't suspend on stopping

by ehsavoie Hugonnet (JIRA)

ehsavoie Hugonnet created WFCORE-2179: ----------------------------------------- Summary: When in USPENDED state we shouldn't suspend on stopping Key: WFCORE-2179 URL: https://issues.jboss.org/browse/WFCORE-2179 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 3.0.0.Alpha16 Reporter: ehsavoie Hugonnet Assignee: ehsavoie Hugonnet If you start in suspended mode and reload the server, it will suspend even if we are already suspended. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7875) Elytron, IBM java, SPNEGO continuation required situation

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7875?page=com.atlassian.jira.plugin.... ] Martin Choma updated WFLY-7875: ------------------------------- Priority: Blocker (was: Critical) > Elytron, IBM java, SPNEGO continuation required situation > --------------------------------------------------------- > > Key: WFLY-7875 > URL: https://issues.jboss.org/browse/WFLY-7875 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Attachments: ContinuationRequiredIBM.pcap, server.log > > > I have problem to achieve this scenario with elytron on IBM java: > # Using IBM Java > # Client sends non kerberos OID mechanism as most preferred with non kerberos ticket > # Server response with "continuation required" > # Client sends kerberos ticket > # Server response with 401 instead of 200 > # In server there is error > {code} > 10:43:35,570 TRACE [org.wildfly.security] (default task-3) GSSContext message exchange failed: org.ietf.jgss.GSSException, major code: 10, minor code: 0 > major string: Defective token > minor string: Bad token tag: -95 > at com.ibm.security.jgss.i18n.I18NException.throwGSSException(I18NException.java:5) > at com.ibm.security.jgss.TokenHeader.a(TokenHeader.java:33) > at com.ibm.security.jgss.TokenHeader.a(TokenHeader.java:102) > at com.ibm.security.jgss.TokenHeader.<init>(TokenHeader.java:70) > at com.ibm.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:119) > at com.ibm.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:186) > at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.evaluateRequest(SpnegoAuthenticationMechanism.java:138) > at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90) > at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74) > at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82) > {code} > Basically, it is same scenario as tested in [1] (for legacy security). > This scenario works correctly > * on Oracle and OpenJDK java with elytron in EAP 7.1 > * with legacy security on IBM java in EAP 7.1 > Setting high priority as: > * It works in legacy security, so customers won't be able to migrate > * Similar error was resolved in EAP 7.0 (JBEAP-3709) as blocker because customer case existed for that. > [1] https://github.com/wildfly/wildfly/blob/15f9a4f2b5a10cc3acbaa2df57d5cc13d... > [2] https://github.com/wildfly/wildfly/blob/15f9a4f2b5a10cc3acbaa2df57d5cc13d... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-850) Elytron ldap-realm allows access with empty password

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-850?page=com.atlassian.jira.plugin.sy... ] Jan Kalina updated ELY-850: --------------------------- Fix Version/s: 1.1.0.Beta19 > Elytron ldap-realm allows access with empty password > ---------------------------------------------------- > > Key: ELY-850 > URL: https://issues.jboss.org/browse/ELY-850 > Project: WildFly Elytron > Issue Type: Bug > Components: Realms > Affects Versions: 1.1.0.Beta17 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > Fix For: 1.1.0.Beta19 > > > An empty password is treated as an anonymous login by some LDAP servers (e.g. by Microsoft Active Directory). In case when Elytron ldap-realm is configured for that type of LDAP server then access with empty password to secured web resource guarded by that ldap-realm is always granted. > There should be some attribute for configuring whether empty password should be accepted by ldap-realm. > Similar issue occurs in previous versions of application server, see: > * https://bugzilla.redhat.com/show_bug.cgi?id=901251 > * https://bugzilla.redhat.com/show_bug.cgi?id=885569 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7875) Elytron, IBM java, SPNEGO continuation required situation

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7875?page=com.atlassian.jira.plugin.... ] Martin Choma moved JBEAP-8209 to WFLY-7875: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7875 (was: JBEAP-8209) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.DR10) > Elytron, IBM java, SPNEGO continuation required situation > --------------------------------------------------------- > > Key: WFLY-7875 > URL: https://issues.jboss.org/browse/WFLY-7875 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Attachments: ContinuationRequiredIBM.pcap, server.log > > > I have problem to achieve this scenario with elytron on IBM java: > # Using IBM Java > # Client sends non kerberos OID mechanism as most preferred with non kerberos ticket > # Server response with "continuation required" > # Client sends kerberos ticket > # Server response with 401 instead of 200 > # In server there is error > {code} > 10:43:35,570 TRACE [org.wildfly.security] (default task-3) GSSContext message exchange failed: org.ietf.jgss.GSSException, major code: 10, minor code: 0 > major string: Defective token > minor string: Bad token tag: -95 > at com.ibm.security.jgss.i18n.I18NException.throwGSSException(I18NException.java:5) > at com.ibm.security.jgss.TokenHeader.a(TokenHeader.java:33) > at com.ibm.security.jgss.TokenHeader.a(TokenHeader.java:102) > at com.ibm.security.jgss.TokenHeader.<init>(TokenHeader.java:70) > at com.ibm.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:119) > at com.ibm.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:186) > at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.evaluateRequest(SpnegoAuthenticationMechanism.java:138) > at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90) > at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74) > at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82) > {code} > Basically, it is same scenario as tested in [1] (for legacy security). > This scenario works correctly > * on Oracle and OpenJDK java with elytron in EAP 7.1 > * with legacy security on IBM java in EAP 7.1 > Setting high priority as: > * It works in legacy security, so customers won't be able to migrate > * Similar error was resolved in EAP 7.0 (JBEAP-3709) as blocker because customer case existed for that. > [1] https://github.com/wildfly/wildfly/blob/15f9a4f2b5a10cc3acbaa2df57d5cc13d... > [2] https://github.com/wildfly/wildfly/blob/15f9a4f2b5a10cc3acbaa2df57d5cc13d... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7871) Decouple backup/site name from the name of the corresponding resource

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/WFLY-7871?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on WFLY-7871: ---------------------------------------- I was wondering whether, to be consistent we could name backup's {{site}} as {{site-name}}. Since normally backup site-name and remote-site site-name would be the same. E.g. {code} <backups> <backup name="remote" site-name="${...}" strategy="SYNC"/> </backups> <relay site="local"> <remote-site name="local" site-name="${...}" channel=".."/> <remote-site name="remote" site-name="${...}" channel=".."/> </relay> {code} WDYT? > Decouple backup/site name from the name of the corresponding resource > --------------------------------------------------------------------- > > Key: WFLY-7871 > URL: https://issues.jboss.org/browse/WFLY-7871 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Beta1 > > > Currently, the site names defined in the JGroups subsystem RELAY2 protocol, and the backup names defined in the Infinispan subsystem do not allow expressions, since these name are used for the corresponding resource paths. To simplify the use of cross-site replication (specifically, to allow each site to use an identical domain.xml/standalone.xml), we can support expressions if we decouple the site name from the resource name. > e.g. > {noformat} > <backups> > <backup name="remote" site="${...}" strategy="SYNC"/> > </backups> > <relay site="local"> > <remote-site name="local" site-name="${...}" channel=".."/> > <remote-site name="remote" site-name="${...}" channel=".."/> > </relay> > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4168) jdr.sh CommandLineMain does not run jdr on the application server

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4168?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4168: ----------------------------------------------- Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 1195507|https://bugzilla.redhat.com/show_bug.cgi?id=1195507] from ON_QA to VERIFIED > jdr.sh CommandLineMain does not run jdr on the application server > ----------------------------------------------------------------- > > Key: WFLY-4168 > URL: https://issues.jboss.org/browse/WFLY-4168 > Project: WildFly > Issue Type: Bug > Components: JDR > Affects Versions: 9.0.0.Alpha1 > Reporter: Brad Maxwell > Assignee: Brad Maxwell > Fix For: 9.0.0.Beta1 > > > jdr.sh CommandLineMain does not run jdr on the application server > JDR run via the CLI / Managemenet API - runs the JDR report in the Application Server's JVM > /subsystem=jdr:generate-jdr-report() > Running jdr.sh / jdr.bat runs the JDR report in the JDR JVM > jdr.sh / jdr.bat should run the JDR report in the Application Server's JVM if it is running. If it is not running, then it should just collect the files that are available. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2017