[JBoss JIRA] (SECURITY-993) SimpleRole.hashCode NPE when a principal has the roles set to null
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/SECURITY-993?page=com.atlassian.jira.plug... ]
Ilia Vassilev commented on SECURITY-993:
----------------------------------------
PR sent: https://github.com/picketbox/picketbox/pull/81
> SimpleRole.hashCode NPE when a principal has the roles set to null
> ------------------------------------------------------------------
>
> Key: SECURITY-993
> URL: https://issues.jboss.org/browse/SECURITY-993
> Project: PicketBox
> Issue Type: Bug
> Components: Identity
> Affects Versions: PicketBox_5_1_0.Final
> Environment: Wild Fly Swarm 2018.2.0
> Reporter: Sergey Beryozkin
> Assignee: Ilia Vassilev
> Priority: Minor
> Fix For: PicketBox_5_1_1.Beta1
>
>
> If a principal is created with the roles set to null then NPE is reported back to the user during the authentication process:
> {noformat}
> java.lang.RuntimeException: java.lang.NullPointerException
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:140)
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:94)
> at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:167)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:245)
> ....
> Caused by: java.lang.NullPointerException
> at org.jboss.security.identity.plugins.SimpleRole.hashCode(SimpleRole.java:106)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10577) Undertow subsystem should not depend on clustering code.
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10577?page=com.atlassian.jira.plugin... ]
Paul Ferraro commented on WFLY-10577:
-------------------------------------
{quote}I can understand the dependency to org.wildfly.clustering.service for web cache thingie.
However org.jboss.as.clustering.common does not deal about that. It is an abstraction on top of the Core API, right?{quote}
The wildfly-clustering-service module depends primarily on jboss-msc and jboss-modules, and does not depend on anything from wildfly-core ^1^. The fundamental abstraction is ServiceConfigurator, which encapsulates the logic for configuring a service, the goal of which is to eliminate code duplication for services built by multiple subsystems. This module contains interfaces/class originally extracted from wildfly-clustering-common, and is as a dependency of the public API for building singleton services (i.e. org.wildfly.clustering.singleton.api).
The wildfly-clustering-common module (at least the stuff we're talking about) depends primarily on wildfly-clustering-service *and* wildfly-controller (from wildfly-core). The bulk of this module deals with simplifying subsystem development. However, there are a couple of interfaces that are specific used by the clustering SPIs that relate to building/configuring services whose dependencies require capability resolution. These really ought to be split out, either into a separate module (without "clustering" in the name), or (preferably) pulled into wildfly-controller (within core).
\[1] https://github.com/wildfly/wildfly/blob/master/servlet-feature-pack/src/m...
{quote}My concern is having subsystem code depends on another one for core features.{quote}
wildfly-clustering-common isn't a subsystem. It's just logic that was originally common to the clustering subsystems.
{quote}That makes the whole codebase harder to maintain as we have different ways to do the same thing (dealing with MSC Service in that case).{quote}
I understand the concern. I'll propose a solution at the end of my comments.
{quote}If the Core API (or the MSC Service API) does not provide the correct abstraction (or need another level of abstraction), these features should be done in a place that benefits all subsystems.{quote}
I completely agree. I proposed migrating some of its core abstractions to wildfly-core a couple of years ago, but we never reached a consensus.
{quote}By the way, the dependency from wildfly-undertow to wildfly-clustering-common is not direct and goes through wildfly-security > wildfly-clustering-infinispan-spi
\[...]
That's why I was not sure if the dependency was intentional or just a byproduct of being available...
{quote}
On the contrary - it's a direct dependency of the SPIs involved in clustering integration with wildfly-clustering-web-undertow. e.g.
https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org...
Here's what I would propose:
1. Extract the non-deprecated interfaces/classes for configuring services and registering dependencies from wildfly-clustering-service into a separate module, let's call it wildfly-service. Since this module has no dependencies on any module from wildfly or wildfly-core, this can either reside in a separate maven repo or within wildfly-core.
2. Extract the interfaces/classes from wildfly-clustering-common appropriate for inclusion into wildfly-controller (within wildfly-core), minimally:
* CapabilityServiceConfigurator (extends ServiceConfigurator adding ability to configure itself from an OperationContext, specifically to resolve names of dependencies provided by capabilities)
* ResourceServiceConfigurator (extends ServiceConfigurator adding ability to configure itself from an OperationContext and Resource model)
* ResourceServiceHandler (encapsulates logic for adding/removing services for a resource - this is logic that is normally duplicated between add/remove operation handlers)
* SimpleResourceServiceHandler (a ResourceServiceHandler that add/removes a single service using a ResourceServiceConfigurator)
* Skeleton add/remove/write-attribute OperationStepHandlers that leverage ResourceServiceHandler
* Binary/UnaryCapabilityNameResolver (common dynamic capability name mapper implementations - to be used in lieu of lambdas)
This would be sufficient to remove the undertow subsystem dependency on wildfly-clustering-common and wildfly-clustering-service. WDYT?
> Undertow subsystem should not depend on clustering code.
> --------------------------------------------------------
>
> Key: WFLY-10577
> URL: https://issues.jboss.org/browse/WFLY-10577
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Reporter: Jeff Mesnil
> Assignee: Paul Ferraro
>
> With WFLY-10352, Undertow subsystem now depends on Clustering code for Clustering's abstraction of the new MSC Service API. For example https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org...
> As far as I can tell, the org.jboss.as.clustering.common module is bundled in servlet-feature-pack just so Undertow extension can access its API.
> This is not correct. Undertow should not have to depend on clustering for this kind of abstraction.
> Either these abstractions should be provided by Core or they should not be allowed.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFWIP-20) [Artemis 2.x upgrade] Setting globalThreadPool size on client using system properties is ignored
by Justin Bertram (JIRA)
[ https://issues.jboss.org/browse/WFWIP-20?page=com.atlassian.jira.plugin.s... ]
Justin Bertram commented on WFWIP-20:
-------------------------------------
Despite the fact that the test passes with on Wildfly master, I still think there's a problem with the test. If {{testConnectionFactoryPools}} is executed last or not executed at all the other tests pass.
> [Artemis 2.x upgrade] Setting globalThreadPool size on client using system properties is ignored
> ------------------------------------------------------------------------------------------------
>
> Key: WFWIP-20
> URL: https://issues.jboss.org/browse/WFWIP-20
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
>
> Setting client globalThreadPoolSize for configuring max number of ActiveMQ-client-global-threads using system property or in connection factory which is looked up by standalone JMS client is ignored. There is alway 8 * number CPU cores.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (DROOLS-2532) UX design for scenario simulation
by Ron Murhammer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2532?page=com.atlassian.jira.plugi... ]
Ron Murhammer commented on DROOLS-2532:
---------------------------------------
[~uxdlc] Is there a link to the actual click through of the mockups? It used to be somewhere but now all I can find are the PDF versions.
> UX design for scenario simulation
> ---------------------------------
>
> Key: DROOLS-2532
> URL: https://issues.jboss.org/browse/DROOLS-2532
> Project: Drools
> Issue Type: Task
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: Appformer, UX, UXTeam
> Attachments: Proposed.pdf, Proposed_2.pdf
>
>
> As Aimee or Cameron I want to:
> * Easily create a test scenario template through the use of variable/data object placeholders so that I can create test scenarios against a single decision.
> * Define test scenarios through a UI so I can develop basic task scenarios with minimal engagement from IT.
> * Run a test scenario simulation so that I can verify the expected results against test simulation results.
> Verification conditions:
> Provide wireframe design and click-thru prototype which includes the following views:
> * Overview (properties)
> * Scenario Template
> * Scenarios Input Screen
> * Results
> * Code View
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (SECURITY-993) SimpleRole.hashCode NPE when a principal has the roles set to null
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/SECURITY-993?page=com.atlassian.jira.plug... ]
Ilia Vassilev moved WFLY-9902 to SECURITY-993:
----------------------------------------------
Project: PicketBox (was: WildFly)
Key: SECURITY-993 (was: WFLY-9902)
Workflow: classic default workflow (was: GIT Pull Request workflow )
Component/s: Identity
(was: Security)
> SimpleRole.hashCode NPE when a principal has the roles set to null
> ------------------------------------------------------------------
>
> Key: SECURITY-993
> URL: https://issues.jboss.org/browse/SECURITY-993
> Project: PicketBox
> Issue Type: Bug
> Components: Identity
> Affects Versions: PicketBox_5_1_0.Final
> Environment: Wild Fly Swarm 2018.2.0
> Reporter: Sergey Beryozkin
> Assignee: Ilia Vassilev
> Priority: Minor
> Fix For: PicketBox_5_1_1.Beta1
>
>
> If a principal is created with the roles set to null then NPE is reported back to the user during the authentication process:
> {noformat}
> java.lang.RuntimeException: java.lang.NullPointerException
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:140)
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:94)
> at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:167)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:245)
> ....
> Caused by: java.lang.NullPointerException
> at org.jboss.security.identity.plugins.SimpleRole.hashCode(SimpleRole.java:106)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (SECURITY-993) SimpleRole.hashCode NPE when a principal has the roles set to null
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/SECURITY-993?page=com.atlassian.jira.plug... ]
Ilia Vassilev updated SECURITY-993:
-----------------------------------
Affects Version/s: PicketBox_5_1_0.Final
> SimpleRole.hashCode NPE when a principal has the roles set to null
> ------------------------------------------------------------------
>
> Key: SECURITY-993
> URL: https://issues.jboss.org/browse/SECURITY-993
> Project: PicketBox
> Issue Type: Bug
> Components: Identity
> Affects Versions: PicketBox_5_1_0.Final
> Environment: Wild Fly Swarm 2018.2.0
> Reporter: Sergey Beryozkin
> Assignee: Ilia Vassilev
> Priority: Minor
> Fix For: PicketBox_5_1_1.Beta1
>
>
> If a principal is created with the roles set to null then NPE is reported back to the user during the authentication process:
> {noformat}
> java.lang.RuntimeException: java.lang.NullPointerException
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:140)
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:94)
> at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:167)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:245)
> ....
> Caused by: java.lang.NullPointerException
> at org.jboss.security.identity.plugins.SimpleRole.hashCode(SimpleRole.java:106)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (SECURITY-993) SimpleRole.hashCode NPE when a principal has the roles set to null
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/SECURITY-993?page=com.atlassian.jira.plug... ]
Ilia Vassilev updated SECURITY-993:
-----------------------------------
Fix Version/s: PicketBox_5_1_1.Beta1
> SimpleRole.hashCode NPE when a principal has the roles set to null
> ------------------------------------------------------------------
>
> Key: SECURITY-993
> URL: https://issues.jboss.org/browse/SECURITY-993
> Project: PicketBox
> Issue Type: Bug
> Components: Identity
> Affects Versions: PicketBox_5_1_0.Final
> Environment: Wild Fly Swarm 2018.2.0
> Reporter: Sergey Beryozkin
> Assignee: Ilia Vassilev
> Priority: Minor
> Fix For: PicketBox_5_1_1.Beta1
>
>
> If a principal is created with the roles set to null then NPE is reported back to the user during the authentication process:
> {noformat}
> java.lang.RuntimeException: java.lang.NullPointerException
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:140)
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:94)
> at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:167)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:245)
> ....
> Caused by: java.lang.NullPointerException
> at org.jboss.security.identity.plugins.SimpleRole.hashCode(SimpleRole.java:106)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-9902) SimpleRole.hashCode NPE when a principal has the roles set to null
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-9902?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev reassigned WFLY-9902:
-----------------------------------
Assignee: Ilia Vassilev
> SimpleRole.hashCode NPE when a principal has the roles set to null
> ------------------------------------------------------------------
>
> Key: WFLY-9902
> URL: https://issues.jboss.org/browse/WFLY-9902
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Environment: Wild Fly Swarm 2018.2.0
> Reporter: Sergey Beryozkin
> Assignee: Ilia Vassilev
> Priority: Minor
>
> If a principal is created with the roles set to null then NPE is reported back to the user during the authentication process:
> {noformat}
> java.lang.RuntimeException: java.lang.NullPointerException
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:140)
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:94)
> at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:167)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:245)
> ....
> Caused by: java.lang.NullPointerException
> at org.jboss.security.identity.plugins.SimpleRole.hashCode(SimpleRole.java:106)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (DROOLS-2587) Java 8 and Drools 7.5.0
by Gibran Castillo (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2587?page=com.atlassian.jira.plugi... ]
Gibran Castillo commented on DROOLS-2587:
-----------------------------------------
Everything works properly with drools 6.5.0 but it does not work with drools 7.0.0 and higher, same issues as drools 7.5.0
> Java 8 and Drools 7.5.0
> -----------------------
>
> Key: DROOLS-2587
> URL: https://issues.jboss.org/browse/DROOLS-2587
> Project: Drools
> Issue Type: Bug
> Components: decision tables
> Affects Versions: 7.5.0.Final
> Environment: Development
> Reporter: Gibran Castillo
> Assignee: Mario Fusco
> Labels: support
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> I upgraded my Drools 5.x (drools-compiler 5.2.1.Final, drools-decisiontables 5.4.0.Final, and drools-templates 5.4.0.Final; jbpm-flow 5.1.1.Final, jbpm-bmpn2 5.1.1.Final and with their respective dependencies) Java 1.7.0_21 job to drools 7.5.0 and use kie-api/kie-ci and Java 1.8.0_162; I had to do some refactoring because now drools is part of the KIE (Knowledge Is Everything) umbrella, specifically the code below:
> KieServices ks = KieServices.Factory.get();
> KieContainer kc = ks.getKieClasspathContainer();
> KieSession ks = kc.newKieSession("ksession-dtables"); //stateful session
> FactHandle fh = ks.insert(fact);
> ks.fireAllRules();
> ....
> I added the pom.properties file and kmodule.xml file. The java job builds successfully. When I run the java job the packages and rules are loaded into the Knowledge Base but only the first rules fire up and then it stops or ends.
> This seems to be a bug in the decision table (spreadsheet), it works with Java 7/Drools 5 but not with Java 8/Drools 7
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month