September 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9375) META-INF/services are always accessible from dependencies

by Alexander Kudrevatykh (JIRA)

[ https://issues.jboss.org/browse/WFLY-9375?page=com.atlassian.jira.plugin.... ] Alexander Kudrevatykh commented on WFLY-9375: --------------------------------------------- I created patch, which helps me with this issue https://github.com/wildfly/wildfly/pull/10535 > META-INF/services are always accessible from dependencies > --------------------------------------------------------- > > Key: WFLY-9375 > URL: https://issues.jboss.org/browse/WFLY-9375 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final, 10.1.0.Final, 11.0.0.CR1 > Reporter: Alexander Kudrevatykh > Assignee: Jason Greene > > I found regression in Wildfly 10.1 (10.0 and 11 CR1 also affected) - META-INF/services entries are accesible from war dependencies, even if not marked as "import" -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9375) META-INF/services are always accessible from dependencies

by Alexander Kudrevatykh (JIRA)

Alexander Kudrevatykh created WFLY-9375: ------------------------------------------- Summary: META-INF/services are always accessible from dependencies Key: WFLY-9375 URL: https://issues.jboss.org/browse/WFLY-9375 Project: WildFly Issue Type: Bug Affects Versions: 11.0.0.CR1, 10.1.0.Final, 10.0.0.Final Reporter: Alexander Kudrevatykh Assignee: Jason Greene I found regression in Wildfly 10.1 (10.0 and 11 CR1 also affected) - META-INF/services entries are accesible from war dependencies, even if not marked as "import" -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3316) Server fails to start after submitting invalid security attributes

by Martin Stefanko (JIRA)

Martin Stefanko created WFCORE-3316: --------------------------------------- Summary: Server fails to start after submitting invalid security attributes Key: WFCORE-3316 URL: https://issues.jboss.org/browse/WFCORE-3316 Project: WildFly Core Issue Type: Bug Components: CLI Affects Versions: 3.0.3.Final Reporter: Martin Stefanko Assignee: Martin Stefanko Priority: Critical Server fails to start after submitting invalid security attributes values for remoting http connector (e.g QOP, strength) Only fix for the configuration is to manually change the XML file directly -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3305) Advanced SSL Use Cases

by Ondrej Kotek (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3305?page=com.atlassian.jira.plugi... ] Ondrej Kotek commented on WFCORE-3305: -------------------------------------- Could we rename this issue to be more specific? For example, "Advanced operations for SSL certificates", or "Advanced operations on Elytron key-store", ... > Advanced SSL Use Cases > ---------------------- > > Key: WFCORE-3305 > URL: https://issues.jboss.org/browse/WFCORE-3305 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Fix For: 4.0.0.Beta1 > > > Analysis Document: > https://developer.jboss.org/wiki/AnalysisDesign-AdvancedSSLUseCases -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2220) Two nodes can own a same lock at same time

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2220?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2220: --------------------------- Fix Version/s: 4.0.7 > Two nodes can own a same lock at same time > ------------------------------------------ > > Key: JGRP-2220 > URL: https://issues.jboss.org/browse/JGRP-2220 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.4 > Environment: Two nodes cluster with jgroup 3.4.0 alpha2 > Reporter: Xiao Li > Assignee: Bela Ban > Fix For: 4.0.7 > > > We have a two node cluster with following protocol stack for distributed lock. > lock.protocolStack=UDP(bind_addr=myIP;bind_port=31562;mcast_addr=239.255.166.17;mcast_port=31569;ip_ttl=32;mcast_send_buf_size=150000;mcast_recv_buf_size=80000):PING(timeout=2000;num_initial_members=3):MERGE2(min_interval=5000;max_interval=10000):FD_ALL(interval=5000;timeout=20000):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(retransmit_timeout=300,600,1200,2400,4800):UNICAST(timeout=5000):pbcast.STABLE(desired_avg_gossip=20000):FRAG(frag_size=8096):pbcast.GMS(join_timeout=5000;print_local_addr=true):CENTRAL_LOCK(num_backups=2) > We use the following call to get a lock for one node. > lock = lockManager.getLock(lockId); > lock.tryLock(Long.MAX_VALUE, TimeUnit.MILLISECONDS); where lockManager is an object of LockService and lock is a Lock object. > Another node is waiting on the lock at same method call. When the node owning the lock release the lock with the call lock.unlock(), the node waiting on the lock gets the lock and the lock is deleted from the node owned the lock. When the JVM for the node that released the lock restarted, it can also get same lock. So two nodes own the lock at same time. > If I don't call lock.unlock() before shutting down the node, it waits for the lock as expected when its JVM starts up. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9264) Remove ClientCompatibilityUnitTestCase as it is already in wildfly-core

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-9264?page=com.atlassian.jira.plugin.... ] Lin Gao edited comment on WFLY-9264 at 9/24/17 9:36 PM: -------------------------------------------------------- ClientCompatibilityUnitTestCase was copied instead of moved from full to core on purpose. Please see the description in WFCORE-2196 :) was (Author: gaol): ClientCompatibilityUnitTestCase was copied from full to core on purpose. Please see the description in WFCORE-2196 :) > Remove ClientCompatibilityUnitTestCase as it is already in wildfly-core > ----------------------------------------------------------------------- > > Key: WFLY-9264 > URL: https://issues.jboss.org/browse/WFLY-9264 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > > also look how much of this is duplicated in core's client-old-server testsuite -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9264) Remove ClientCompatibilityUnitTestCase as it is already in wildfly-core

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-9264?page=com.atlassian.jira.plugin.... ] Lin Gao commented on WFLY-9264: ------------------------------- ClientCompatibilityUnitTestCase was copied from full to core on purpose. Please see the description in WFCORE-2196 :) > Remove ClientCompatibilityUnitTestCase as it is already in wildfly-core > ----------------------------------------------------------------------- > > Key: WFLY-9264 > URL: https://issues.jboss.org/browse/WFLY-9264 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > > also look how much of this is duplicated in core's client-old-server testsuite -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-132) Add support for generating certificate signing requests (CSRs)

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/ELY-132?page=com.atlassian.jira.plugin.sy... ] Farah Juma reassigned ELY-132: ------------------------------ Assignee: Farah Juma > Add support for generating certificate signing requests (CSRs) > -------------------------------------------------------------- > > Key: ELY-132 > URL: https://issues.jboss.org/browse/ELY-132 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Certificate Authority > Reporter: Darran Lofthouse > Assignee: Farah Juma > Fix For: 2.0.0.Alpha1 > > > At some point we want to be able to guide users through the process of generating their own public and private key along with getting a certificate signed by a certificate authority. > Generation of a certificate signing request is going to be essential for that. > https://tools.ietf.org/html/rfc2986 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (AG-35) Use ServiceLoader to discover implementations

