June 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4987) Bump the Elytron subsystem version

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4987?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4987: -------------------------------- Component/s: Security > Bump the Elytron subsystem version > ---------------------------------- > > Key: WFCORE-4987 > URL: https://issues.redhat.com/browse/WFCORE-4987 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 13.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5004) TlsTestCase#testReloadTrustManager fails on IBM Java 8

by Ondrej Kotek (Jira)

Ondrej Kotek created WFCORE-5004: ------------------------------------ Summary: TlsTestCase#testReloadTrustManager fails on IBM Java 8 Key: WFCORE-5004 URL: https://issues.redhat.com/browse/WFCORE-5004 Project: WildFly Core Issue Type: Bug Components: Security Affects Versions: 13.0.0.Beta1 Reporter: Ondrej Kotek Assignee: Darran Lofthouse TlsTestCase#testReloadTrustManager fails on IBM Java 8 at [TlsTestCase.java#L439|https://github.com/wildfly/wildfly-core/blob/master...] reporting the same DN. When I try to compare using canonical names, there is a difference. Using RFC1779 or RFC2253 names is ok. {noformat} Assert.assertEquals(originalFoundDN.getIssuerX500Principal().getName(X500Principal.CANONICAL), ISSUER_DN.getName(X500Principal.CANONICAL)); [ERROR] TlsTestCase.testReloadTrustManager:439 expected:<....2.840.113549.1.9.1=[#1613656c7974726f6e4077696c64666c792e6f7267],c=uk,st=elytron,cn=...> but was:<....2.840.113549.1.9.1=[elytron@wildfly.org],c=uk,st=elytron,cn=...> {noformat} Is it just a test issue, or can there be an impact on functionality? In case it's just a test issue, can we assert equality of names? I.e. {noformat} Assert.assertEquals(originalFoundDN.getIssuerX500Principal().getName(), ISSUER_DN.getName()); {noformat} The same for [TlsTestCase.java#L465|https://github.com/wildfly/wildfly-core/blob/master...] then. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1994) Ensure the Elytron build works on Java 14

by Darran Lofthouse (Jira)

Darran Lofthouse created ELY-1994: ------------------------------------- Summary: Ensure the Elytron build works on Java 14 Key: ELY-1994 URL: https://issues.redhat.com/browse/ELY-1994 Project: WildFly Elytron Issue Type: Task Components: Testsuite Reporter: Darran Lofthouse Fix For: 1.13.0.CR2 Overall the build is not doing too badly and doesn't fail until we get to the main testsuite. {code:java} [INFO] WildFly Elytron - Tests ............................ FAILURE [ 1.447 s] [INFO] WildFly Elytron .................................... SKIPPED [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 01:46 min [INFO] Finished at: 2020-06-11T11:25:23+01:00 [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0-jboss-1:testCompile (default-testCompile) on project wildfly-elytron-tests: Compilation failure: Compilation failure: [ERROR] /home/darranl/src/community/wildfly-elytron/tests/base/src/test/java/org/wildfly/security/auth/TestLoginModule.java:[31,25] package java.security.acl does not exist [ERROR] /home/darranl/src/community/wildfly-elytron/tests/base/src/test/java/org/wildfly/security/auth/TestLoginModule.java:[107,40] cannot find symbol [ERROR] symbol: class Group [ERROR] location: class org.wildfly.security.auth.TestLoginModule [ERROR] -> [Help 1] {code} If this is all that is failing for us maybe we can revisit the test and see how appropriate it is and if it can be adapted to use available APIs. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13471) Warn the ws deployment packaged with JAXP implementation

by Jim Ma (Jira)

