July 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1278) Coverity static analysis: Dereference null return value in ServerAuthenticationContext (Elytron)

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/ELY-1278?page=com.atlassian.jira.plugin.s... ] Ilia Vassilev reassigned ELY-1278: ---------------------------------- Assignee: Ilia Vassilev (was: Darran Lofthouse) > Coverity static analysis: Dereference null return value in ServerAuthenticationContext (Elytron) > ------------------------------------------------------------------------------------------------ > > Key: ELY-1278 > URL: https://issues.jboss.org/browse/ELY-1278 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Martin Choma > Assignee: Ilia Vassilev > Priority: Critical > > Coverity found possible NPE occurense, as according to javadoc for {{SSLSession().getLocalCertificates()}} may return null [1], but {{X500.asX509CertificateArray}} can't consume null parameter and NPE will be thrown in that case. > {code:java|title=ServerAuthenticationContext.java} > } else if (callback instanceof SSLCallback) { > SSLCallback sslCallback = (SSLCallback) callback; > try { > peerCerts = X500.asX509CertificateArray(sslCallback.getSslSession().getPeerCertificates()); > } catch (SSLPeerUnverifiedException e) { > log.trace("Peer unverified", e); > peerCerts = null; > } > serverCerts = X500.asX509CertificateArray(sslCallback.getSslSession().getLocalCertificates()); > handleOne(callbacks, idx + 1); > } > {code} > https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=26379... > [1] https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSession.html#g... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3040) StepCapabilityStatus should take dynamic capability dependencies into account

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3040?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet updated WFCORE-3040: -------------------------------------- Summary: StepCapabilityStatus should take dynamic capability dependencies into account (was: StepCapabilityStatus should take capability dependencies into account) > StepCapabilityStatus should take dynamic capability dependencies into account > ----------------------------------------------------------------------------- > > Key: WFCORE-3040 > URL: https://issues.jboss.org/browse/WFCORE-3040 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta28 > Reporter: ehsavoie Hugonnet > Assignee: Brian Stansberry > > Currently at stage RUNTIME we check the stepCapabilityStatus before executing the OSH associated with a capability. But this check doesn't take into account the state of the capability dependencies. > For example if we add the undertow subsystem from scratch : the server service is not added because its capability is RELOAD_REQUIRED but when adding the listener the stepCapabilityStatus is NORMAL while it depends on a service that is in RELOAD_REQUIRED so is potentially not there (which is the case) thus the RUNTIME OSH will fail instead of being skipped. > Reproducer: > {code:java} > /extension=org.wildfly.extension.undertow:add(module="org.wildfly.extension.undertow") > /extension=org.wildfly.extension.io:add(module="org.wildfly.extension.io") > batch > /subsystem=undertow:add > /subsystem=undertow/servlet-container=default:add > /subsystem=undertow/server=default-server:add > /subsystem=undertow/server=default-server/host=default-host:add(alias=["localhost"]) > /subsystem=undertow/server=default-server/http-listener=default:add(socket-binding="http") > /subsystem=undertow/buffer-cache=default:add > /subsystem=undertow/configuration=handler:add > /subsystem=undertow/configuration=filter:add > /subsystem=io:add > /subsystem=io/buffer-pool=default:add > /subsystem=io/worker=default:add > /socket-binding-group=standard-sockets/socket-binding=http:add(port="\${jboss.http.port:8080}") > run-batch > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9048) MDB20TopicTestCase fails with security manager

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9048?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-9048: ------------------------------ Labels: security-manager (was: ) > MDB20TopicTestCase fails with security manager > ---------------------------------------------- > > Key: WFLY-9048 > URL: https://issues.jboss.org/browse/WFLY-9048 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 11.0.0.Beta1 > Reporter: Ondrej Kotek > Assignee: Tomaz Cerar > Labels: security-manager > > MDB20TopicTestCase fails with security manager: > {noformat} > java.io.IOException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.remoting3.security.RemotingPermission" "createEndpoint")" in code source "(vfs:/content/MDB20TopicTestCase.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.MDB20TopicTestCase.jar" from Service Module Loader") > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:149) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75) > at org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20TopicTestCase.getNumberOfAllSubscriptions(MDB20TopicTestCase.java:171) > ... > {noformat} > There are missing permissions {{RemotingPermission("createEndpoint")}}, {{RemotingPermission("connect")}}, and possibly others, and missing dependency on {{org.jboss.remoting3}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9048) MDB20TopicTestCase fails with security manager

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9048?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-9048: --------------------------------- Assignee: (was: Tomaz Cerar) > MDB20TopicTestCase fails with security manager > ---------------------------------------------- > > Key: WFLY-9048 > URL: https://issues.jboss.org/browse/WFLY-9048 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 11.0.0.Beta1 > Reporter: Ondrej Kotek > Labels: security-manager > > MDB20TopicTestCase fails with security manager: > {noformat} > java.io.IOException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.remoting3.security.RemotingPermission" "createEndpoint")" in code source "(vfs:/content/MDB20TopicTestCase.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.MDB20TopicTestCase.jar" from Service Module Loader") > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:149) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75) > at org.jboss.as.test.integration.ejb.mdb.ejb2x.MDB20TopicTestCase.getNumberOfAllSubscriptions(MDB20TopicTestCase.java:171) > ... > {noformat} > There are missing permissions {{RemotingPermission("createEndpoint")}}, {{RemotingPermission("connect")}}, and possibly others, and missing dependency on {{org.jboss.remoting3}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3040) StepCapabilityStatus should take capability dependencies into account

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3040?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet commented on WFCORE-3040: ------------------------------------------- It is related to the fact that the capability dependency is defined using dynamic dependencies (which is deprecated) and added at runtime in the ListenerAdd > StepCapabilityStatus should take capability dependencies into account > --------------------------------------------------------------------- > > Key: WFCORE-3040 > URL: https://issues.jboss.org/browse/WFCORE-3040 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta28 > Reporter: ehsavoie Hugonnet > Assignee: Brian Stansberry > > Currently at stage RUNTIME we check the stepCapabilityStatus before executing the OSH associated with a capability. But this check doesn't take into account the state of the capability dependencies. > For example if we add the undertow subsystem from scratch : the server service is not added because its capability is RELOAD_REQUIRED but when adding the listener the stepCapabilityStatus is NORMAL while it depends on a service that is in RELOAD_REQUIRED so is potentially not there (which is the case) thus the RUNTIME OSH will fail instead of being skipped. > Reproducer: > {code:java} > /extension=org.wildfly.extension.undertow:add(module="org.wildfly.extension.undertow") > /extension=org.wildfly.extension.io:add(module="org.wildfly.extension.io") > batch > /subsystem=undertow:add > /subsystem=undertow/servlet-container=default:add > /subsystem=undertow/server=default-server:add > /subsystem=undertow/server=default-server/host=default-host:add(alias=["localhost"]) > /subsystem=undertow/server=default-server/http-listener=default:add(socket-binding="http") > /subsystem=undertow/buffer-cache=default:add > /subsystem=undertow/configuration=handler:add > /subsystem=undertow/configuration=filter:add > /subsystem=io:add > /subsystem=io/buffer-pool=default:add > /subsystem=io/worker=default:add > /socket-binding-group=standard-sockets/socket-binding=http:add(port="\${jboss.http.port:8080}") > run-batch > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1650) Exclude the jsr94 from Drools build

