May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2767) Elytron Keystore resource needs restart when is changed credential-reference attribute but restart-required is set to "no-services"

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2767?page=com.atlassian.jira.plugi... ] Yeray Borges reassigned WFCORE-2767: ------------------------------------ Assignee: Yeray Borges > Elytron Keystore resource needs restart when is changed credential-reference attribute but restart-required is set to "no-services" > ----------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2767 > URL: https://issues.jboss.org/browse/WFCORE-2767 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Yeray Borges > Priority: Critical > > Elytron Keystore resource needs restart when is changed credential-reference attribute but restart-required is set to "no-services" > There should be rather restart-required set to "resource-services" and ability to use allow-resource-service-restart=true header property -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8697) Address DeploymentUnitProcessor leaks in the codebase

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-8697?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-8697: --------------------------------- Issue Type: Bug (was: Task) > Address DeploymentUnitProcessor leaks in the codebase > ----------------------------------------------------- > > Key: WFLY-8697 > URL: https://issues.jboss.org/browse/WFLY-8697 > Project: WildFly > Issue Type: Bug > Affects Versions: 11.0.0.Alpha1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > In order to get singleton deployments fully working, we need to address the numerous {{org.jboss.as.server.deployment.DeploymentUnitProcessor#undeploy}} implementation leaks. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8719) Address DeploymentUnitProcessor leaks in the codebase

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-8719: ------------------------------------ Summary: Address DeploymentUnitProcessor leaks in the codebase Key: WFLY-8719 URL: https://issues.jboss.org/browse/WFLY-8719 Project: WildFly Issue Type: Task Affects Versions: 11.0.0.Alpha1 Reporter: Radoslav Husar Assignee: Radoslav Husar In order to get singleton deployments fully working, we need to address the numerous {{org.jboss.as.server.deployment.DeploymentUnitProcessor#undeploy}} implementation leaks. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8706) Singleton deployments does not work in domain mode

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-8706?page=com.atlassian.jira.plugin.... ] Radoslav Husar closed WFLY-8706. -------------------------------- Resolution: Rejected > Singleton deployments does not work in domain mode > -------------------------------------------------- > > Key: WFLY-8706 > URL: https://issues.jboss.org/browse/WFLY-8706 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Environment: Centos > Wildfly 10.1.0.Final (two instances and one domain controller) > Java 8 > Reporter: Ariel Carrera > Assignee: Paul Ferraro > > In a domain mode, when a deployment is a "singleton deployment" (with a singleton- deployment.xml descriptor), it is working fine if the server nodes are started sequently but fails if it is started from domain console. > When a deployments needs to be updated, a race condition happens and two instances of the deployment are started. > From logs: > node1: > 12:39:48,434 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 133) WFLYCLINF0002: Started default cache from server container > 12:39:48,436 INFO [org.wildfly.clustering.server] (notification-thread--p84-t1) WFLYCLSV0003: node1:one *elected as the singleton provider of the jboss.deployment.unit."my-deployment.jar"*.FIRST_MODULE_USE service > 12:39:48,440 INFO [org.wildfly.clustering.server] (notification-thread--p84-t1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."my-deployment.jar".FIRST_MODULE_USE service > node2: > 12:39:48,370 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 122) WFLYCLINF0002: Started default cache from server container > 12:39:48,372 INFO [org.wildfly.clustering.server] (notification-thread--p193-t1) WFLYCLSV0003: node2:two *elected as the singleton provider of the jboss.deployment.unit."my-deployment.jar"*.FIRST_MODULE_USE service > 12:39:48,372 INFO [org.wildfly.clustering.server] (notification-thread--p193-t1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."my-deployment.jar".FIRST_MODULE_USE service -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8706) Singleton deployments does not work in domain mode

by Ariel Carrera (JIRA)

