May 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3542) Elytron JDBC realm password mapping is not consistent with underlying implementation

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3542?page=com.atlassian.jira.plugi... ] Jan Kalina commented on WFCORE-3542: ------------------------------------ jdb-realm specify individual password types in complex attributes requiring attributes required for given type - to support modular crypt need to be modular-crypt-mapper added. > Elytron JDBC realm password mapping is not consistent with underlying implementation > ------------------------------------------------------------------------------------ > > Key: WFCORE-3542 > URL: https://issues.jboss.org/browse/WFCORE-3542 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: David Lloyd > Assignee: Jan Kalina > > There is no way to configure the JDBC realm to use modular crypt in WildFly, even though the underlying realm does support it. > The problem is that the *{{salt-index}} and {{itereration-count-index}} attributes should be optional*, and if they not given, a value of {{-1}} should be passed to the mapper. By omitting both of these values, the database column values will then be recognized as modular-crypt strings. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2545) Accumulate on 'this' doesn't work in executable model

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2545?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-2545. --------------------------------- Resolution: Done Fixed by https://github.com/kiegroup/drools/commit/f1939d045cc3462d4937a005fa48cc2... > Accumulate on 'this' doesn't work in executable model > ----------------------------------------------------- > > Key: DROOLS-2545 > URL: https://issues.jboss.org/browse/DROOLS-2545 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2546) Accumulate on 'this' doesn't work in executable model

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-2546: ----------------------------------- Summary: Accumulate on 'this' doesn't work in executable model Key: DROOLS-2546 URL: https://issues.jboss.org/browse/DROOLS-2546 Project: Drools Issue Type: Bug Components: core engine Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2545) Accumulate on 'this' doesn't work in executable model

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-2545: ----------------------------------- Summary: Accumulate on 'this' doesn't work in executable model Key: DROOLS-2545 URL: https://issues.jboss.org/browse/DROOLS-2545 Project: Drools Issue Type: Bug Components: core engine Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10350) Duplicated packages in artemis modules

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-10350?page=com.atlassian.jira.plugin... ] Jeff Mesnil resolved WFLY-10350. -------------------------------- Resolution: Rejected This is not an issue. The packages are present in 2 artemis jars but they provide non-overlapping classes. Artemis ended up with such a split to extract its journal component (that depends on artemis-commons). At that time, the classes were moved from one component to another without changing their packages for backwards compatibility > Duplicated packages in artemis modules > -------------------------------------- > > Key: WFLY-10350 > URL: https://issues.jboss.org/browse/WFLY-10350 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 12.0.0.Final > Reporter: Erich Duda > Assignee: Jeff Mesnil > > As you can see in the following report, some Artemis packages are present in multiple jars which are parts of different modules. {{artemis-core-client}} jar is located in main module and {{artemis-commons}} jar is located in {{journal}} module. This is problem for Jigsaw. > Based on the discussion with [~dmlloyd] This can be solved by adding {{filter}} subelement to the artemis-commons to filter out duplicated packages. > {code} > 142) [Package org.apache.activemq.artemis.api.core is present in multiple jars [artemis-commons-1.5.5.jbossorg-010.jar, artemis-core-client-1.5.5.jbossorg-010.jar]] > 144) [Package org.apache.activemq.artemis.core.buffers.impl is present in multiple jars [artemis-commons-1.5.5.jbossorg-010.jar, artemis-core-client-1.5.5.jbossorg-010.jar]] > ./org/apache/activemq/artemis/main/artemis-core-client-1.5.5.jbossorg-010.jar > ./org/apache/activemq/artemis/journal/main/artemis-commons-1.5.5.jbossorg-010.jar > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10350) Duplicated packages in artemis modules

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-10350?page=com.atlassian.jira.plugin... ] Jeff Mesnil commented on WFLY-10350: ------------------------------------ I check at the content of the duplicated packages from Artemis 1.5.5.jbossorg-010 and there is no overlapping classes. {code} $ ls artemis-commons/src/main/java/org/apache/activemq/artemis/core/buffers/impl/ ChannelBufferWrapper.java $ ls artemis-core-client/src/main/java/org/apache/activemq/artemis/core/buffers/impl/ ResetLimitWrappedActiveMQBuffer.java $ ls artemis-commons/src/main/java/org/apache/activemq/artemis/api/core/ ActiveMQAddressExistsException.java ActiveMQIllegalStateException.java ActiveMQPropertyConversionException.java ActiveMQAddressFullException.java ActiveMQIncompatibleClientServerException.java ActiveMQQueueExistsException.java ActiveMQAlreadyReplicatingException.java ActiveMQInterceptorRejectedPacketException.java ActiveMQRemoteDisconnectException.java ActiveMQBuffer.java ActiveMQInternalErrorException.java ActiveMQSecurityException.java ActiveMQBuffers.java ActiveMQInterruptedException.java ActiveMQSessionCreationException.java ActiveMQClusterSecurityException.java ActiveMQInvalidFilterExpressionException.java ActiveMQTransactionOutcomeUnknownException.java ActiveMQConnectionTimedOutException.java ActiveMQInvalidTransientQueueUseException.java ActiveMQTransactionRolledBackException.java ActiveMQDisconnectedException.java ActiveMQLargeMessageException.java ActiveMQTransactionTimeoutException.java ActiveMQDuplicateIdException.java ActiveMQLargeMessageInterruptedException.java ActiveMQUnBlockedException.java ActiveMQDuplicateMetaDataException.java ActiveMQNativeIOError.java ActiveMQUnsupportedPacketException.java ActiveMQException.java ActiveMQNonExistentQueueException.java Pair.java ActiveMQExceptionType.java ActiveMQNotConnectedException.java SimpleString.java ActiveMQIOErrorException.java ActiveMQObjectClosedException.java $ ls artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/ BaseInterceptor.java JGroupsBroadcastEndpoint.java TransportConfiguration.java BroadcastEndpoint.java JGroupsChannelBroadcastEndpoint.java TransportConfigurationHelper.java BroadcastEndpointFactory.java JGroupsFileBroadcastEndpoint.java UDPBroadcastEndpointFactory.java BroadcastGroupConfiguration.java JGroupsFileBroadcastEndpointFactory.java client/ ChannelBroadcastEndpointFactory.java JGroupsPropertiesBroadcastEndpoint.java jgroups/ DiscoveryGroupConfiguration.java JGroupsPropertiesBroadcastEndpointFactory.java management/ FilterConstants.java JsonUtil.java Interceptor.java Message.java {code} > Duplicated packages in artemis modules > -------------------------------------- > > Key: WFLY-10350 > URL: https://issues.jboss.org/browse/WFLY-10350 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 12.0.0.Final > Reporter: Erich Duda > Assignee: Jeff Mesnil > > As you can see in the following report, some Artemis packages are present in multiple jars which are parts of different modules. {{artemis-core-client}} jar is located in main module and {{artemis-commons}} jar is located in {{journal}} module. This is problem for Jigsaw. > Based on the discussion with [~dmlloyd] This can be solved by adding {{filter}} subelement to the artemis-commons to filter out duplicated packages. > {code} > 142) [Package org.apache.activemq.artemis.api.core is present in multiple jars [artemis-commons-1.5.5.jbossorg-010.jar, artemis-core-client-1.5.5.jbossorg-010.jar]] > 144) [Package org.apache.activemq.artemis.core.buffers.impl is present in multiple jars [artemis-commons-1.5.5.jbossorg-010.jar, artemis-core-client-1.5.5.jbossorg-010.jar]] > ./org/apache/activemq/artemis/main/artemis-core-client-1.5.5.jbossorg-010.jar > ./org/apache/activemq/artemis/journal/main/artemis-commons-1.5.5.jbossorg-010.jar > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2257) UDP#PacketReceiver stuck in busy loop when socket throws closed exception but socket is not closed

