May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2741) ManagedServerOperationsFactory is not propagating the 'module' attribute to the servers

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2741?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-2741: ------------------------------------------------- Radovan STANCEL <rstancel(a)redhat.com> changed the Status of [bug 1455588|https://bugzilla.redhat.com/show_bug.cgi?id=1455588] from POST to MODIFIED > ManagedServerOperationsFactory is not propagating the 'module' attribute to the servers > --------------------------------------------------------------------------------------- > > Key: WFCORE-2741 > URL: https://issues.jboss.org/browse/WFCORE-2741 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Yeray Borges > Priority: Critical > Fix For: 3.0.0.Beta22 > > > In a managed domain if you configure a vault with the 'module' attribute set, when the HC launches a server that attribute value is not passed to the server in the relevant operation in the boot operation list. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2890) OperationContextImpl leaks to OperationContextImpl.OperationContextServiceRegistry

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-2890: ---------------------------------------- Summary: OperationContextImpl leaks to OperationContextImpl.OperationContextServiceRegistry Key: WFCORE-2890 URL: https://issues.jboss.org/browse/WFCORE-2890 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry WorkerResourceDefinition.WorkerResource is holding a ref to the OperationContextImpl.OperationContextServiceRegistry. That's not a static class so that leaks the original OperationContextImpl. Fix is to make it static and when the op is done disconnect the OC the way we do with OperationContextImpl.ContextServiceTarget. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5627) Unable to view the infinispan statistics from CLI

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-5627?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-5627: ------------------------------------ Until https://issues.jboss.org/browse/WFLY-5685 is complete, you can only see these metrics via JMX. > Unable to view the infinispan statistics from CLI > ------------------------------------------------- > > Key: WFLY-5627 > URL: https://issues.jboss.org/browse/WFLY-5627 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Chao Wang > Assignee: Paul Ferraro > > When I investigated https://bugzilla.redhat.com/show_bug.cgi?id=1276441 and tested its scenario with WildFly as: > {noformat} > Steps to Reproduce: > =================== > 1) Build latest Wildfly master and consider `standalone-ha.xml` file. > 2) Enable the infinispan statistics in the standalone-ha.xml file. > Configuration looks as below: > ----- > <subsystem xmlns="urn:jboss:domain:infinispan:4.0"> > <cache-container name="server" aliases="singleton cluster" module="org.wildfly.clustering.server" default-cache="default"> > <transport lock-timeout="60000"/> > <replicated-cache name="default" mode="SYNC"> > <transaction mode="BATCH"/> > </replicated-cache> > </cache-container> > <cache-container name="web" module="org.wildfly.clustering.web.infinispan" default-cache="dist" statistics-enabled="true"> > <transport lock-timeout="60000"/> > <distributed-cache name="dist" statistics-enabled="true" mode="ASYNC" l1-lifespan="0" owners="2"> > <locking isolation="REPEATABLE_READ"/> > <transaction mode="BATCH"/> > <file-store/> > </distributed-cache> > </cache-container> > ----- > 3) Start the server with `standalone-ha.xml` file. > 4) Deploy the cluster web application and hit the application. > 5) and check the infinispan statistics by using the below cli command: > ----- > /subsystem=infinispan/cache-container=web/distributed-cache=dist:read-resource(include-runtime=true) > ----- > 6) Values for the runtime parameters(i.e.,number-of-entries, hits, etc.,) never change. > Actual results: > =============== > - Values for the runtime parameters(i.e.,number-of-entries, hits, etc.,) never changed. > Expected results: > ================= > - There should be a change in the runtime parameters values. > Additional info: > ================= > - I can see the expected result from the jconsole statistics. > jconsole -> mbean tab -> jboss.infinispan -> Cache -> $application -> web -> Statistics. > {noformat} > It actually works fine with 10.0.0.CR4, but it breaks in latest master. It seems commit https://github.com/wildfly/wildfly/commit/79b49a3b930fd5c7cc29e9fe1c9a747... makes such difference. Once I revert this commit, I can see dynamic statistics change in CLI operation. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5627) Unable to view the infinispan statistics from CLI

by PEANO LUCA (JIRA)

[ https://issues.jboss.org/browse/WFLY-5627?page=com.atlassian.jira.plugin.... ] PEANO LUCA commented on WFLY-5627: ---------------------------------- sorry but how i can get replicated web cache metrics via jboss cli? > Unable to view the infinispan statistics from CLI > ------------------------------------------------- > > Key: WFLY-5627 > URL: https://issues.jboss.org/browse/WFLY-5627 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Chao Wang > Assignee: Paul Ferraro > > When I investigated https://bugzilla.redhat.com/show_bug.cgi?id=1276441 and tested its scenario with WildFly as: > {noformat} > Steps to Reproduce: > =================== > 1) Build latest Wildfly master and consider `standalone-ha.xml` file. > 2) Enable the infinispan statistics in the standalone-ha.xml file. > Configuration looks as below: > ----- > <subsystem xmlns="urn:jboss:domain:infinispan:4.0"> > <cache-container name="server" aliases="singleton cluster" module="org.wildfly.clustering.server" default-cache="default"> > <transport lock-timeout="60000"/> > <replicated-cache name="default" mode="SYNC"> > <transaction mode="BATCH"/> > </replicated-cache> > </cache-container> > <cache-container name="web" module="org.wildfly.clustering.web.infinispan" default-cache="dist" statistics-enabled="true"> > <transport lock-timeout="60000"/> > <distributed-cache name="dist" statistics-enabled="true" mode="ASYNC" l1-lifespan="0" owners="2"> > <locking isolation="REPEATABLE_READ"/> > <transaction mode="BATCH"/> > <file-store/> > </distributed-cache> > </cache-container> > ----- > 3) Start the server with `standalone-ha.xml` file. > 4) Deploy the cluster web application and hit the application. > 5) and check the infinispan statistics by using the below cli command: > ----- > /subsystem=infinispan/cache-container=web/distributed-cache=dist:read-resource(include-runtime=true) > ----- > 6) Values for the runtime parameters(i.e.,number-of-entries, hits, etc.,) never change. > Actual results: > =============== > - Values for the runtime parameters(i.e.,number-of-entries, hits, etc.,) never changed. > Expected results: > ================= > - There should be a change in the runtime parameters values. > Additional info: > ================= > - I can see the expected result from the jconsole statistics. > jconsole -> mbean tab -> jboss.infinispan -> Cache -> $application -> web -> Statistics. > {noformat} > It actually works fine with 10.0.0.CR4, but it breaks in latest master. It seems commit https://github.com/wildfly/wildfly/commit/79b49a3b930fd5c7cc29e9fe1c9a747... makes such difference. Once I revert this commit, I can see dynamic statistics change in CLI operation. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1550) wildfly-init-redhat.sh script does not work on RHEL 5 OS

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1550?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1550: ------------------------------------------------- Radovan STANCEL <rstancel(a)redhat.com> changed the Status of [bug 1328146|https://bugzilla.redhat.com/show_bug.cgi?id=1328146] from POST to MODIFIED > wildfly-init-redhat.sh script does not work on RHEL 5 OS > -------------------------------------------------------- > > Key: WFCORE-1550 > URL: https://issues.jboss.org/browse/WFCORE-1550 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 2.2.0.CR2 > Reporter: Vlado Pakan > Assignee: Vlado Pakan > Fix For: 3.0.0.Alpha2 > > > Wildfly start-up script $JBOSS_HOME/docs/contrib/scripts/init.d/wildfly-init-redhat.sh tries to get successful start timestamp using following command: > grep -o '[0-9]*' $JBOSS_MARKERFILE > This however does not work on RHEL 5 OS, as grep-2.5.1 does not return regular expression result correctly when used with -o option. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5627) Unable to view the infinispan statistics from CLI

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-5627?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-5627: ------------------------------------ [~lpeano] The routing information is stored in a cache instance per server (i.e. undertow "server"), named using the name of that server (e.g. <server name="default-server">...</server>. I'm not sure why statistics from this cache would be of any interest. > Unable to view the infinispan statistics from CLI > ------------------------------------------------- > > Key: WFLY-5627 > URL: https://issues.jboss.org/browse/WFLY-5627 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Chao Wang > Assignee: Paul Ferraro > > When I investigated https://bugzilla.redhat.com/show_bug.cgi?id=1276441 and tested its scenario with WildFly as: > {noformat} > Steps to Reproduce: > =================== > 1) Build latest Wildfly master and consider `standalone-ha.xml` file. > 2) Enable the infinispan statistics in the standalone-ha.xml file. > Configuration looks as below: > ----- > <subsystem xmlns="urn:jboss:domain:infinispan:4.0"> > <cache-container name="server" aliases="singleton cluster" module="org.wildfly.clustering.server" default-cache="default"> > <transport lock-timeout="60000"/> > <replicated-cache name="default" mode="SYNC"> > <transaction mode="BATCH"/> > </replicated-cache> > </cache-container> > <cache-container name="web" module="org.wildfly.clustering.web.infinispan" default-cache="dist" statistics-enabled="true"> > <transport lock-timeout="60000"/> > <distributed-cache name="dist" statistics-enabled="true" mode="ASYNC" l1-lifespan="0" owners="2"> > <locking isolation="REPEATABLE_READ"/> > <transaction mode="BATCH"/> > <file-store/> > </distributed-cache> > </cache-container> > ----- > 3) Start the server with `standalone-ha.xml` file. > 4) Deploy the cluster web application and hit the application. > 5) and check the infinispan statistics by using the below cli command: > ----- > /subsystem=infinispan/cache-container=web/distributed-cache=dist:read-resource(include-runtime=true) > ----- > 6) Values for the runtime parameters(i.e.,number-of-entries, hits, etc.,) never change. > Actual results: > =============== > - Values for the runtime parameters(i.e.,number-of-entries, hits, etc.,) never changed. > Expected results: > ================= > - There should be a change in the runtime parameters values. > Additional info: > ================= > - I can see the expected result from the jconsole statistics. > jconsole -> mbean tab -> jboss.infinispan -> Cache -> $application -> web -> Statistics. > {noformat} > It actually works fine with 10.0.0.CR4, but it breaks in latest master. It seems commit https://github.com/wildfly/wildfly/commit/79b49a3b930fd5c7cc29e9fe1c9a747... makes such difference. Once I revert this commit, I can see dynamic statistics change in CLI operation. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1198) AuthenticationConfiguration ACC changes

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-1198?page=com.atlassian.jira.plugin.s... ] David Lloyd commented on ELY-1198: ---------------------------------- Like ELY-1212, this issue relates to locking in dynamic behavior on an AuthenticationConfiguration so that subsequent usages are stable. > AuthenticationConfiguration ACC changes > --------------------------------------- > > Key: ELY-1198 > URL: https://issues.jboss.org/browse/ELY-1198 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Reporter: David Lloyd > Assignee: David Lloyd > > The ACC should be captured dynamically if not given, and established to the auth config. The ACC should not figure into equals/hashCode decisions. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1212) The forward identity should be captured in AuthenticationContextConfigurationClient.getAuthenticationConfiguration()

by David Lloyd (JIRA)

David Lloyd created ELY-1212: -------------------------------- Summary: The forward identity should be captured in AuthenticationContextConfigurationClient.getAuthenticationConfiguration() Key: ELY-1212 URL: https://issues.jboss.org/browse/ELY-1212 Project: WildFly Elytron Issue Type: Bug Components: Authentication Client Reporter: David Lloyd Fix For: 2.0.0.Alpha1 When there is a forwarded identity (from a configured security domain for example), the principal and credential set should be captured when the AuthenticationConfiguration is captured by the client. This will allow the identity to flow across threads without mixing up connection sharing considerations. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-680) No log messages comming from Elytron - kerberos

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-680?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-680: -------------------------------- Improved in second PR. > No log messages comming from Elytron - kerberos > ----------------------------------------------- > > Key: ELY-680 > URL: https://issues.jboss.org/browse/ELY-680 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > > Elytron is missing log messages related to kerberos authentication. These log messages should be added. See JBEAP-6041 for more details. > I consider to be useful to have TRACE log messages at least in: > - SpnegoAuthenticationMechanism > - GSSCredentialSecurityFactory > If there are more classes involved in kerberos authnetication include them as well. > Kerberos issues are very specific. So it is very important to have as much trace information as possible. Therefore raising priority to Critical. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2160) Incorrect JBOSS_HOME warning in vault.sh

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2160?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-2160: ------------------------------------------------- Radovan STANCEL <rstancel(a)redhat.com> changed the Status of [bug 1410924|https://bugzilla.redhat.com/show_bug.cgi?id=1410924] from POST to MODIFIED > Incorrect JBOSS_HOME warning in vault.sh > ---------------------------------------- > > Key: WFCORE-2160 > URL: https://issues.jboss.org/browse/WFCORE-2160 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 3.0.0.Alpha16 > Reporter: Dennis Reed > Assignee: Romain Pelisse > Priority: Minor > Fix For: 3.0.0.Alpha23 > > > vault.sh has an incorrect check to make sure JBOSS_HOME is set correctly. > SANITIZED_JBOSS_HOME=`cd "$JBOSS_HOME/.."; pwd` > if [ "$RESOLVED_JBOSS" != "$SANITIZED_JBOSS_HOME" ]; then > The check will always fail because of the incorrect "/..", which should be removed. > The incorrect value is only used for printing the "WARNING JBOSS_HOME may be pointing to a different installation - unpredictable results may occur." log, and appears to have been around since at least EAP 6.0. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2017