[ https://issues.jboss.org/browse/WFLY-8706?page=com.atlassian.jira.plugin.... ] Ariel Carrera commented on WFLY-8706: ------------------------------------- I'm sorry, I forgot, you're right. Closed, it was a problem with jgroups configuration and there is not a bug. > Singleton deployments does not work in domain mode > -------------------------------------------------- > > Key: WFLY-8706 > URL: https://issues.jboss.org/browse/WFLY-8706 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Environment: Centos > Wildfly 10.1.0.Final (two instances and one domain controller) > Java 8 > Reporter: Ariel Carrera > Assignee: Paul Ferraro > > In a domain mode, when a deployment is a "singleton deployment" (with a singleton- deployment.xml descriptor), it is working fine if the server nodes are started sequently but fails if it is started from domain console. > When a deployments needs to be updated, a race condition happens and two instances of the deployment are started. > From logs: > node1: > 12:39:48,434 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 133) WFLYCLINF0002: Started default cache from server container > 12:39:48,436 INFO [org.wildfly.clustering.server] (notification-thread--p84-t1) WFLYCLSV0003: node1:one *elected as the singleton provider of the jboss.deployment.unit."my-deployment.jar"*.FIRST_MODULE_USE service > 12:39:48,440 INFO [org.wildfly.clustering.server] (notification-thread--p84-t1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."my-deployment.jar".FIRST_MODULE_USE service > node2: > 12:39:48,370 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 122) WFLYCLINF0002: Started default cache from server container > 12:39:48,372 INFO [org.wildfly.clustering.server] (notification-thread--p193-t1) WFLYCLSV0003: node2:two *elected as the singleton provider of the jboss.deployment.unit."my-deployment.jar"*.FIRST_MODULE_USE service > 12:39:48,372 INFO [org.wildfly.clustering.server] (notification-thread--p193-t1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."my-deployment.jar".FIRST_MODULE_USE service -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8718) JDBC driver's xa-datasource-class vs. driver-xa-datasource-class-name in the datasources subsystem

by Ladislav Thon (JIRA)

Ladislav Thon created WFLY-8718: ----------------------------------- Summary: JDBC driver's xa-datasource-class vs. driver-xa-datasource-class-name in the datasources subsystem Key: WFLY-8718 URL: https://issues.jboss.org/browse/WFLY-8718 Project: WildFly Issue Type: Bug Components: JCA Affects Versions: 10.1.0.Final Reporter: Ladislav Thon Assignee: Stefano Maestri The {{jdbc-driver=*}} management resources in the {{datasources}} subsystem has two attributes, {{xa-datasource-class}} and {{driver-xa-datasource-class-name}}, whose difference isn't clear. Per wildfly-dev discussion \[1\], the {{xa-datasource-class}} has actually no meaning. IMHO, at the very least, it should be marked as deprecated with an explanation of something like "ignored" or so. Ultimately, removal is IMHO a good idea. I'd also like to note that this actually caused a bug in WildFly Swarm: SWARM-1215 \[1\] http://lists.jboss.org/pipermail/wildfly-dev/2017-May/005913.html -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2620) Add ability to read computed runtime values of IO subsystem buffer-pool attributes

by Romain Pelisse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2620?page=com.atlassian.jira.plugi... ] Romain Pelisse edited comment on WFCORE-2620 at 5/8/17 6:29 AM: ---------------------------------------------------------------- [~ctomc] following your comment (and Brian's) on my [PR|https://github.com/wildfly/wildfly-core/pull/2330] for [WFCORE-2620|https://issues.jboss.org/browse/WFCORE-2620], I've looked at how you achieved a proper runtime computed value of the workers. AFAIU, you simply used the [MBean|https://github.com/wildfly/wildfly-core/blob/master/io/subsystem/sr...], provided by Xnio(1) to get the proper value. However, afaiu, there is no value related to buffer in this MBean. There is an other MBean, java.nio, providing info in the BufferPool(2), however the attributes available there (TotalCapacity and Count) does not provides us with the metrics we need here (buffer-size and buffers-per-slice). AFAIU, the metrics associated to those are computer in the [BufferPoolResourceDefinition class|https://github.com/wildfly/wildfly-core/blob/master/io/subsystem/sr...], and maybe override using the subsystem configuration in [the standalone.xm|https://github.com/wildfly/wildfly-core/blob/master/io/subs...]. My naive approach here - that I want to double check with you, is : Should I create a MBean for the buffer attribute - to mimic the approach of the worker ? If so I assume we'll move the [buffers "default computation"|https://github.com/wildfly/wildfly-core/blob/master/io/subsystem/src/main/java/org/wildfly/extension/io/BufferPoolResourceDefinition.java#L62] into the MBean (right?). Or am I misunderstanding or missing something here ? Let me know what you think about this (and if my analysis is correct) MX object names: * (1) ObjectName: org.xnio:tyep=Xnio.provider="nio,work"="default" * (2) ObjectName: java.nio:type=BufferPool,name=direct] was (Author: rpelisse): [~ctomc] following your comment (and Brian's) on my [PR|https://github.com/wildfly/wildfly-core/pull/2330] for [WFCORE-2620|https://issues.jboss.org/browse/WFCORE-2620], I've looked at you achieved a proper runtime computed value of the workers. AFAIU, you simply used the [MBean|https://github.com/wildfly/wildfly-core/blob/master/io/subsystem/sr...], provided by Xnio(1) to get the proper value. However, there is no value related to buffer in this MBean. There is an other MBean, java.nio, providing info in the BufferPool(2), however the attributes available there (TotalCapacity and Count) does not provides us with the metrics we need here (buffer-size and buffers-per-slice). AFAIU, the metrics associated to those are computer in the [BufferPoolResourceDefinition class|https://github.com/wildfly/wildfly-core/blob/master/io/subsystem/sr...], and maybe override using the subsystem configuration in [the standalone.xm|https://github.com/wildfly/wildfly-core/blob/master/io/subs...]. My naive approach here - that I want to double check with you, is : Should I create a MBean for the buffer attribute - to mimic the approach of the worker ? If so I assume we'll move the [buffers "default computation"|https://github.com/wildfly/wildfly-core/blob/master/io/subsystem/src/main/java/org/wildfly/extension/io/BufferPoolResourceDefinition.java#L62] into the MBean (right?). Or am I misunderstanding or missing something here ? Let me know what you think about this (and if my analysis is correct) MX object names: * (1) ObjectName: org.xnio:tyep=Xnio.provider="nio,work"="default" * (2) ObjectName: java.nio:type=BufferPool,name=direct] > Add ability to read computed runtime values of IO subsystem buffer-pool attributes > ---------------------------------------------------------------------------------- > > Key: WFCORE-2620 > URL: https://issues.jboss.org/browse/WFCORE-2620 > Project: WildFly Core > Issue Type: Enhancement > Affects Versions: 3.0.0.Beta13 > Reporter: Romain Pelisse > Assignee: Romain Pelisse > Original Estimate: 2 days > Remaining Estimate: 2 days > > In IO subsystem there are some attributes which are calculated based on available system resources if not explicitly specified. These attributes are: > * worker > ** io-threads > ** task-max-threads > * buffer-pool > ** buffer-size > ** buffers-per-slice > ** direct-buffers > Currently these computed values are not visible for user in the subsystem configuration even with include-runtime=true. > To show these runtime values would definitely improve UX. > Worker attributes are covered by EAP7-616 . > This issue is about buffer-pool attributes. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ELY-1142) Add an NSS database to the testsuite and selection of smoke tests to use it.

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1142: ------------------------------------- Summary: Add an NSS database to the testsuite and selection of smoke tests to use it. Key: ELY-1142 URL: https://issues.jboss.org/browse/ELY-1142 Project: WildFly Elytron Issue Type: Task Components: SSL, Testsuite Reporter: Darran Lofthouse Fix For: 2.0.0.Alpha1 Due to NSS not being available in all environments testing will likely need to be conditional on the OS, this should however at the very least assist in flagging regressions in the PR process. Originally creating thinking about SSL but we could possibly cover credential store as well. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2773) Upgrade Wildfly-Elytron-Tool to 1.0.0.Beta5

by Peter Skopek (JIRA)

Peter Skopek created WFCORE-2773: ------------------------------------ Summary: Upgrade Wildfly-Elytron-Tool to 1.0.0.Beta5 Key: WFCORE-2773 URL: https://issues.jboss.org/browse/WFCORE-2773 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Peter Skopek Assignee: Darran Lofthouse -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1556) Implement support for proxies in kie-ci

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-1556: ----------------------------------- Summary: Implement support for proxies in kie-ci Key: DROOLS-1556 URL: https://issues.jboss.org/browse/DROOLS-1556 Project: Drools Issue Type: Enhancement Components: core engine Reporter: Mario Fusco Assignee: Mario Fusco Kie-Maven integration doesn't support proxy settings in maven configuration -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

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 May 2017