December 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-3402) Encoding set in constructor not taking effect

by Barnabás Kurucz (Jira)

[ https://issues.jboss.org/browse/DROOLS-3402?page=com.atlassian.jira.plugi... ] Barnabás Kurucz reopened DROOLS-3402: ------------------------------------- Hi, thanks for having a look at this. After some further investigation it looks the issue can be reproduced only when the default system encoding is set to CP-1252. Since the system default was CP-1252, the JVM was running with that encoding and the KIE Resource also had used this encoding, even though I set UTF-8 in its conctructor. Once I changed the system default to UTF-8, the special characters (ä, etc.) were shown correctly. Could you have another look? > Encoding set in constructor not taking effect > --------------------------------------------- > > Key: DROOLS-3402 > URL: https://issues.jboss.org/browse/DROOLS-3402 > Project: Drools > Issue Type: Bug > Affects Versions: 7.13.0.Final > Reporter: Barnabás Kurucz > Assignee: Mario Fusco > Priority: Major > > In my drl file, I'm using German characters such as Umlauts or ß. Thus, I am setting the encoding to UTF-8 with the overloaded constructor when creating the Resource for the Kie File System. However, after firing the rules on the inserted Fact Drools does not seem to apply the specified encoding. I insert the fact, and if the condition is true to that fact it should modify the Action1 (String) attribute of the fact to "Rückfrage" and return the modified fact. However, when I look at the retrieved bean's Action1 attribute I am seeing "RÃ¼ckfrage" instead of "Rückfrage". I tried both UTF-8 and ISO-8859-1 encoding. Any ideas what's wrong? > Drools 7.13 > *KieSessionGenerator*: > public KieSessionGenerator() { > KieServices kieServices = KieServices.Factory.get(); > KieFileSystem kieFileSystem = kieServices.newKieFileSystem(); > kieFileSystem.write(ResourceFactory.newClassPathResource(drlFile, "UTF-8")); > KieBuilder kieBuilder = kieServices.newKieBuilder(kieFileSystem); > kieBuilder.buildAll(); > KieModule kieModule = kieBuilder.getKieModule(); > KieContainer kieContainer = kieServices.newKieContainer(kieModule.getReleaseId()); > kieSession = kieContainer.newKieSession(); > } > *Snippet from DRL:* > rule "813" > when > $bean : Bean(longDesc == "Infektion") > then > $bean.setAction1("Rückfrage"); > end > *Inserting the fact:* > public Bean lookupBean(Bean bean) { > kieSessionGenerator.getKieSession().insert(bean); > kieSessionGenerator.getKieSession().fireAllRules(); > return bean; > } -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3947) Support SSL Certificate revocation using OCSP

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFCORE-3947?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-3947: ------------------------------------- Fix Version/s: 8.0.0.Beta2 > Support SSL Certificate revocation using OCSP > --------------------------------------------- > > Key: WFCORE-3947 > URL: https://issues.jboss.org/browse/WFCORE-3947 > Project: WildFly Core > Issue Type: Task > Components: Security > Affects Versions: 6.0.0.Alpha2 > Reporter: Jan Kalina > Assignee: Martin Mazanek > Priority: Critical > Fix For: 8.0.0.Beta2 > > > - Provide undertow's client certificate revocation capability when undertow is used as a load balancer using OCSP. > (CRL capability is provided in the earlier release as part of Elytron SSL Consolidation effort that this JIRA is cloned from) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3947) Support SSL Certificate revocation using OCSP

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFCORE-3947?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-3947: ------------------------------------- Fix Version/s: 3.x.x TBD > Support SSL Certificate revocation using OCSP > --------------------------------------------- > > Key: WFCORE-3947 > URL: https://issues.jboss.org/browse/WFCORE-3947 > Project: WildFly Core > Issue Type: Task > Components: Security > Affects Versions: 6.0.0.Alpha2 > Reporter: Jan Kalina > Assignee: Martin Mazanek > Priority: Critical > Fix For: 8.0.0.Beta2 > > > - Provide undertow's client certificate revocation capability when undertow is used as a load balancer using OCSP. > (CRL capability is provided in the earlier release as part of Elytron SSL Consolidation effort that this JIRA is cloned from) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3947) Support SSL Certificate revocation using OCSP

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFCORE-3947?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-3947: ------------------------------------- Fix Version/s: (was: 3.x.x TBD) > Support SSL Certificate revocation using OCSP > --------------------------------------------- > > Key: WFCORE-3947 > URL: https://issues.jboss.org/browse/WFCORE-3947 > Project: WildFly Core > Issue Type: Task > Components: Security > Affects Versions: 6.0.0.Alpha2 > Reporter: Jan Kalina > Assignee: Martin Mazanek > Priority: Critical > Fix For: 8.0.0.Beta2 > > > - Provide undertow's client certificate revocation capability when undertow is used as a load balancer using OCSP. > (CRL capability is provided in the earlier release as part of Elytron SSL Consolidation effort that this JIRA is cloned from) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11123) Illegal reflective access by org.wildfly.extension.elytron.SSLDefinitions

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-11123?page=com.atlassian.jira.plugin... ] Darran Lofthouse commented on WFLY-11123: ----------------------------------------- Dropping to major, this method is presently available in the currently supported JVMs, additionally it fails safe if not. > Illegal reflective access by org.wildfly.extension.elytron.SSLDefinitions > ------------------------------------------------------------------------- > > Key: WFLY-11123 > URL: https://issues.jboss.org/browse/WFLY-11123 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 14.0.1.Final > Environment: Windows 7 x64. Java 11: OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11+28-201810022317, mixed mode) > Reporter: Marco Del Percio > Priority: Major > Labels: Java11, access, elytron, illegal, reflective, wildfly > > After configuring HTTPS using the following guide: [Enable One-way SSL/TLS for Applications|http://docs.wildfly.org/14/WildFly_Elytron_Security.html#con...], configuration seems ok and server boots fine however an illegal reflective access warning comes up from jar within Elytron: > {color:red} > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by org.wildfly.extension.elytron.SSLDefinitions (jar:file:/D:/wildfly-14.0.1.Final_FleetManager/modules/system/layers/base/org/wildfly/extension/elytron/main/wildfly-elytron-integration-6.0.2.Final.jar!/) to method com.sun.net.ssl.internal.ssl.Provider.isFIPS() > WARNING: Please consider reporting this to the maintainers of org.wildfly.extension.elytron.SSLDefinitions > WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations > WARNING: All illegal access operations will be denied in a future release > {color} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3947) Support SSL Certificate revocation using OCSP

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFCORE-3947?page=com.atlassian.jira.plugi... ] Darran Lofthouse reassigned WFCORE-3947: ---------------------------------------- Assignee: Martin Mazanek > Support SSL Certificate revocation using OCSP > --------------------------------------------- > > Key: WFCORE-3947 > URL: https://issues.jboss.org/browse/WFCORE-3947 > Project: WildFly Core > Issue Type: Task > Components: Security > Affects Versions: 6.0.0.Alpha2 > Reporter: Jan Kalina > Assignee: Martin Mazanek > Priority: Critical > Fix For: 8.0.0.Beta2 > > > - Provide undertow's client certificate revocation capability when undertow is used as a load balancer using OCSP. > (CRL capability is provided in the earlier release as part of Elytron SSL Consolidation effort that this JIRA is cloned from) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11123) Illegal reflective access by org.wildfly.extension.elytron.SSLDefinitions

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-11123?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFLY-11123: ------------------------------------ Priority: Major (was: Critical) > Illegal reflective access by org.wildfly.extension.elytron.SSLDefinitions > ------------------------------------------------------------------------- > > Key: WFLY-11123 > URL: https://issues.jboss.org/browse/WFLY-11123 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 14.0.1.Final > Environment: Windows 7 x64. Java 11: OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11+28-201810022317, mixed mode) > Reporter: Marco Del Percio > Priority: Major > Labels: Java11, access, elytron, illegal, reflective, wildfly > > After configuring HTTPS using the following guide: [Enable One-way SSL/TLS for Applications|http://docs.wildfly.org/14/WildFly_Elytron_Security.html#con...], configuration seems ok and server boots fine however an illegal reflective access warning comes up from jar within Elytron: > {color:red} > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by org.wildfly.extension.elytron.SSLDefinitions (jar:file:/D:/wildfly-14.0.1.Final_FleetManager/modules/system/layers/base/org/wildfly/extension/elytron/main/wildfly-elytron-integration-6.0.2.Final.jar!/) to method com.sun.net.ssl.internal.ssl.Provider.isFIPS() > WARNING: Please consider reporting this to the maintainers of org.wildfly.extension.elytron.SSLDefinitions > WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations > WARNING: All illegal access operations will be denied in a future release > {color} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9855) [JDK9+] org.jboss.security.negotiation.spnego package is exported by two jars

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-9855?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-9855: ---------------------------------------- Dropping the priority as a deprecated component used within the application server only. > [JDK9+] org.jboss.security.negotiation.spnego package is exported by two jars > ----------------------------------------------------------------------------- > > Key: WFLY-9855 > URL: https://issues.jboss.org/browse/WFLY-9855 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Tomaz Cerar > Assignee: Tomas Hofman > Priority: Major > > Currently if you have > jboss-negotiation-spnego-3.0.4.Final and jboss-negotiation-extras-3.0.4.Final.jar > on your module path, jvm complains as both jars export package org.jboss.security.negotiation.spnego > which violates the modules contract where only one module (jar) can provide single package. > example error that jvm prints > {noformat} > Error: Modules jboss.negotiation.extras and jboss.negotiation.spnego export package org.jboss.security.negotiation.spnego to module wildfly.clustering.common > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9855) [JDK9+] org.jboss.security.negotiation.spnego package is exported by two jars

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-9855?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-9855: ----------------------------------- Priority: Major (was: Critical) > [JDK9+] org.jboss.security.negotiation.spnego package is exported by two jars > ----------------------------------------------------------------------------- > > Key: WFLY-9855 > URL: https://issues.jboss.org/browse/WFLY-9855 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Tomaz Cerar > Assignee: Tomas Hofman > Priority: Major > > Currently if you have > jboss-negotiation-spnego-3.0.4.Final and jboss-negotiation-extras-3.0.4.Final.jar > on your module path, jvm complains as both jars export package org.jboss.security.negotiation.spnego > which violates the modules contract where only one module (jar) can provide single package. > example error that jvm prints > {noformat} > Error: Modules jboss.negotiation.extras and jboss.negotiation.spnego export package org.jboss.security.negotiation.spnego to module wildfly.clustering.common > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11510) EarOpenTracingWithWeldProbeTestCase fails with node0/1 set

