July 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SECURITY-864) NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration

by Philippe Marschall (JIRA)

[ https://issues.jboss.org/browse/SECURITY-864?page=com.atlassian.jira.plug... ] Philippe Marschall commented on SECURITY-864: --------------------------------------------- [~benze] {quote}I looked at your code in GitHub. Won't the exceptions thrown by the EmptyPolicy still cause the same slowdowns? Or is the exception thrown by WF simply limited to the fact that no policyRegistration is found (even though it is never actually used)?{quote} Yes that's what we observed, the policyRegistration is never actually used. We profiled the application afterwards and found no more exceptions raised during normal EJB processing. It was to be noted though that we use EJB remoting and not servlets so JACC can never really be called. However we now also provide a {{JBossPolicyRegistrationObjectFactory}} that registers a {{JBossPolicyRegistration}}. > NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration > ------------------------------------------------------------------------------------------------------- > > Key: SECURITY-864 > URL: https://issues.jboss.org/browse/SECURITY-864 > Project: PicketBox > Issue Type: Bug > Components: PicketBox > Reporter: Chao Wang > Assignee: Stefan Guilhen > > "NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration" is recorded in server.log during quickstart example run by changing log level: > {noformat} > <logger category="org.jboss.as.security"> > <level name="TRACE"/> > </logger> > <logger category="org.jboss.security"> > <level name="TRACE"/> > </logger> > {noformat} > See detailed description in community discussion [#907134|https://developer.jboss.org/message/907134] > I choose Jira component picketbox since the exception is titled as "PBOX000293: Exception caught: javax.naming.NameNotFoundException" -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1682) DMN Marshaller prefix preservation and minor improvements

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1682?page=com.atlassian.jira.plugi... ] Tibor Zimányi updated DROOLS-1682: ---------------------------------- Tester: Tibor Zimányi > DMN Marshaller prefix preservation and minor improvements > --------------------------------------------------------- > > Key: DROOLS-1682 > URL: https://issues.jboss.org/browse/DROOLS-1682 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > > Required: > * when a DMN xml file uses a prefix for the DMN namespace, such prefix is to be maintained while marshalling back to xml > Nice to have: > * additional attributes in the non-DMN namespace shall be preserved > * even if no extension elements converters are registered, it would be nice for the DMN-extension element itself to be preserved while marshalling back; especially for the case when it's an empty DMN-extension element element -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1682) DMN Marshaller prefix preservation and minor improvements

by Matteo Mortari (JIRA)

Matteo Mortari created DROOLS-1682: -------------------------------------- Summary: DMN Marshaller prefix preservation and minor improvements Key: DROOLS-1682 URL: https://issues.jboss.org/browse/DROOLS-1682 Project: Drools Issue Type: Bug Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari Required: * when a DMN xml file uses a prefix for the DMN namespace, such prefix is to be maintained while marshalling back to xml Nice to have: * additional attributes in the non-DMN namespace shall be preserved * even if no extension elements converters are registered, it would be nice for the DMN-extension element itself to be preserved while marshalling back; especially for the case when it's an empty DMN-extension element element -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1682) DMN Marshaller prefix preservation and minor improvements

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1682?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-1682: ----------------------------------- Sprint: 2017 Week 30-31 > DMN Marshaller prefix preservation and minor improvements > --------------------------------------------------------- > > Key: DROOLS-1682 > URL: https://issues.jboss.org/browse/DROOLS-1682 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > > Required: > * when a DMN xml file uses a prefix for the DMN namespace, such prefix is to be maintained while marshalling back to xml > Nice to have: > * additional attributes in the non-DMN namespace shall be preserved > * even if no extension elements converters are registered, it would be nice for the DMN-extension element itself to be preserved while marshalling back; especially for the case when it's an empty DMN-extension element element -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1681) Publish XSDs automatically for new Drools versions

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1681?page=com.atlassian.jira.plugi... ] Petr Široký commented on DROOLS-1681: ------------------------------------- [~mbiarnes] is this something you could possibly take a look at? > Publish XSDs automatically for new Drools versions > -------------------------------------------------- > > Key: DROOLS-1681 > URL: https://issues.jboss.org/browse/DROOLS-1681 > Project: Drools > Issue Type: Feature Request > Components: build > Affects Versions: 6.4.0.Final, 6.5.0.Final, 7.0.0.Final, 7.1.0.Final > Reporter: Russell Morrisey > Assignee: Petr Široký > > When a new Drools final version is released, the XSD should be published and uploaded automatically to the site. > Drools website is missing XSDs for 6.4, 6.5 and 7.x. The URL given in the kmodule.xml example files returns a 404 error. > Automation of the XSDs was previously discussed here: > https://github.com/kiegroup/droolsjbpm-build-bootstrap/pull/122/files -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1180) Migrate QE tests upstream.

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1180?page=com.atlassian.jira.plugi... ] Tibor Zimányi closed DROOLS-1180. --------------------------------- > Migrate QE tests upstream. > --------------------------- > > Key: DROOLS-1180 > URL: https://issues.jboss.org/browse/DROOLS-1180 > Project: Drools > Issue Type: Enhancement > Reporter: Tibor Zimányi > Assignee: Tibor Zimányi > Priority: Minor > > We have some regression tests in QE that could be migrated upstream. This is a tracking issue for this migration. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3108) Upgrade commons-logging-jboss-logmanager from 1.0.1.Final to 1.0.2.Final

