[JBoss JIRA] (WFCORE-1842) Support RBAC based on raw roles from an Identity
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1842?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-1842:
-------------------------------------
Fix Version/s: 3.0.0.Alpha13
> Support RBAC based on raw roles from an Identity
> -------------------------------------------------
>
> Key: WFCORE-1842
> URL: https://issues.jboss.org/browse/WFCORE-1842
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Security
> Reporter: Pedro Igor
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Alpha13
>
>
> Currently, RBAC requires a static mapping between standard roles and raw roles from an identity.
> We should be able to use RBAC without necessarily forcing this static mapping and just consider the raw roles from the identity.
> This issue may be related with exposing {{org.jboss.as.controller.access.management.WritableAuthorizerConfiguration#useRealmRoles}} in the management model.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 6 months
[JBoss JIRA] (JGRP-2128) MERGE3: incorrect merge
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2128?page=com.atlassian.jira.plugin.... ]
Bela Ban closed JGRP-2128.
--------------------------
Resolution: Won't Fix
> MERGE3: incorrect merge
> -----------------------
>
> Key: JGRP-2128
> URL: https://issues.jboss.org/browse/JGRP-2128
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Labels: CR3
> Fix For: 3.6.12, 4.0
>
> Attachments: BrokerPE-0.zip, SEM03VVM-201.zip, SEM03VVM-202.zip
>
>
> The following merge is incorrect, investigate what the desired behavior should be.
> Link: http://stackoverflow.com/questions/40492204/incorrect-merge-views-with-in...
> {noformat}
> (Incoming-1,BrokerPE-0-28575) ISPN000094: Received new cluster view for channel ISPN: [BrokerPE-0-28575|2] (3) [BrokerPE-0-28575, SEM03VVM-201-59385, SEM03VVM-202-33714]
> ISPN000094: Received new cluster view for channel ISPN: [BrokerPE-0-28575|3] (2) [BrokerPE-0-28575, SEM03VVM-202-33714] --> one node disconnected
> ISPN000093: Received new, MERGED cluster view for channel ISPN: MergeView::[BrokerPE-0-28575|4] (2) [BrokerPE-0-28575, SEM03VVM-201-59385], 2 subgroups: [BrokerPE-0-28575|3] (2) [BrokerPE-0-28575, SEM03VVM-202-33714], [BrokerPE-0-28575|2] (3) [BrokerPE-0-28575, SEM03VVM-201-59385, SEM03VVM-202-33714] --> incorrect merge
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 6 months
[JBoss JIRA] (JGRP-2128) MERGE3: incorrect merge
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2128?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2128:
--------------------------------
Didn't you see the following warning?
{code:java}
if(internal_thread_pool_min_threads < 2)
log.warn("The internal thread pool was configured with only %d min_threads; this might lead to problems " +
"when more than 1 thread is needed, e.g. when merging", internal_thread_pool_min_threads);
{code}
OK, I'm closing this issue.
> MERGE3: incorrect merge
> -----------------------
>
> Key: JGRP-2128
> URL: https://issues.jboss.org/browse/JGRP-2128
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Labels: CR3
> Fix For: 3.6.12, 4.0
>
> Attachments: BrokerPE-0.zip, SEM03VVM-201.zip, SEM03VVM-202.zip
>
>
> The following merge is incorrect, investigate what the desired behavior should be.
> Link: http://stackoverflow.com/questions/40492204/incorrect-merge-views-with-in...
> {noformat}
> (Incoming-1,BrokerPE-0-28575) ISPN000094: Received new cluster view for channel ISPN: [BrokerPE-0-28575|2] (3) [BrokerPE-0-28575, SEM03VVM-201-59385, SEM03VVM-202-33714]
> ISPN000094: Received new cluster view for channel ISPN: [BrokerPE-0-28575|3] (2) [BrokerPE-0-28575, SEM03VVM-202-33714] --> one node disconnected
> ISPN000093: Received new, MERGED cluster view for channel ISPN: MergeView::[BrokerPE-0-28575|4] (2) [BrokerPE-0-28575, SEM03VVM-201-59385], 2 subgroups: [BrokerPE-0-28575|3] (2) [BrokerPE-0-28575, SEM03VVM-202-33714], [BrokerPE-0-28575|2] (3) [BrokerPE-0-28575, SEM03VVM-201-59385, SEM03VVM-202-33714] --> incorrect merge
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 6 months
[JBoss JIRA] (JGRP-2128) MERGE3: incorrect merge
by Anjith Paila (JIRA)
[ https://issues.jboss.org/browse/JGRP-2128?page=com.atlassian.jira.plugin.... ]
Anjith Paila commented on JGRP-2128:
------------------------------------
You could actually close this bug. It turned out that we set the following property value to just 1: internal_thread_pool.min_threads. It looks like this this property value should be more than in order for the MERGE protocol to work.I feel this should be documented well to avoid any confusion.
> MERGE3: incorrect merge
> -----------------------
>
> Key: JGRP-2128
> URL: https://issues.jboss.org/browse/JGRP-2128
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Labels: CR3
> Fix For: 3.6.12, 4.0
>
> Attachments: BrokerPE-0.zip, SEM03VVM-201.zip, SEM03VVM-202.zip
>
>
> The following merge is incorrect, investigate what the desired behavior should be.
> Link: http://stackoverflow.com/questions/40492204/incorrect-merge-views-with-in...
> {noformat}
> (Incoming-1,BrokerPE-0-28575) ISPN000094: Received new cluster view for channel ISPN: [BrokerPE-0-28575|2] (3) [BrokerPE-0-28575, SEM03VVM-201-59385, SEM03VVM-202-33714]
> ISPN000094: Received new cluster view for channel ISPN: [BrokerPE-0-28575|3] (2) [BrokerPE-0-28575, SEM03VVM-202-33714] --> one node disconnected
> ISPN000093: Received new, MERGED cluster view for channel ISPN: MergeView::[BrokerPE-0-28575|4] (2) [BrokerPE-0-28575, SEM03VVM-201-59385], 2 subgroups: [BrokerPE-0-28575|3] (2) [BrokerPE-0-28575, SEM03VVM-202-33714], [BrokerPE-0-28575|2] (3) [BrokerPE-0-28575, SEM03VVM-201-59385, SEM03VVM-202-33714] --> incorrect merge
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 6 months
[JBoss JIRA] (JBLOGGING-126) log4j detection broken in OSGi
by Jens Reimann (JIRA)
[ https://issues.jboss.org/browse/JBLOGGING-126?page=com.atlassian.jira.plu... ]
Jens Reimann commented on JBLOGGING-126:
----------------------------------------
Created PR: https://github.com/jboss-logging/jboss-logging/pull/24
> log4j detection broken in OSGi
> ------------------------------
>
> Key: JBLOGGING-126
> URL: https://issues.jboss.org/browse/JBLOGGING-126
> Project: JBoss Logging
> Issue Type: Bug
> Components: jboss-logging-log4j
> Affects Versions: 3.3.0.Final
> Environment: OSGi, tested on Equinox 3.11.1
> Reporter: Jens Reimann
> Assignee: James Perkins
>
> This was introduced by a change in JBLOGGING-94
> The test for log4j was changed from:
> {code:java}
> Class.forName("org.apache.log4j.Hierarchy", true, cl);
> {code}
> to:
> {code:java}
> Class.forName("org.apache.log4j.config.PropertySetter", true, cl);
> {code}
> However the OSGi package imports where not updated to also include "{{org.apache.log4j.config}}". And this the latter test for "{{PropertySetter}}" will always fail in OSGi.
> The fix should be pretty simple. Simply import "{{org.apache.log4j.config}}" as optional in addition.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 6 months
[JBoss JIRA] (DROOLS-1366) Cannot access remote KIE maven repo - Unauthorized access 401
by Sambhaji Biradar (JIRA)
Sambhaji Biradar created DROOLS-1366:
----------------------------------------
Summary: Cannot access remote KIE maven repo - Unauthorized access 401
Key: DROOLS-1366
URL: https://issues.jboss.org/browse/DROOLS-1366
Project: Drools
Issue Type: Bug
Components: kie server
Reporter: Sambhaji Biradar
Assignee: Edson Tirelli
Using the latest 6.5 version, we are getting unauthorized access error. From the other posts I see that this issue was resolved in earlier versions but wondering if this issue was introduced again in 6.5. I tried this solution with no success - https://issues.jboss.org/browse/DROOLS-436.
Could someone help resolving the issue please?
#NOTE: This is an Aether internal implementation file, its format can be changed without prior notice.
#Mon Nov 21 19:20:51 EST 2016
maven-metadata-central.xml.error=Could not transfer metadata com.xxx.xxx.ruleengine\:fraudrules\:1.1-SNAPSHOT/maven-metadata.xml from/to central (http\://repo1.maven.org/maven2/)\: Connect to repo1.maven.org\:80 timed out
maven-metadata-guvnor-m2-repo.xml.error=Could not transfer metadata com.xxx.xxx.ruleengine\:rules\:1.1-SNAPSHOT/maven-metadata.xml from/to guvnor-m2-repo (http\://10.xxx.77.xxx\:8080/kie-drools-wb/maven2/)\: Unauthorized (401)
maven-metadata-workbench.xml.lastUpdated=1479774051131
maven-metadata-guvnor-m2-repo.xml/@default-guvnor-m2-repo-http\://10.xxx.77.xxx\:8080/kie-drools-wb/maven2/.lastUpdated=1479774051096
maven-metadata-central.xml/@default-central-http\://repo1.maven.org/maven2/.lastUpdated=1479774050359
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 6 months
[JBoss JIRA] (JBLOGGING-126) log4j detection broken in OSGi
by Jens Reimann (JIRA)
[ https://issues.jboss.org/browse/JBLOGGING-126?page=com.atlassian.jira.plu... ]
Jens Reimann commented on JBLOGGING-126:
----------------------------------------
I just looked into the package import declaration:
{code:xml}
<Import-Package>
*;resolution:=optional
</Import-Package>
{code}
This won't catch any calls to {{Class.formName(…)}}. So an explicit import is required here.
> log4j detection broken in OSGi
> ------------------------------
>
> Key: JBLOGGING-126
> URL: https://issues.jboss.org/browse/JBLOGGING-126
> Project: JBoss Logging
> Issue Type: Bug
> Components: jboss-logging-log4j
> Affects Versions: 3.3.0.Final
> Environment: OSGi, tested on Equinox 3.11.1
> Reporter: Jens Reimann
> Assignee: James Perkins
>
> This was introduced by a change in JBLOGGING-94
> The test for log4j was changed from:
> {code:java}
> Class.forName("org.apache.log4j.Hierarchy", true, cl);
> {code}
> to:
> {code:java}
> Class.forName("org.apache.log4j.config.PropertySetter", true, cl);
> {code}
> However the OSGi package imports where not updated to also include "{{org.apache.log4j.config}}". And this the latter test for "{{PropertySetter}}" will always fail in OSGi.
> The fix should be pretty simple. Simply import "{{org.apache.log4j.config}}" as optional in addition.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 6 months
[JBoss JIRA] (JBLOGGING-126) log4j detection broken in OSGi
by Jens Reimann (JIRA)
Jens Reimann created JBLOGGING-126:
--------------------------------------
Summary: log4j detection broken in OSGi
Key: JBLOGGING-126
URL: https://issues.jboss.org/browse/JBLOGGING-126
Project: JBoss Logging
Issue Type: Bug
Components: jboss-logging-log4j
Affects Versions: 3.3.0.Final
Environment: OSGi, tested on Equinox 3.11.1
Reporter: Jens Reimann
Assignee: James Perkins
This was introduced by a change in JBLOGGING-94
The test for log4j was changed from:
{code:java}
Class.forName("org.apache.log4j.Hierarchy", true, cl);
{code}
to:
{code:java}
Class.forName("org.apache.log4j.config.PropertySetter", true, cl);
{code}
However the OSGi package imports where not updated to also include "{{org.apache.log4j.config}}". And this the latter test for "{{PropertySetter}}" will always fail in OSGi.
The fix should be pretty simple. Simply import "{{org.apache.log4j.config}}" as optional in addition.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 6 months
[JBoss JIRA] (DROOLS-744) Rule Generation Feature Request
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-744?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer updated DROOLS-744:
------------------------------------------
Fix Version/s: 7.0.0.Beta4
(was: 7.0.0.Beta3)
> Rule Generation Feature Request
> -------------------------------
>
> Key: DROOLS-744
> URL: https://issues.jboss.org/browse/DROOLS-744
> Project: Drools
> Issue Type: Feature Request
> Components: core engine, kie server
> Affects Versions: 6.2.0.Final
> Reporter: Justin Holmes
> Assignee: Mario Fusco
> Fix For: 7.0.0.Beta4
>
>
> As a developer using Drools, I want a rule generation java api that supports control logic in the rule templates (e.g. for loops, if/else) and integrates with the rule workbench in order to build highly dynamic business rules driven systems.
> The initial thought process around implementation is to build two things 1) a simple way to author mvel templates in business central, the existing text editor could be used at first and 2) a simple embedded java api in it's own maven module which can checkout the git project that has the mvel template, apply a set of domain objects to the template, check in the resulting rule files to the local git repo and then push the changes back to business central. This allows us to leverage the power of the existing MVEL and JGit tech stack while pushing the complexity to a java api, where we are stronger than the workbench itself.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 6 months