February 2021 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (DROOLS-5991) [DMN Designer] Not able to open large dmn model

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-5991?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-5991: -------------------------------- Affects Version/s: 7.50.0.Final (was: 7.31.0.Final) > [DMN Designer] Not able to open large dmn model > ----------------------------------------------- > > Key: DROOLS-5991 > URL: https://issues.redhat.com/browse/DROOLS-5991 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.50.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Gomes > Priority: Critical > Labels: drools-tools > > With the attached DMN model, user is unable to do changes and save them. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5991) [DMN Designer] Not able to open large dmn model

by Jozef Marko (Jira)

Jozef Marko created DROOLS-5991: ----------------------------------- Summary: [DMN Designer] Not able to open large dmn model Key: DROOLS-5991 URL: https://issues.redhat.com/browse/DROOLS-5991 Project: Drools Issue Type: Bug Components: DMN Editor Affects Versions: 7.31.0.Final Reporter: Jozef Marko Assignee: Guilherme Gomes With the attached DMN model, user is unable to do changes and save them. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-13940) SingletonDeploymentJBossAllTestCase fails frequently in CI

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13940?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13940: ---------------------------------- Fix Version/s: 23.0.0.Beta1 > SingletonDeploymentJBossAllTestCase fails frequently in CI > ---------------------------------------------------------- > > Key: WFLY-13940 > URL: https://issues.redhat.com/browse/WFLY-13940 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 21.0.0.Beta1, 22.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > Fix For: 23.0.0.Beta1 > > > https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=... -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-13940) SingletonDeploymentJBossAllTestCase fails frequently in CI

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13940?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13940: ---------------------------------- Affects Version/s: 22.0.0.Final > SingletonDeploymentJBossAllTestCase fails frequently in CI > ---------------------------------------------------------- > > Key: WFLY-13940 > URL: https://issues.redhat.com/browse/WFLY-13940 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 21.0.0.Beta1, 22.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=... -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-13940) SingletonDeploymentJBossAllTestCase fails frequently in CI

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13940?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13940: ---------------------------------- Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/13628) > SingletonDeploymentJBossAllTestCase fails frequently in CI > ---------------------------------------------------------- > > Key: WFLY-13940 > URL: https://issues.redhat.com/browse/WFLY-13940 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 21.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=... -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 2 months

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 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)

5 years, 2 months

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)

5 years, 2 months

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)

5 years, 2 months

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)

5 years, 2 months

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)

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