February 2021 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (JGRP-2527) NPE if binding JGroups to an IP without interface

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2527?page=com.atlassian.jira.plugin... ] Bela Ban resolved JGRP-2527. ---------------------------- Resolution: Done > NPE if binding JGroups to an IP without interface > ------------------------------------------------- > > Key: JGRP-2527 > URL: https://issues.redhat.com/browse/JGRP-2527 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.2.9 > Reporter: Pedro Ruivo > Assignee: Bela Ban > Priority: Minor > Fix For: 4.2.12, 5.1.5 > > > If you bind JGroups to 127.0.2.1 (or any IP without an interface, like 127.0.0.0/8 - loopback IP addresses (refers to self) RFC 5735), JGroups fails with an NPE: > {noformat} > Caused by: java.lang.NullPointerException > at org.jgroups.protocols.UDP.dumpSocketInfo(UDP.java:558) > at org.jgroups.protocols.UDP.createSockets(UDP.java:422) > at org.jgroups.protocols.UDP.start(UDP.java:292) > at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:868) > at org.jgroups.JChannel.startStack(JChannel.java:980) > at org.jgroups.JChannel._preConnect(JChannel.java:844) > at org.jgroups.JChannel.connect(JChannel.java:349) > at org.jgroups.JChannel.connect(JChannel.java:343) > {noformat} > The exception comes from this line: [https://github.com/belaban/JGroups/blob/4.x/src/org/jgroups/protocols/UDP...] > {{NetworkInterface.getByInetAddress(bind_addr)}} returns {{null}} since the IP does not have an interface. It would be nice to have a null check here to prevent the NPE. > This is useful for local testing when `port_range=0`. It allows having a dedicated IP for each JGroups instance. > Workaround: > The workaround requires you to create a virtual interface > {noformat} > sudo ifconfig lo:0 127.0.2.1 up > {noformat} -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 1 month

1
0
0 / 0

[Red Hat JIRA] (JGRP-2527) NPE if binding JGroups to an IP without interface

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2527?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2527: --------------------------- Fix Version/s: 5.1.5 4.2.12 > NPE if binding JGroups to an IP without interface > ------------------------------------------------- > > Key: JGRP-2527 > URL: https://issues.redhat.com/browse/JGRP-2527 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.2.9 > Reporter: Pedro Ruivo > Assignee: Bela Ban > Priority: Minor > Fix For: 4.2.12, 5.1.5 > > > If you bind JGroups to 127.0.2.1 (or any IP without an interface, like 127.0.0.0/8 - loopback IP addresses (refers to self) RFC 5735), JGroups fails with an NPE: > {noformat} > Caused by: java.lang.NullPointerException > at org.jgroups.protocols.UDP.dumpSocketInfo(UDP.java:558) > at org.jgroups.protocols.UDP.createSockets(UDP.java:422) > at org.jgroups.protocols.UDP.start(UDP.java:292) > at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:868) > at org.jgroups.JChannel.startStack(JChannel.java:980) > at org.jgroups.JChannel._preConnect(JChannel.java:844) > at org.jgroups.JChannel.connect(JChannel.java:349) > at org.jgroups.JChannel.connect(JChannel.java:343) > {noformat} > The exception comes from this line: [https://github.com/belaban/JGroups/blob/4.x/src/org/jgroups/protocols/UDP...] > {{NetworkInterface.getByInetAddress(bind_addr)}} returns {{null}} since the IP does not have an interface. It would be nice to have a null check here to prevent the NPE. > This is useful for local testing when `port_range=0`. It allows having a dedicated IP for each JGroups instance. > Workaround: > The workaround requires you to create a virtual interface > {noformat} > sudo ifconfig lo:0 127.0.2.1 up > {noformat} -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 1 month

1
0
0 / 0

[Red Hat JIRA] (WFLY-14061) Replace Java EE references in java doc with corresponding Jakarta EE ones

by Alessio Soldano (Jira)