by Kabir Khan (JIRA)

Kabir Khan created WFCORE-3108: ---------------------------------- Summary: Upgrade commons-logging-jboss-logmanager from 1.0.1.Final to 1.0.2.Final Key: WFCORE-3108 URL: https://issues.jboss.org/browse/WFCORE-3108 Project: WildFly Core Issue Type: Component Upgrade Components: Logging Reporter: James Perkins Assignee: James Perkins Upgrade commons-logging-jboss-logmanager from 1.0.1.Final to 1.0.2.Final. Only contains two commits. One is just a license fix and the other fixes an issue with reporting the correct caller for the log message. https://github.com/jboss-logging/commons-logging-jboss-logmanager/compare... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9138) Warning message mistake

by Baturman Şen (JIRA)

Baturman Şen created WFLY-9138: ---------------------------------- Summary: Warning message mistake Key: WFLY-9138 URL: https://issues.jboss.org/browse/WFLY-9138 Project: WildFly Issue Type: Bug Components: CDI / Weld Affects Versions: 10.1.0.Final Reporter: Baturman Şen Assignee: Stuart Douglas Priority: Trivial I am not native english speaker but, following warning message should be fixed. {panel:title=Original Message} 09:52:31,242 WARN [org.jboss.weld.deployer] (MSC service thread 1-5) WFLYWELD0013: Deployment deployment "xxxx" contains CDI annotations but no bean archive was not found. (No beans.xml nor class with bean defining annotations) {panel} {panel:title=Fixed Message} 09:52:31,242 WARN [org.jboss.weld.deployer] (MSC service thread 1-5) WFLYWELD0013: Deployment "xxxx" contains CDI annotations but no bean archive was found. (No beans.xml nor class with bean defining annotations) {panel} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9137) SSL tests in ElytronRemoteOutboundConnectionTestCase fails on IBM JDK

by Michal Jurc (JIRA)

[ https://issues.jboss.org/browse/WFLY-9137?page=com.atlassian.jira.plugin.... ] Michal Jurc moved JBEAP-12357 to WFLY-9137: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-9137 (was: JBEAP-12357) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Test Suite (was: Test Suite) Affects Version/s: (was: 7.1.0.ER2) > SSL tests in ElytronRemoteOutboundConnectionTestCase fails on IBM JDK > --------------------------------------------------------------------- > > Key: WFLY-9137 > URL: https://issues.jboss.org/browse/WFLY-9137 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Michal Jurc > Assignee: Michal Jurc > > Setup in SSL tests in {{ElytronRemoteOutboundConnectionTestCase}} fails with the following on IBM JDK: > {code}{ > "outcome" => "failed", > "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.key-manager.ejb-remote-tests-server-key-manager" => "java.security.NoSuchAlgorithmException: SunX509 KeyManagerFactory not available > Caused by: java.security.NoSuchAlgorithmException: SunX509 KeyManagerFactory not available"}}, > "rolled-back" => true > }{code} > The test runs with incorrect configuration then and therefore fails. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9136) Undertow is doubly URLDecoder.decode(ing) auth-method query parameters

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-9136: ------------------------------------ Summary: Undertow is doubly URLDecoder.decode(ing) auth-method query parameters Key: WFLY-9136 URL: https://issues.jboss.org/browse/WFLY-9136 Project: WildFly Issue Type: Bug Components: Web (Undertow) Affects Versions: 10.1.0.Final Reporter: Scott Stark Assignee: Stuart Douglas I'm testing a custom authentication mechanism that is passing in a PEM encoded public key that has been URL.encoded. I have attached the web.xml I'm using, but I have also created a simple standalone unit test that illustrates the issue. The org.wildfly.extension.undertow.deployment.AuthMethodParser.parse method calls io.undertow.util.QueryParameterUtils.parseQueryString to handle the parsing of the query string passed in with the auth-method name. This detects if there is a need to decode a parameter and does so. The resulting map of query properties is then again unconditionally decodes the values again by this loop in AuthMethodParser: {code:java} for (Map.Entry<String, Deque<String>> entry : props.entrySet()) { Deque<String> val = entry.getValue(); if (val.isEmpty()) { authMethodConfig.getProperties().put(URLDecoder.decode(entry.getKey(), UTF_8), ""); } else { authMethodConfig.getProperties().put(URLDecoder.decode(entry.getKey(), UTF_8), URLDecoder.decode(val.getFirst(), UTF_8)); } } {code} since the original value is a PEM encoded public key, it may contains '+' characters, and these then are incorrectly transformed into space characters. I would suggest that this second decoding step simply be dropped. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

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