April 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-10198) Upgrade WIldFly Core to 5.0.0.Alpha3

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFLY-10198?page=com.atlassian.jira.plugin... ] Chao Wang resolved WFLY-10198. ------------------------------ Fix Version/s: 13.0.0.Beta1 Resolution: Duplicate Issue > Upgrade WIldFly Core to 5.0.0.Alpha3 > ------------------------------------ > > Key: WFLY-10198 > URL: https://issues.jboss.org/browse/WFLY-10198 > Project: WildFly > Issue Type: Component Upgrade > Reporter: David Lloyd > Assignee: Jason Greene > Fix For: 13.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10197) AuthenticationPolicyContextTestCase fails under a security manager

by Martin Stefanko (JIRA)

[ https://issues.jboss.org/browse/WFLY-10197?page=com.atlassian.jira.plugin... ] Martin Stefanko commented on WFLY-10197: ---------------------------------------- [~dmlloyd] yes > AuthenticationPolicyContextTestCase fails under a security manager > ------------------------------------------------------------------ > > Key: WFLY-10197 > URL: https://issues.jboss.org/browse/WFLY-10197 > Project: WildFly > Issue Type: Bug > Components: Test Suite, Web Services > Reporter: David Lloyd > Assignee: Martin Stefanko > > Stack trace: > {noformat} > java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.security.SecurityPermission" "getPolicy")" in code source "(vfs:/content/picketlink-sts-ws.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.picketlink-sts-ws.war" from Service Module Loader") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192) > at javax.security.jacc.PolicyContext.getContext(PolicyContext.java:99) > at org.jboss.as.test.integration.ws.authentication.policy.resources.EchoService.echo(EchoService.java:62) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) > at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:90) > at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:101) > at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) > ... 103 more > {noformat} > I think the {{EchoService}} deployment needs the {{getPolicy}} permission in order to complete its task. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2265) Jgroup MERGE3 is not merging big cluster

by lokesh raheja (JIRA)

[ https://issues.jboss.org/browse/JGRP-2265?page=com.atlassian.jira.plugin.... ] lokesh raheja updated JGRP-2265: -------------------------------- Description: Hi Bela Jgroup 3.6.13 MERGE3 is not merging the cluster: We have a cluster of 105 nodes.I see after the cluster split it merge the cluster every time. But sometimes it gets stuck and divided into two or three clusters .1 big cluster and 2 small clusters. We have to restart the node in the small cluster to join the big cluster. In the case when it doesn’t join the cluster, I noticed that the node which is not in big cluster show the coordinator(using MERGE3.dumpviews) is the one which is already in a big cluster.The strange part is if I shut down the coordinator of a small cluster, but on all the nodes of the small cluster, it shows that same coordinator which is shut down. Is some caching issue?Could you please help on the same was: Hi Bela MERGE3 is not merging the cluster: We have a cluster of 105 nodes.I see after the cluster split it merge the cluster every time. But sometimes it gets stuck and divided into two or three clusters .1 big cluster and 2 small clusters. We have to restart the node in the small cluster to join the big cluster. In the case when it doesn’t join the cluster, I noticed that the node which is not in big cluster show the coordinator(using MERGE3.dumpviews) is the one which is already in a big cluster.The strange part is if I shut down the coordinator of a small cluster, but on all the nodes of the small cluster, it shows that same coordinator which is shut down. Is some caching issue?Could you please help on the same > Jgroup MERGE3 is not merging big cluster > ---------------------------------------- > > Key: JGRP-2265 > URL: https://issues.jboss.org/browse/JGRP-2265 > Project: JGroups > Issue Type: Feature Request > Reporter: lokesh raheja > Assignee: Bela Ban > > Hi Bela > Jgroup 3.6.13 > MERGE3 is not merging the cluster: > We have a cluster of 105 nodes.I see after the cluster split it merge the cluster every time. > But sometimes it gets stuck and divided into two or three clusters .1 big cluster and 2 small clusters. > We have to restart the node in the small cluster to join the big cluster. > In the case when it doesn’t join the cluster, I noticed that the node which is not in big cluster show the coordinator(using MERGE3.dumpviews) is the one which is already in a big cluster.The strange part is if I shut down the coordinator of a small cluster, but on all the nodes of the small cluster, it shows that same coordinator which is shut down. > Is some caching issue?Could you please help on the same > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2265) Jgroup MERGE3 is not merging big cluster

by lokesh raheja (JIRA)

[ https://issues.jboss.org/browse/JGRP-2265?page=com.atlassian.jira.plugin.... ] lokesh raheja updated JGRP-2265: -------------------------------- Description: Hi Bela Jgroup 3.6.13 We have a cluster of 105 nodes.I see after the cluster split it merge the cluster every time. But sometimes it gets stuck and divided into two or three clusters .1 big cluster and 2 small clusters. We have to restart the node in the small cluster to join the big cluster. In the case when it doesn’t join the cluster, I noticed that the node which is not in big cluster show the coordinator(using MERGE3.dumpviews) is the one which is already in a big cluster.The strange part is if I shut down the coordinator of a small cluster, but on all the nodes of the small cluster, it shows that same coordinator which is shut down. Is some caching issue?Could you please help on the same was: Hi Bela Jgroup 3.6.13 MERGE3 is not merging the cluster: We have a cluster of 105 nodes.I see after the cluster split it merge the cluster every time. But sometimes it gets stuck and divided into two or three clusters .1 big cluster and 2 small clusters. We have to restart the node in the small cluster to join the big cluster. In the case when it doesn’t join the cluster, I noticed that the node which is not in big cluster show the coordinator(using MERGE3.dumpviews) is the one which is already in a big cluster.The strange part is if I shut down the coordinator of a small cluster, but on all the nodes of the small cluster, it shows that same coordinator which is shut down. Is some caching issue?Could you please help on the same > Jgroup MERGE3 is not merging big cluster > ---------------------------------------- > > Key: JGRP-2265 > URL: https://issues.jboss.org/browse/JGRP-2265 > Project: JGroups > Issue Type: Feature Request > Reporter: lokesh raheja > Assignee: Bela Ban > > Hi Bela > Jgroup 3.6.13 > We have a cluster of 105 nodes.I see after the cluster split it merge the cluster every time. > But sometimes it gets stuck and divided into two or three clusters .1 big cluster and 2 small clusters. > We have to restart the node in the small cluster to join the big cluster. > In the case when it doesn’t join the cluster, I noticed that the node which is not in big cluster show the coordinator(using MERGE3.dumpviews) is the one which is already in a big cluster.The strange part is if I shut down the coordinator of a small cluster, but on all the nodes of the small cluster, it shows that same coordinator which is shut down. > Is some caching issue?Could you please help on the same > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3566) Different results of disabling commands already disabled deployment

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3566?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3566: ------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/3166 (was: https://github.com/wildfly/wildfly-core/pull/3135, https://github.com/wildfly/wildfly-core/pull/3166) > Different results of disabling commands already disabled deployment > ------------------------------------------------------------------- > > Key: WFCORE-3566 > URL: https://issues.jboss.org/browse/WFCORE-3566 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Vratislav Marek > Assignee: Martin Stefanko > Labels: test_included > Fix For: 5.0.0.Alpha4 > > > *Different command result of disabling already disabled deployment in standalone and domain mode* > * In standalone return > {noformat} > WFLYCTL0155: 'steps' may not be null > {noformat} > * In domain return nothing, no warning or error > {noformat} > [standalone@localhost:9990 /] deployment info > NAME RUNTIME-NAME PERSISTENT ENABLED STATUS > cli-test-another-deploy.war cli-test-another-deploy.war true true OK > cli-test-app1-deploy.war cli-test-app1-deploy.war true false STOPPED > cli-test-app2-deploy.war cli-test-app2-deploy.war true true OK > [standalone@localhost:9990 /] deployment disable cli-test-app1-deploy-all.war > WFLYCTL0155: 'steps' may not be null > [standalone@localhost:9990 /] > {noformat} > {noformat} > [domain@localhost:9990 /] deployment info --server-groups=main-server-group > NAME RUNTIME-NAME STATE > cli-test-another-deploy-all.war cli-test-another-deploy-all.war enabled > cli-test-app1-deploy-all.war cli-test-app1-deploy-all.war added > cli-test-app2-deploy-all.war cli-test-app2-deploy-all.war not added > cli-test-app3-deploy-all.war cli-test-app3-deploy-all.war enabled > [domain@localhost:9990 /] deployment disable --server-groups=main-server-group cli-test-app1-deploy-all.war > [domain@localhost:9990 /] > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-181) Install Openshift 3.9 Cluster B21

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-181?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo resolved SWSQE-181. ------------------------------------------- Resolution: Done > Install Openshift 3.9 Cluster B21 > --------------------------------- > > Key: SWSQE-181 > URL: https://issues.jboss.org/browse/SWSQE-181 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > > Reinstall Openshift 3.9 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3765) Make the embedded module maven deps very clear

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3765: ---------------------------------------- Summary: Make the embedded module maven deps very clear Key: WFCORE-3765 URL: https://issues.jboss.org/browse/WFCORE-3765 Project: WildFly Core Issue Type: Task Components: Embedded Reporter: Brian Stansberry Assignee: Brian Stansberry The embedded module pom should be as precise as possible about dependencies so it is crystal clear what needs to be on the embedding app's classpath. 1) Any dependency should have an exclude to exclude all transitives. So all deps should have to be declared in order to compile. 2) Any dependency that at runtime is only used via the embedded process side modular classloader should use scope 'provided'. These should also be grouped together in the pom. At runtime these dependencies do not need to be available to the embedding app's classloader; the embedding app creates a modular classloader configured with an appropriate module path and these deps are loaded that way. The maven 'provided' notion basically aligns with this concept. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-85) TravisCI for building and pushing test-mesh to public Docker Repo

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/SWSQE-85?page=com.atlassian.jira.plugin.s... ] Matt Mahoney resolved SWSQE-85. ------------------------------- Resolution: Done PR Merged: kiali-test-service and kiali-test-mesh-traffic-generator now build and pushed to: [https://hub.docker.com/u/kiali|https://hub.docker.com/u/kiali]/ > TravisCI for building and pushing test-mesh to public Docker Repo > ----------------------------------------------------------------- > > Key: SWSQE-85 > URL: https://issues.jboss.org/browse/SWSQE-85 > Project: Kiali QE > Issue Type: QE Task > Reporter: Matt Mahoney > Assignee: Matt Mahoney > Priority: Minor > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2265) Jgroup MERGE3 is not merging big cluster

by lokesh raheja (JIRA)

[ https://issues.jboss.org/browse/JGRP-2265?page=com.atlassian.jira.plugin.... ] lokesh raheja updated JGRP-2265: -------------------------------- Description: Hi Bela MERGE3 is not merging the cluster: We have a cluster of 105 nodes.I see after the cluster split it merge the cluster every time. But sometimes it gets stuck and divided into two or three clusters .1 big cluster and 2 small clusters. We have to restart the node in the small cluster to join the big cluster. In the case when it doesn’t join the cluster, I noticed that the node which is not in big cluster show the coordinator(using MERGE3.dumpviews) is the one which is already in a big cluster.The strange part is if I shut down the coordinator of a small cluster, but on all the nodes of the small cluster, it shows that same coordinator which is shut down. Is some caching issue?Could you please help on the same was: MERGE3 is not merging the cluster: We have a cluster of 105 nodes.I see after the cluster split it merge the cluster every time. But sometimes it gets stuck and divided into two or three clusters .1 big cluster and 2 small clusters. We have to restart the node in the small cluster to join the big cluster. In the case when it doesn’t join the cluster, I noticed that the node which is not in big cluster show the coordinator(using MERGE3.dumpviews) is the one which is already in a big cluster.The strange part is if I shut down the coordinator of a small cluster, but on all the nodes of the small cluster, it shows that same coordinator which is shut down. Is some caching issue?Could you please help on the same > Jgroup MERGE3 is not merging big cluster > ---------------------------------------- > > Key: JGRP-2265 > URL: https://issues.jboss.org/browse/JGRP-2265 > Project: JGroups > Issue Type: Feature Request > Reporter: lokesh raheja > Assignee: Bela Ban > > Hi Bela > MERGE3 is not merging the cluster: > We have a cluster of 105 nodes.I see after the cluster split it merge the cluster every time. > But sometimes it gets stuck and divided into two or three clusters .1 big cluster and 2 small clusters. > We have to restart the node in the small cluster to join the big cluster. > In the case when it doesn’t join the cluster, I noticed that the node which is not in big cluster show the coordinator(using MERGE3.dumpviews) is the one which is already in a big cluster.The strange part is if I shut down the coordinator of a small cluster, but on all the nodes of the small cluster, it shows that same coordinator which is shut down. > Is some caching issue?Could you please help on the same > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-181) Install Openshift 3.9 Cluster B21

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-181?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo commented on SWSQE-181: ----------------------------------------------- I decided to use b21 as node instead of going as a master. This is going maximize memory and pod allocation since b21 is newer than b18. (disclaimer: if you deploy an openshift master, you will need to use a node for infrastructure which will use only for infra pods like hawkular metrics) > Install Openshift 3.9 Cluster B21 > --------------------------------- > > Key: SWSQE-181 > URL: https://issues.jboss.org/browse/SWSQE-181 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2018