[ https://issues.redhat.com/browse/WFLY-14061?page=com.atlassian.jira.plugi... ] Alessio Soldano updated WFLY-14061: ----------------------------------- Priority: Blocker (was: Major) > Replace Java EE references in java doc with corresponding Jakarta EE ones > ------------------------------------------------------------------------- > > Key: WFLY-14061 > URL: https://issues.redhat.com/browse/WFLY-14061 > Project: WildFly > Issue Type: Task > Reporter: Alessio Soldano > Assignee: Ranabir Chakraborty > Priority: Blocker > Fix For: 23.0.0.Beta1 > > Attachments: Replace Java EE references in java doc with corresponding Jakarta EE ones.docx > > -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 1 month

1
0
0 / 0

[Red Hat JIRA] (WFLY-10929) Unescaped characters in URL from client does not work correctly when allowed for HTTP and HTTPS listeners

by Flavia Rainone (Jira)

[ https://issues.redhat.com/browse/WFLY-10929?page=com.atlassian.jira.plugi... ] Flavia Rainone commented on WFLY-10929: --------------------------------------- [~wolfc] That requires an investigation to see how are the access logs showing the non UTF-8 characters for the error message in HTTPS. As for the URLs being percentage-encoded, it is true, that's exactly why the feature is optional. The feature was originally requested with the argument that [other servers supported unescaped characters | UNDERTOW-1185]. > Unescaped characters in URL from client does not work correctly when allowed for HTTP and HTTPS listeners > --------------------------------------------------------------------------------------------------------- > > Key: WFLY-10929 > URL: https://issues.redhat.com/browse/WFLY-10929 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 14.0.0.Beta2 > Reporter: Jan Stourac > Assignee: Bartosz Baranowski > Priority: Major > Labels: downstream_dependency > Attachments: helloworld.war > > > Since the time of {{EAP7.1.1.CP}} there is a possibility to allow unescaped characters in URL requests from clients to server. This was allowed first by setting {{org.wildfly.undertow.ALLOW_UNESCAPED_CHARACTERS_IN_URL=true}} system property introduced by UNDERTOW-1185. Now we have a new attribute for this in Wildfly in AJP, HTTP and HTTPS listeners {{allow-unescaped-characters-in-url}}. > However this does not seem to work correctly. There have been some fixes for AJP listener already UNDERTOW-1386, UNDERTOW-1386 and UNDERTOW-1399 (the last one not included in WildFly {{14.0.0.Beta2}} yet). However HTTP/HTTPS listener seems to be broken too. > When HTTP request with unescaped characters is performed against server: > {code} > curl "http://localhost:8080/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null > {code} > we get 200 OK HTTP response, although the result in access log looks like: > {code:title=HTTP actual result} > 127.0.0.1 - - [27/Aug/2018:09:17:39 +0200] "GET /helloworld/íê¸ì´ë¦ > _test.html?param=íê¸ì´ë¦ > _ahoy HTTP/1.1" 200 950 > {code} > but we expect following: > {code:title=HTTP expected result} > 127.0.0.1 - - [27/Aug/2018:08:40:47 +0200] "GET /helloworld/한글이름_test.html?param=한글이름_ahoy HTTP/1.1" 200 950 > {code} > Slightly different problem seems to be also for HTTPS listener. When we perform HTTPS request against WildFly: > {code} > curl "https://localhost:8443/helloworld/한글이름_test.html?param=한글이름_ahoy" -v >/dev/null --insecure > {code} > we receive 404 Not Found HTTP response and following record in access.log: > {code:HTTPS actual result} > 127.0.0.1 - - [27/Aug/2018:09:18:37 +0200] "GET /helloworld/￭ﾕﾜ￪ﾸﾀ￬ﾝﾴ￫ﾦﾄ_test.html?param=￭ﾕﾜ￪ﾸﾀ￬ﾝﾴ￫ﾦﾄ_ahoy HTTP/2.0" 404 68 > {code} > however expected result should be similar to what we expect for HTTP, I guess. -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 1 month

1
0
0 / 0

[Red Hat JIRA] (WFLY-14378) Generic JMS RA fails to authenticate

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-14378?page=com.atlassian.jira.plugi... ] Brian Stansberry resolved WFLY-14378. ------------------------------------- Fix Version/s: 23.0.0.Beta1 22.0.1.Final Resolution: Done > Generic JMS RA fails to authenticate > ------------------------------------- > > Key: WFLY-14378 > URL: https://issues.redhat.com/browse/WFLY-14378 > Project: WildFly > Issue Type: Bug > Affects Versions: 22.0.0.Final > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Critical > Fix For: 23.0.0.Beta1, 22.0.1.Final > > > MDBs deployed in on WildFLy 22 using generic JMS resource adapter would fail to authenticate with external TIBCO broker due to missing password. > {noformat} > 2021-01-29 13:55:47,927 WARN [org.jboss.resource.adapter.jms.inflow.JmsActivation] (default-threads - 3) Failure in jms activation org.jboss.resource.adapter.jms.inflow.JmsActivationSpec@25f70034(ra=org.jboss.resource.adapter.jms.JmsResourceAdapter(a)4b294f76 destination=jms/topic/inTopic destinationType=javax.jms.Topic acknowledgeMode=Auto-acknowledge subscriptionDurability=false reconnectInterval=10 reconnectAttempts=-1 user=quickuser maxMessages=1 minSession=1 maxSession=15 connectionFactory=jms/cf/XATopicConnectionFactory jndiParameters={java.naming.provider.url=tcp://aza:7222, java.naming.factory.initial=com.tibco.tibjms.naming.TibjmsInitialContextFactory, java.naming.security.principal=quickuser, java.naming.security.credentials=<not shown>}): javax.jms.JMSSecurityException: authentication failed > at com.tibco.tibjms.Tibjmsx.buildException(Tibjmsx.java:744) > at com.tibco.tibjms.TibjmsConnection._create(TibjmsConnection.java:1465) > at com.tibco.tibjms.TibjmsConnection.<init>(TibjmsConnection.java:4412) > at com.tibco.tibjms.TibjmsXAConnection.<init>(TibjmsXAConnection.java:30) > at com.tibco.tibjms.TibjmsXATopicConnection.<init>(TibjmsXATopicConnection.java:29) > at com.tibco.tibjms.TibjmsxCFImpl._createImpl(TibjmsxCFImpl.java:147) > at com.tibco.tibjms.TibjmsxCFImpl._createConnection(TibjmsxCFImpl.java:255) > at com.tibco.tibjms.TibjmsXAConnectionFactory.createXAConnection(TibjmsXAConnectionFactory.java:61) > at org.jboss.resource.adapter.jms.inflow.JmsActivation.setupConnection(JmsActivation.java:442) > at org.jboss.resource.adapter.jms.inflow.JmsActivation.setupConnection(JmsActivation.java:417) > at org.jboss.resource.adapter.jms.inflow.JmsActivation.setupActivation(JmsActivation.java:316) > at org.jboss.resource.adapter.jms.inflow.JmsActivation.access$100(JmsActivation.java:58) > at org.jboss.resource.adapter.jms.inflow.JmsActivation$SetupActivation.run(JmsActivation.java:546) > at org.jboss.jca.core.workmanager.WorkWrapper.runWork(WorkWrapper.java:445) > at org.jboss.as.connector.services.workmanager.WildflyWorkWrapper.runWork(WildflyWorkWrapper.java:69) > at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223) > at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:29) > at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:789) > at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:44) > at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:809) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {noformat} > Authentication with TIBCO JNDI does works and JMS bridge would work only MDB are affected. > This is due to missing getter() method on JMSActivationSpect class. -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 1 month

1
0
0 / 0

[Red Hat JIRA] (ELY-2079) (7.3.z) ELY-2069 - JWT token validation uses int instead of long for the dates: exp (expiration) and nbf

by Ilia Vassilev (Jira)

Ilia Vassilev created ELY-2079: ---------------------------------- Summary: (7.3.z) ELY-2069 - JWT token validation uses int instead of long for the dates: exp (expiration) and nbf Key: ELY-2079 URL: https://issues.redhat.com/browse/ELY-2079 Project: WildFly Elytron Issue Type: Bug Components: Realms Affects Versions: 1.14.1.Final Reporter: Ilia Vassilev Assignee: Ilia Vassilev Fix For: 1.15.0.CR1 JwtValidator is reading the exp and nbf field as a Java int instead of long: [https://github.com/wildfly-security/wildfly-elytron/blob/master/auth/real...] This means the maximum expiration date is ~January 18, 2038. Also, with Javascript a NumericDate this would be a 64-bit value. The JWT spec also leaves open the possibility of a decimal value so that should possibly be accounted for. -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 1 month

1
0
0 / 0

[Red Hat JIRA] (WFLY-14386) SecurityBootstrapService should set TCCL before calling PolicyConfigurationFactory.getPolicyConfigurationFactory()

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-14386: --------------------------------------- Summary: SecurityBootstrapService should set TCCL before calling PolicyConfigurationFactory.getPolicyConfigurationFactory() Key: WFLY-14386 URL: https://issues.redhat.com/browse/WFLY-14386 Project: WildFly Issue Type: Bug Components: Security Reporter: Brian Stansberry Assignee: Darran Lofthouse This: https://github.com/wildfly/wildfly/blob/22.0.0.Final/security/subsystem/s... should be more like this: https://github.com/wildfly/wildfly/blob/22.0.0.Final/ee/src/main/java/org... They both deal with the 'org.jboss.as.security.jacc-module' but one sets the TCCL to its module and the other does not. SecurityBootstrapService not doing that means the module, if defined, has to be a dependency of the org.jboss.as.security module. Such a module would be custom, meaning the user is editing our module.xml, and we don't want that. -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 1 month

1
0
0 / 0

[Red Hat JIRA] (WFLY-14385) Ensure wildfly-clustering-server ProtoStream marshallers use valid protobuf encoding

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-14385: ----------------------------------- Summary: Ensure wildfly-clustering-server ProtoStream marshallers use valid protobuf encoding Key: WFLY-14385 URL: https://issues.redhat.com/browse/WFLY-14385 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 22.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Most ProtoStream marshallers in wildfly-clustering-server are adapted from Externalizers, and thus do not use valid protobuf encoding. -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 1 month

1
0
0 / 0

[Red Hat JIRA] (JGRP-2527) NPE if binding JGroups to an IP without interface

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/JGRP-2527?page=com.atlassian.jira.plugin... ] Pedro Ruivo updated JGRP-2527: ------------------------------ Affects Version/s: 4.2.9 > NPE if binding JGroups to an IP without interface > ------------------------------------------------- > > Key: JGRP-2527 > URL: https://issues.redhat.com/browse/JGRP-2527 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.2.9 > Reporter: Pedro Ruivo > Assignee: Bela Ban > Priority: Minor > > If you bind JGroups to 127.0.2.1 (or any IP without an interface, like 127.0.0.0/8 - loopback IP addresses (refers to self) RFC 5735), JGroups fails with an NPE: > {noformat} > Caused by: java.lang.NullPointerException > at org.jgroups.protocols.UDP.dumpSocketInfo(UDP.java:558) > at org.jgroups.protocols.UDP.createSockets(UDP.java:422) > at org.jgroups.protocols.UDP.start(UDP.java:292) > at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:868) > at org.jgroups.JChannel.startStack(JChannel.java:980) > at org.jgroups.JChannel._preConnect(JChannel.java:844) > at org.jgroups.JChannel.connect(JChannel.java:349) > at org.jgroups.JChannel.connect(JChannel.java:343) > {noformat} > The exception comes from this line: [https://github.com/belaban/JGroups/blob/4.x/src/org/jgroups/protocols/UDP...] > {{NetworkInterface.getByInetAddress(bind_addr)}} returns {{null}} since the IP does not have an interface. It would be nice to have a null check here to prevent the NPE. > This is useful for local testing when `port_range=0`. It allows having a dedicated IP for each JGroups instance. > Workaround: > The workaround requires you to create a virtual interface > {noformat} > sudo ifconfig lo:0 127.0.2.1 up > {noformat} -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 1 month