by Luis Barreiro (JIRA)

[ https://issues.jboss.org/browse/AG-35?page=com.atlassian.jira.plugin.syst... ] Luis Barreiro resolved AG-35. ----------------------------- Resolution: Done Three options as to how generate the service descriptor : # by hand, in resources/META-INF folder # using a maven plugin (com.github.kristofa/service-plugin-loader) # using an annotation (org.kohsuke/metainf-services) Decided to go for a maven plugin, for being the cleanest way, although it does not seem to integrate with IDEs as well as an annotation does. > Use ServiceLoader to discover implementations > --------------------------------------------- > > Key: AG-35 > URL: https://issues.jboss.org/browse/AG-35 > Project: Agroal > Issue Type: Bug > Components: api, hikari, pool > Affects Versions: 0.2 > Reporter: Luis Barreiro > Assignee: Luis Barreiro > Fix For: 0.3 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2220) Two nodes can own a same lock at same time

by Xiao Li (JIRA)

Xiao Li created JGRP-2220: ----------------------------- Summary: Two nodes can own a same lock at same time Key: JGRP-2220 URL: https://issues.jboss.org/browse/JGRP-2220 Project: JGroups Issue Type: Bug Affects Versions: 3.4 Environment: Two nodes cluster with jgroup 3.4.0 alpha2 Reporter: Xiao Li Assignee: Bela Ban We have a two node cluster with following protocol stack for distributed lock. lock.protocolStack=UDP(bind_addr=myIP;bind_port=31562;mcast_addr=239.255.166.17;mcast_port=31569;ip_ttl=32;mcast_send_buf_size=150000;mcast_recv_buf_size=80000):PING(timeout=2000;num_initial_members=3):MERGE2(min_interval=5000;max_interval=10000):FD_ALL(interval=5000;timeout=20000):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(retransmit_timeout=300,600,1200,2400,4800):UNICAST(timeout=5000):pbcast.STABLE(desired_avg_gossip=20000):FRAG(frag_size=8096):pbcast.GMS(join_timeout=5000;print_local_addr=true):CENTRAL_LOCK(num_backups=2) We use the following call to get a lock for one node. lock = lockManager.getLock(lockId); lock.tryLock(Long.MAX_VALUE, TimeUnit.MILLISECONDS); where lockManager is an object of LockService and lock is a Lock object. Another node is waiting on the lock at same method call. When the node owning the lock release the lock with the call lock.unlock(), the node waiting on the lock gets the lock and the lock is deleted from the node owned the lock. When the JVM for the node that released the lock restarted, it can also get same lock. So two nodes own the lock at same time. If I don't call lock.unlock() before shutting down the node, it waits for the lock as expected when its JVM starts up. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 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 September 2017