by Paul Illingworth (JIRA)

[ https://issues.jboss.org/browse/JGRP-2257?page=com.atlassian.jira.plugin.... ] Paul Illingworth closed JGRP-2257. ---------------------------------- Resolution: Cannot Reproduce Unable to reproduce and as far as I am aware has not been seen before or since. > UDP#PacketReceiver stuck in busy loop when socket throws closed exception but socket is not closed > -------------------------------------------------------------------------------------------------- > > Key: JGRP-2257 > URL: https://issues.jboss.org/browse/JGRP-2257 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.12 > Environment: Windows Server 2016, 32GBytes memory running as a Hyper-V guest > java version "1.8.0_131" > Java(TM) SE Runtime Environment (build 1.8.0_131-b11) > Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode) > It was reported with just a single node running. > Reporter: Paul Illingworth > Assignee: Bela Ban > Fix For: 4.0.12 > > > I have a had a report of a scenario where it looks like the UDP#PacketReceiver is stuck spinning in a busy loop. The following is a snippet of the log file from the system in question. > {noformat} > 2018-03-16 14:05:43,273 SEVERE [] (214,unicast receiver,shared=udp) JGRP000190: failed receiving packet > java.net.SocketException: socket closed > at java.net.TwoStacksPlainDatagramSocketImpl.peekData(Native Method) > at java.net.DatagramSocket.receive(DatagramSocket.java:743) > at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:694) > at java.lang.Thread.run(Thread.java:748) > > 2018-03-16 14:05:43,273 SEVERE [] (214,unicast receiver,shared=udp) JGRP000190: failed receiving packet > java.net.SocketException: socket closed > at java.net.TwoStacksPlainDatagramSocketImpl.peekData(Native Method) > at java.net.DatagramSocket.receive(DatagramSocket.java:743) > at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:694) > at java.lang.Thread.run(Thread.java:748) > > 2018-03-16 14:05:43,273 SEVERE [] (214,unicast receiver,shared=udp) JGRP000190: failed receiving packet > java.net.SocketException: socket closed > at java.net.TwoStacksPlainDatagramSocketImpl.peekData(Native Method) > at java.net.DatagramSocket.receive(DatagramSocket.java:743) > at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:694) > at java.lang.Thread.run(Thread.java:748) > {noformat} > Looking at the code it looks like the call to receive a packet > {code:java} > receiver_socket.receive(packet); > {code} > results in an exception being thrown because the socket is closed but then when the exception is caught > {code:java} > if(receiver_socket.isClosed()) { > {code} > method is queried which says the socket has not been closed and the loop then continues for ever. > I guess this is related to JGRP-1669. To quote > _I hope there is no condition which causes the socket receive() to spit out endless exceptions while not being closed..._ -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2257) UDP#PacketReceiver stuck in busy loop when socket throws closed exception but socket is not closed

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2257?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2257: -------------------------------- I see that there's no {{SocketClosedException}}, just the generic {{SocketException}}. I agree that parsing the exception's message for "socket closed" is brittle, and not something I want to do. Yes, please close this ticket and re-open if you run into the issue again, hopefully with a reproduceable use case... > UDP#PacketReceiver stuck in busy loop when socket throws closed exception but socket is not closed > -------------------------------------------------------------------------------------------------- > > Key: JGRP-2257 > URL: https://issues.jboss.org/browse/JGRP-2257 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.12 > Environment: Windows Server 2016, 32GBytes memory running as a Hyper-V guest > java version "1.8.0_131" > Java(TM) SE Runtime Environment (build 1.8.0_131-b11) > Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode) > It was reported with just a single node running. > Reporter: Paul Illingworth > Assignee: Bela Ban > Fix For: 4.0.12 > > > I have a had a report of a scenario where it looks like the UDP#PacketReceiver is stuck spinning in a busy loop. The following is a snippet of the log file from the system in question. > {noformat} > 2018-03-16 14:05:43,273 SEVERE [] (214,unicast receiver,shared=udp) JGRP000190: failed receiving packet > java.net.SocketException: socket closed > at java.net.TwoStacksPlainDatagramSocketImpl.peekData(Native Method) > at java.net.DatagramSocket.receive(DatagramSocket.java:743) > at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:694) > at java.lang.Thread.run(Thread.java:748) > > 2018-03-16 14:05:43,273 SEVERE [] (214,unicast receiver,shared=udp) JGRP000190: failed receiving packet > java.net.SocketException: socket closed > at java.net.TwoStacksPlainDatagramSocketImpl.peekData(Native Method) > at java.net.DatagramSocket.receive(DatagramSocket.java:743) > at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:694) > at java.lang.Thread.run(Thread.java:748) > > 2018-03-16 14:05:43,273 SEVERE [] (214,unicast receiver,shared=udp) JGRP000190: failed receiving packet > java.net.SocketException: socket closed > at java.net.TwoStacksPlainDatagramSocketImpl.peekData(Native Method) > at java.net.DatagramSocket.receive(DatagramSocket.java:743) > at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:694) > at java.lang.Thread.run(Thread.java:748) > {noformat} > Looking at the code it looks like the call to receive a packet > {code:java} > receiver_socket.receive(packet); > {code} > results in an exception being thrown because the socket is closed but then when the exception is caught > {code:java} > if(receiver_socket.isClosed()) { > {code} > method is queried which says the socket has not been closed and the loop then continues for ever. > I guess this is related to JGRP-1669. To quote > _I hope there is no condition which causes the socket receive() to spit out endless exceptions while not being closed..._ -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1567) [JDK9+] wildfly-elytron-tool jar doesn't not have Multi-Release entry in Manifest

by Rostislav Svoboda (JIRA)

[ https://issues.jboss.org/browse/ELY-1567?page=com.atlassian.jira.plugin.s... ] Rostislav Svoboda reassigned ELY-1567: -------------------------------------- Assignee: Rostislav Svoboda > [JDK9+] wildfly-elytron-tool jar doesn't not have Multi-Release entry in Manifest > --------------------------------------------------------------------------------- > > Key: ELY-1567 > URL: https://issues.jboss.org/browse/ELY-1567 > Project: WildFly Elytron > Issue Type: Bug > Components: Utils > Reporter: Rostislav Svoboda > Assignee: Rostislav Svoboda > Priority: Critical > > Split of https://issues.jboss.org/browse/WFLY-10256 to component trackers > Artifact wildfly-13.0.0.Alpha1-SNAPSHOT/bin/wildfly-elytron-tool.jar is expected to be Multi-Release JAR as it has overlay directory but no Multi-Release entry in Manifest -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1567) [JDK9+] wildfly-elytron-tool jar doesn't not have Multi-Release entry in Manifest

by Rostislav Svoboda (JIRA)

[ https://issues.jboss.org/browse/ELY-1567?page=com.atlassian.jira.plugin.s... ] Rostislav Svoboda updated ELY-1567: ----------------------------------- Git Pull Request: https://github.com/wildfly-security/wildfly-elytron-tool/pull/144 > [JDK9+] wildfly-elytron-tool jar doesn't not have Multi-Release entry in Manifest > --------------------------------------------------------------------------------- > > Key: ELY-1567 > URL: https://issues.jboss.org/browse/ELY-1567 > Project: WildFly Elytron > Issue Type: Bug > Components: Utils > Reporter: Rostislav Svoboda > Assignee: Rostislav Svoboda > Priority: Critical > > Split of https://issues.jboss.org/browse/WFLY-10256 to component trackers > Artifact wildfly-13.0.0.Alpha1-SNAPSHOT/bin/wildfly-elytron-tool.jar is expected to be Multi-Release JAR as it has overlay directory but no Multi-Release entry in Manifest -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 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 May 2018