by Ryan Zhang (JIRA)

Ryan Zhang created DROOLS-1650: ---------------------------------- Summary: Exclude the jsr94 from Drools build Key: DROOLS-1650 URL: https://issues.jboss.org/browse/DROOLS-1650 Project: Drools Issue Type: Bug Reporter: Ryan Zhang Assignee: Edson Tirelli This is requesting to retire jsr94 because we can't find the source code license information for it. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1649) Avoid using Class.forName in static factory methods

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-1649: ----------------------------------- Summary: Avoid using Class.forName in static factory methods Key: DROOLS-1649 URL: https://issues.jboss.org/browse/DROOLS-1649 Project: Drools Issue Type: Enhancement Components: core engine Reporter: Mario Fusco Assignee: Matteo Mortari All factory calls should go through the ServiceRegistryImpl instead of using Class.forName -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2201) TRACE is logged as INFO

by Jesper Blomquist (JIRA)

[ https://issues.jboss.org/browse/JGRP-2201?page=com.atlassian.jira.plugin.... ] Jesper Blomquist updated JGRP-2201: ----------------------------------- Description: In [Slf4jLogImpl|https://github.com/belaban/JGroups/blob/master/src/org/jgrou...], the formatting "trace" method forwards to {{logger.info(formatted)}} I would also love to se all formatting log methods check the log level before formatting (perhaps log level should always be checked before forwarding?). was: In Slf4jLogImpl, the formatting "[trace|https://github.com/belaban/JGroups/blob/master/src/org/jgroups/logg...]" method forwards to {{logger.info(formatted)}} I would also love to se all formatting log methods check the log level before formatting (perhaps log level should always be checked before forwarding?). > TRACE is logged as INFO > ----------------------- > > Key: JGRP-2201 > URL: https://issues.jboss.org/browse/JGRP-2201 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.1 > Reporter: Jesper Blomquist > Assignee: Bela Ban > Priority: Minor > > In [Slf4jLogImpl|https://github.com/belaban/JGroups/blob/master/src/org/jgrou...], the formatting "trace" method forwards to {{logger.info(formatted)}} > I would also love to se all formatting log methods check the log level before formatting (perhaps log level should always be checked before forwarding?). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2201) TRACE is logged as INFO

by Jesper Blomquist (JIRA)

Jesper Blomquist created JGRP-2201: -------------------------------------- Summary: TRACE is logged as INFO Key: JGRP-2201 URL: https://issues.jboss.org/browse/JGRP-2201 Project: JGroups Issue Type: Bug Affects Versions: 4.0.1 Reporter: Jesper Blomquist Assignee: Bela Ban Priority: Minor In Slf4jLogImpl, the formatting "[trace|https://github.com/belaban/JGroups/blob/master/src/org/jgroups/logg...]" method forwards to {{logger.info(formatted)}} I would also love to se all formatting log methods check the log level before formatting (perhaps log level should always be checked before forwarding?). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1645) Wildcard in packages does not work in Spring Boot jar

by Jacek Hola (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1645?page=com.atlassian.jira.plugi... ] Jacek Hola commented on DROOLS-1645: ------------------------------------ As you can see in the output you attached it loads from /home/mario/Downloads/droolsSpringBootIssue-master/build/resources/main. The problem exists when you launch the fat jar. You have to run the jar like this: {code} gradlew assemble java -jar build\libs\reproducer-1.0-SNAPSHOT.jar {code} > Wildcard in packages does not work in Spring Boot jar > ----------------------------------------------------- > > Key: DROOLS-1645 > URL: https://issues.jboss.org/browse/DROOLS-1645 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.0.0.Final > Reporter: Jacek Hola > Assignee: Mario Fusco > > In applications built with Spring Boot the resources under {{src/main/resources/}} are packed into jar in {{BOOT-INF/classes/}}. That's why when in {{kmodule.xml}} someone specifies > {code:xml} > <kbase name="base" default="true" packages="com.company.*"> > ... > </kbase> > {code} > then for example resource {{src/main/resources/com/company/rule.drl}} will not be picked up, because the path in jar(zip) is {{BOOT-INF/classes/com/company/rule.drl}}. > From my investigation it seems the logic in org.drools.compiler.kie.builder.impl.KieBuilderImpl#isFileInKieBase does not recognize these files as it compares the packages for equality or if one starts with the other. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 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 July 2017