by Nikoleta Žiaková (Jira)

[ https://issues.jboss.org/browse/WFLY-11510?page=com.atlassian.jira.plugin... ] Nikoleta Žiaková commented on WFLY-11510: ----------------------------------------- [~manovotn], [~okotek], you are right, setting {{-Dorg.jboss.weld.probe.allowRemoteAddress=${node0}}} solves the issue. node0 is set to 127.0.0.1 by default, which is also the default value of {{org.jboss.weld.probe.allowRemoteAddress}}, so the test was working in CI where node0 is not overridden. I suggest setting the Weld config option in [testsuite/pom.xml|https://github.com/wildfly/wildfly/blob/master/testsuit...]. > EarOpenTracingWithWeldProbeTestCase fails with node0/1 set > ---------------------------------------------------------- > > Key: WFLY-11510 > URL: https://issues.jboss.org/browse/WFLY-11510 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing, Test Suite > Affects Versions: 16.0.0.Beta1 > Reporter: Ondrej Kotek > Assignee: Nikoleta Žiaková > Priority: Major > > {{org.jboss.as.test.integration.microprofile.opentracing.EarOpenTracingWithWeldProbeTestCase}} fails with {{node0}} and {{node1}} set: > {noformat} > WARN [org.jboss.weld.probe.Probe] (default task-1) PROBE-000017: Access to /ServiceOne/service-endpoint/app denied for <my IP> > WARN [org.jboss.weld.probe.Probe] (default task-1) PROBE-000017: Access to /ServiceOne/service-endpoint/app denied for <my IP> > ... > java.lang.AssertionError: expected:<200> but was:<403> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at org.junit.Assert.assertEquals(Assert.java:631) > at org.jboss.as.test.integration.microprofile.opentracing.AbstractEarOpenTracingTestCase.testHttpInvokation(AbstractEarOpenTracingTestCase.java:67) > at org.jboss.as.test.integration.microprofile.opentracing.AbstractEarOpenTracingTestCase.testEarServicesUseDifferentTracersAfterReload(AbstractEarOpenTracingTestCase.java:59) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > ... > {noformat} > Maybe access from remote IP addresses is blocked in development mode. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 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 December 2018