1
0
0 / 0

[Red Hat JIRA] (JGRP-2527) NPE if binding JGroups to an IP without interface

by Pedro Ruivo (Jira)

Pedro Ruivo created JGRP-2527: --------------------------------- Summary: NPE if binding JGroups to an IP without interface Key: JGRP-2527 URL: https://issues.redhat.com/browse/JGRP-2527 Project: JGroups Issue Type: Bug Reporter: Pedro Ruivo Assignee: Bela Ban If you bind JGroups to 127.0.2.1 (or any IP without an interface, like 127.0.0.0/8 - loopback IP addresses (refers to self) RFC 5735), JGroups fails with an NPE: {noformat} Caused by: java.lang.NullPointerException at org.jgroups.protocols.UDP.dumpSocketInfo(UDP.java:558) at org.jgroups.protocols.UDP.createSockets(UDP.java:422) at org.jgroups.protocols.UDP.start(UDP.java:292) at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:868) at org.jgroups.JChannel.startStack(JChannel.java:980) at org.jgroups.JChannel._preConnect(JChannel.java:844) at org.jgroups.JChannel.connect(JChannel.java:349) at org.jgroups.JChannel.connect(JChannel.java:343) {noformat} The exception comes from this line: [https://github.com/belaban/JGroups/blob/4.x/src/org/jgroups/protocols/UDP...] {{NetworkInterface.getByInetAddress(bind_addr)}} returns {{null}} since the IP does not have an interface. It would be nice to have a null check here to prevent the NPE. This is useful for local testing when `port_range=0`. It allows having a dedicated IP for each JGroups instance. Workaround: The workaround requires you to create a virtual interface {noformat} sudo ifconfig lo:0 127.0.2.1 up {noformat} -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 1 month

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 February 2021