[ https://issues.redhat.com/browse/WFLY-13471?page=com.atlassian.jira.plugi... ] Jim Ma updated WFLY-13471: -------------------------- Summary: Warn the ws deployment packaged with JAXP implementation (was: Fail the ws deployment packaged with JAXP implementation) > Warn the ws deployment packaged with JAXP implementation > -------------------------------------------------------- > > Key: WFLY-13471 > URL: https://issues.redhat.com/browse/WFLY-13471 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 19.1.0.Final > Reporter: Jim Ma > Assignee: Jim Ma > Priority: Major > Fix For: 21.0.0.Beta1 > > > Deploy JAXWS application that packages an older JAXP implementation. > Try to get the wsdl: wget http://localhost:8080/helloWorld?wsdl > When the container is performing operations, it should use the container's JAXP implementation, else it could fail if the application is packaging a version that is not compatible. > {code} > 19:28:42,560 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.3.0.GA (WildFly Core 10.1.2.Final-redhat-00001) started in 4091ms - Started 426 of 652 services (374 services are lazy, passive or on-demand) > 19:28:45,537 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /helloWorld: java.lang.AbstractMethodError: org.apache.xerces.dom.DeferredDocumentImpl.setXmlStandalone(Z)V > at org.apache.cxf.frontend.WSDLGetUtils.updateDoc(WSDLGetUtils.java:332) > at org.apache.cxf.frontend.WSDLGetUtils.writeWSDLDocument(WSDLGetUtils.java:708) > at org.apache.cxf.frontend.WSDLGetUtils.getDocument(WSDLGetUtils.java:151) > at org.apache.cxf.frontend.WSDLGetInterceptor.getDocument(WSDLGetInterceptor.java:129) > at org.apache.cxf.frontend.WSDLGetInterceptor.handleMessage(WSDLGetInterceptor.java:77) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) > at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267) > at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:110) > at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:134) > at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:301) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:225) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:503) > at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136) > at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:590) > ... > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9129) Setting env var SECMGR=true no longer works

by Lukas Vydra (Jira)

[ https://issues.redhat.com/browse/WFLY-9129?page=com.atlassian.jira.plugin... ] Lukas Vydra commented on WFLY-9129: ----------------------------------- Hi [~rsearls], are you still able to reproduce it? I have created a small reproducer ([https://github.com/lvydra/wfly-9129-reproducer]) servlet, which is proving that enabling a security manager is working. > Setting env var SECMGR=true no longer works > ------------------------------------------- > > Key: WFLY-9129 > URL: https://issues.redhat.com/browse/WFLY-9129 > Project: WildFly > Issue Type: Bug > Components: Security Manager > Affects Versions: 10.0.0.Final, 10.1.0.Final, 11.0.0.Alpha1 > Reporter: r searls > Assignee: Lukas Vydra > Priority: Major > > Setting env var SECMGR=true is suppose to enable the security manager. > It is not working. I've tried the following and none of them enable > the security manager. > export SECMGR=true; > on the cmd-line -DSECMGR=true > edit bin/standalone.conf and uncomment line SECMGR="true" -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5428) DMN extended "invoke()" function to be enlisted as deprecated

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-5428: -------------------------------------- Summary: DMN extended "invoke()" function to be enlisted as deprecated Key: DROOLS-5428 URL: https://issues.redhat.com/browse/DROOLS-5428 Project: Drools Issue Type: Task Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5427) Update Type in Traffic Violation example

by Anna Dupliak (Jira)

Anna Dupliak created DROOLS-5427: ------------------------------------ Summary: Update Type in Traffic Violation example Key: DROOLS-5427 URL: https://issues.redhat.com/browse/DROOLS-5427 Project: Drools Issue Type: Task Components: Scenario Simulation and Testing Affects Versions: 7.38.0.Final Reporter: Anna Dupliak Assignee: Anna Dupliak Since we changed a constraints type mechanism we the old test scenario got failing So need to recreate scesim file in Traffic Violation example. workarounds: if you recreate scesim if you remove that column and add it again, no error is raised -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4446) Confusing scenario validation message for collection types

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4446?page=com.atlassian.jira.plug... ] Jozef Marko closed DROOLS-4446. ------------------------------- Fix Version/s: 7.39.0.Final Resolution: Out of Date Thank you [~yamer]. I can confirm this is not reproducible anymore. Closing. > Confusing scenario validation message for collection types > ---------------------------------------------------------- > > Key: DROOLS-4446 > URL: https://issues.redhat.com/browse/DROOLS-4446 > Project: Drools > Issue Type: Enhancement > Components: Scenario Simulation and Testing > Affects Versions: 7.26.0.Final > Reporter: Jozef Marko > Assignee: Yeser Amer > Priority: Minor > Labels: drools-tools > Fix For: 7.39.0.Final > > Attachments: Screenshot from 2019-08-20 10-19-46.png, Screenshot from 2020-06-10 16-24-49.png > > > There is small enhancement needed if the user validates dmn scenario with *collection* data type, being previously simple data type. > h2. Steps to reproduce > - Create new DMN > - Define there custom data type *LKW:string* > - Set this LKW type for some *input data* node > - Save DMN > - Create a Scenario for this DMN > - Go back to DMN > - Check tickbox *Is Collection* for the *LKW* type > - Save DMN > - Validate Scenario, you will get message as shown in the picture. It can be confusing as it says *LKW* changed to *LKW* -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1618) missingMessageReceived() never called in NAKACK resulting in memory leak

by Senthil SP (Jira)

[ https://issues.redhat.com/browse/JGRP-1618?page=com.atlassian.jira.plugin... ] Senthil SP edited comment on JGRP-1618 at 6/11/20 1:26 AM: ----------------------------------------------------------- [~bbn-tlv] [~belaban] - We are also facing exactly the same issue, but the messages accumulate in xmit_table instead of xmit_stats. was (Author: senthil.aru): [~bbn-tlv] [~belaban] - We are also facing exactly the same issue, but the messages accumulates in xmit_table instead of xmit_stats. > missingMessageReceived() never called in NAKACK resulting in memory leak > ------------------------------------------------------------------------ > > Key: JGRP-1618 > URL: https://issues.redhat.com/browse/JGRP-1618 > Project: JGroups > Issue Type: Bug > Affects Versions: 2.8.1, 2.12.2 > Environment: Java 6 > Reporter: Harry Mark > Assignee: Bela Ban > Priority: Major > Fix For: 3.2.9, 3.3 > > Attachments: 1618-jgrp-patch.jar, NakReceiverWindow.java, screenshot-1.png > > > We are using JGroups 2.8.1 and encountered a memory leak where it eventually ran out of CMS Old Gen memory. The heap dump revealed that the problem was in the xmit_stats ConcurrentHashMap of org.jgroups.protocols.pbcast.NAKACK. > After much analysis here's what we found: when the system is under load, messages can start arriving out of order. When the receiver receives a higher sequence number than expected, it requests the sender retransmit the missing messages with the lower sequence numbers. The sender sends the missing message, however the bug in the NakReceiverWindow meant that the missing message was never purged from the Map that tracks missing messages (xmit_stats) because missingMessageReceived() was never invoked. Over time this Map grows and starts using up CMS Old Gen; the only way it would get reduced was when a server left the cluster and the missing messages were purged for that server. > In JMX, the MissingMsgsReceived attribute of jgroups:cluster=*,protocol=NAKACK,type=protocol was always zero, confirming that it never purged any received "missing messages". > When I looked at the most recent GA version 3.2.8 of NakReceiverWindow.java , it has the corrected logic that ensures that missingMessageReceived() is called. I checked the the most recent 2.x, which is 2.12.2, and found it also has the same bug in the logic as 2.8.1. This bug may apply to other 2.x but I did not check. > Attached is the fixed NakReceiverWindow.java for 2.8.1. > After applying the patch, the memory leak went away. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1618) missingMessageReceived() never called in NAKACK resulting in memory leak

by Senthil SP (Jira)

[ https://issues.redhat.com/browse/JGRP-1618?page=com.atlassian.jira.plugin... ] Senthil SP commented on JGRP-1618: ---------------------------------- [~bbn-tlv] [~belaban] - Exactly the same issue, but the messages accumulates in xmit_table instead of xmit_stats. > missingMessageReceived() never called in NAKACK resulting in memory leak > ------------------------------------------------------------------------ > > Key: JGRP-1618 > URL: https://issues.redhat.com/browse/JGRP-1618 > Project: JGroups > Issue Type: Bug > Affects Versions: 2.8.1, 2.12.2 > Environment: Java 6 > Reporter: Harry Mark > Assignee: Bela Ban > Priority: Major > Fix For: 3.2.9, 3.3 > > Attachments: 1618-jgrp-patch.jar, NakReceiverWindow.java, screenshot-1.png > > > We are using JGroups 2.8.1 and encountered a memory leak where it eventually ran out of CMS Old Gen memory. The heap dump revealed that the problem was in the xmit_stats ConcurrentHashMap of org.jgroups.protocols.pbcast.NAKACK. > After much analysis here's what we found: when the system is under load, messages can start arriving out of order. When the receiver receives a higher sequence number than expected, it requests the sender retransmit the missing messages with the lower sequence numbers. The sender sends the missing message, however the bug in the NakReceiverWindow meant that the missing message was never purged from the Map that tracks missing messages (xmit_stats) because missingMessageReceived() was never invoked. Over time this Map grows and starts using up CMS Old Gen; the only way it would get reduced was when a server left the cluster and the missing messages were purged for that server. > In JMX, the MissingMsgsReceived attribute of jgroups:cluster=*,protocol=NAKACK,type=protocol was always zero, confirming that it never purged any received "missing messages". > When I looked at the most recent GA version 3.2.8 of NakReceiverWindow.java , it has the corrected logic that ensures that missingMessageReceived() is called. I checked the the most recent 2.x, which is 2.12.2, and found it also has the same bug in the logic as 2.8.1. This bug may apply to other 2.x but I did not check. > Attached is the fixed NakReceiverWindow.java for 2.8.1. > After applying the patch, the memory leak went away. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

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 June 2020