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