[JBoss JIRA] (DROOLS-1744) Inclusion of kbases containing rule templates results in duplicate rule names and kbase build failure.
by Alistair Black (JIRA)
Alistair Black created DROOLS-1744:
--------------------------------------
Summary: Inclusion of kbases containing rule templates results in duplicate rule names and kbase build failure.
Key: DROOLS-1744
URL: https://issues.jboss.org/browse/DROOLS-1744
Project: Drools
Issue Type: Bug
Components: decision tables
Affects Versions: 7.3.0.Final
Reporter: Alistair Black
Assignee: Mario Fusco
I am working on a multi-module BRMS project, with each module encapsulating a set of rules forming a single knowledge base. There is an empty "packaging" module which inherits each of these modules in order to generate a single KJAR for deployment purposes. The application then utilises this KJAR via the KieScanner/ReleaseId approach to facilitate dynamic rule loading at runtime and decoupling of application/rules.
Having taken the above approach I have encountered an issue when including knowledge bases that contain rule templates. Drools is unable to build these knowledge bases, reporting duplicate rule names; it appears to believe that the rules exist in both the inheriting and inherited knowledge bases. This behaviour is not seen when including knowledge bases containing standard rules or decision tables - just rule templates.
An example of the error reported is:
{{4528 [main] INFO org.drools.compiler.kie.builder.impl.KieRepositoryImpl - KieModule was added: ZipKieModule[releaseId=my.drools.templates:ruleModuleOne:1.0-SNAPSHOT,file=C:\Users\black\.m2\repository\my\drools\templates\ruleModuleOne\1.0-SNAPSHOT\ruleModuleOne-1.0-SNAPSHOT.jar]
5145 [main] ERROR org.drools.compiler.kie.builder.impl.KieProject - Unable to build KieBaseModel:ruleModule_1_kbase
[7,4]: Duplicate rule name: Rule One :: CCC_4
[15,4]: Duplicate rule name: Rule One :: BBB_3
[23,4]: Duplicate rule name: Rule One :: AAA_2
[7,4]: Duplicate rule name: Rule Two :: EEE_3
[16,4]: Duplicate rule name: Rule Two :: DDD_2
5329 [main] ERROR org.drools.compiler.kie.builder.impl.KieProject - Unable to build KieBaseModel:inheritedTemplateModules-ruleModule_1_kbase
[7,4]: Duplicate rule name: Rule One :: CCC_4
[15,4]: Duplicate rule name: Rule One :: BBB_3
[23,4]: Duplicate rule name: Rule One :: AAA_2
[7,4]: Duplicate rule name: Rule Two :: EEE_3
[16,4]: Duplicate rule name: Rule Two :: DDD_2
}}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 2 months
[JBoss JIRA] (WFLY-9392) WorkerFailoverTestCase fails with security manager
by Ondrej Kotek (JIRA)
[ https://issues.jboss.org/browse/WFLY-9392?page=com.atlassian.jira.plugin.... ]
Ondrej Kotek moved JBEAP-13280 to WFLY-9392:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9392 (was: JBEAP-13280)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Test Suite
(was: Test Suite)
Affects Version/s: 11.0.0.Final
(was: 7.1.0.CR2)
> WorkerFailoverTestCase fails with security manager
> --------------------------------------------------
>
> Key: WFLY-9392
> URL: https://issues.jboss.org/browse/WFLY-9392
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 11.0.0.Final
> Reporter: Ondrej Kotek
> Labels: security-manager
>
> WorkerFailoverTestCase fails with security manager because of missing permission "("java.util.PropertyPermission" "jvmRoute" "read")":
> {noformat}
> ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /jvmroute/jvmroute: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "jvmRoute" "read")" in code source "(vfs:/content/jvmroute.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.jvmroute.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:469)
> at java.lang.System.getProperty(System.java:753)
> at org.jboss.as.test.clustering.single.web.CommonJvmRoute.jvmRoute(CommonJvmRoute.java:31)
> at org.jboss.as.test.clustering.single.web.JvmRouteServlet.doGet(JvmRouteServlet.java:25)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110)
> at java.security.AccessController.doPrivileged(Native Method)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Adding the permission and {{PropertyPermission("jboss.mod_cluster.jvmRoute", "read")}} helps.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 2 months
[JBoss JIRA] (WFLY-8568) Elytron outflow-security-domains doesn't work for Servlet-to-EJB calls
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-8568?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-8568:
--------------------------------------
Assignee: Darran Lofthouse (was: David Lloyd)
> Elytron outflow-security-domains doesn't work for Servlet-to-EJB calls
> ----------------------------------------------------------------------
>
> Key: WFLY-8568
> URL: https://issues.jboss.org/browse/WFLY-8568
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security, Web (Undertow)
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
>
> Security context propagation with using Elytron {{outflow-security-domains}} attribute in security domain doesn't work for Servlet-to-EJB calls.
> This could also be a test configuration issue, but as there is not yet documentation covering this area, I can't guess what could be wrong in the scenario.
> 1. I have 2 similar web applications with servlets and EJBs:
> * the `secured-webapp` is mapped to `web-tests` security domain
> * the `second` application is mapped to `second-domain` security domain
> 2. Undertow and EJB subsystems maps the application domains `web-tests` and `second-domain` to Elytron domains with the same name.
> 3. trust between the domains is defined in following way:
> {code}
> /subsystem=elytron/security-domain=second-domain:write-attribute(name=outflow-security-domains,value=[web-tests])
> /subsystem=elytron/security-domain=second-domain:write-attribute(name=trusted-security-domains, value=[web-tests])
> /subsystem=elytron/security-domain=web-tests:write-attribute(name=trusted-security-domains, value=[second-domain])
> {code}
> 4. the test itself calls servlet from the `second` web application and it calls protected EJB from the `secured-webapp`.
> The EJB call fails with EJBAccessException
> {noformat}
> 14:30:04,631 ERROR [org.jboss.as.ejb3.invocation] (default task-3) WFLYEJB0034: EJB Invocation failed on component HelloBean for method public abstract java.lang.String org.jboss.test.ejb.Hello.sayHello(): javax.ejb.EJBAccessException: WFLYEJB0364: Invocation on method: public abstract java.lang.String org.jboss.test.ejb.Hello.sayHello() of bean: HelloBean is not allowed
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 2 months
[JBoss JIRA] (DROOLS-1743) NPE in RuleNEtworkEvaluator after incremental compilation
by Anton Giertli (JIRA)
Anton Giertli created DROOLS-1743:
-------------------------------------
Summary: NPE in RuleNEtworkEvaluator after incremental compilation
Key: DROOLS-1743
URL: https://issues.jboss.org/browse/DROOLS-1743
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.3.0.Final
Reporter: Anton Giertli
Assignee: Mario Fusco
Attachments: drools-path-memory-reproducer.zip
Having the following drl files :
{code:drl}
package org.hightea.a
import org.drools.compiler.Message
import org.drools.compiler.FirstClass
rule "RG_1"
when
$event : Message()
FirstClass(item1 == $event.message1)
then
System.out.println("RG_1");
end
{code}
and
{code:drl}
package org.hightea.b
import org.drools.compiler.Message
import org.drools.compiler.SecondClass
rule "RG_2"
when
$event: Message()
SecondClass(item1 == $event.message1)
then
System.out.println("RG_2");
end
{code}
We create a module containing the two packages in two drl files and insert a `SecondClass` fact in the WM.
Then we want to incrementally update to a new module containing only the second DRL.
At first fireAllrules after update, we encounter a NPE in RuleNetwork evaluator (a Segment memory is not defined in the path memory)
{code:java}
java.lang.NullPointerException
at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:114)
at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:212)
at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:87)
at org.drools.core.concurrent.AbstractRuleEvaluator.internalEvaluateAndFire(AbstractRuleEvaluator.java:34)
at org.drools.core.concurrent.SequentialRuleEvaluator.evaluateAndFire(SequentialRuleEvaluator.java:43)
at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1067)
at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014)
at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295)
at org.hightea.IncrementalRemoveRuleTest.testNpeInRuleNetworkEvaluator(IncrementalRemoveRuleTest.java:66)
{code}
Note that we don't encounter this issue when the packages names are the same, or if we exchange the order of drl file name in the first module.
A reproducer is attached with its source code at [https://github.com/hightea/drools-reproducer/tree/path-memory-issue|https...]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 2 months
[JBoss JIRA] (WFCORE-2197) ability to upload content from secure web server
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2197?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-2197:
------------------------------------------
Hadn't seen this before but +1 to using the Elytron authentication context, the authentication context can match based on the URL to identify the security policy to use.
> ability to upload content from secure web server
> ------------------------------------------------
>
> Key: WFCORE-2197
> URL: https://issues.jboss.org/browse/WFCORE-2197
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Security
> Reporter: Ian Kent
>
> We use the upload-deployment-url operation of wildfly management API to add content to content repository (app war) from remote web server (nexus artifact repository manager). As the nexus web server is secure so the wildfly app server needs to pass credentials to nexus when downloading war to wildfly content repository for deployment. Is there a way to encode the nexus username and password in url parameter or add a additional parameters for username and password.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 2 months