[JBoss JIRA] (WFLY-9395) Move ClusteringRequirement to the public API module
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-9395:
------------------------------------
Summary: Move ClusteringRequirement to the public API module
Key: WFLY-9395
URL: https://issues.jboss.org/browse/WFLY-9395
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 11.0.0.CR1
Reporter: Radoslav Husar
Assignee: Paul Ferraro
Currently the user needs to rely on using the capability name as service name to establish a dependency, e.g.:
{code:java}
policy.createSingletonServiceBuilder(SINGLETON_SERVICE_NAME, service)
.build(serviceActivatorContext.getServiceTarget())
.addDependency(ServiceName.parse("org.wildfly.clustering.default-group"), Group.class, group)
.install();
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (DROOLS-785) no MVEL debugger registered to handle breakpoint
by Peter Durica (JIRA)
[ https://issues.jboss.org/browse/DROOLS-785?page=com.atlassian.jira.plugin... ]
Peter Durica commented on DROOLS-785:
-------------------------------------
Drools version 6.5.0.Final, Eclipse 4.6 Neon:
The problem is in this class:
{{org.drools.core.base.mvel.MVELDebugHandler}}
This class is a Debug bridge between the Drools and MVEL engine. It registers the debugger instance (MVELDebugger) to the MVEL engine:
{{ public static void setDebugMode(boolean b) {
debugMode = Boolean.valueOf( b );
if (debugMode) {
if (!MVELRuntime.hasDebuggerContext()) {
MVELRuntime.setThreadDebugger(new MVELDebugger());
}
} else {
MVELRuntime.resetDebugger();
}
System.setProperty( DEBUG_LAUNCH_KEY, debugMode.toString());
} }}
The problem is with the line {{MVELRuntime.hasDebuggerContext()}} it always returns true as the MVELRuntime is initialized with the default context so the Drools debugger is never set. After patching this class the debugging seems to work:
{{public static void setDebugMode(boolean b) {
debugMode = Boolean.valueOf( b );
if (debugMode) {
MVELRuntime.setThreadDebugger(new MVELDebugger());
} else {
MVELRuntime.resetDebugger();
}
System.setProperty( DEBUG_LAUNCH_KEY, debugMode.toString());
}}}
If somebody finds a better solution for this problem, please post it here.
> no MVEL debugger registered to handle breakpoint
> ------------------------------------------------
>
> Key: DROOLS-785
> URL: https://issues.jboss.org/browse/DROOLS-785
> Project: Drools
> Issue Type: Bug
> Components: core engine, eclipse plugin
> Affects Versions: 6.2.0.Final, 6.3.0.Final
> Environment: Win 7 64, JBoss Developer Studio Version: 8.1.0.GA, JBossAS Tools 3.0.3.Final-v20150325-0035-B129, Java 1.7.0_76
> Reporter: Maurice Betzel
> Assignee: Petr Široký
>
> Executing Drools-Examples 6.0.2.Final from github containing MVEL dialect resulted in runtime exception:
> 2015-05-16 14:35:28,603 [main] INFO Found kmodule: file:/C:/Users/x3.mbetzel/Development/workspaces/jboss-drools/drools-examples-62/target/classes/META-INF/kmodule.xml
> 2015-05-16 14:35:28,999 [main] INFO KieModule was added: FileKieModule[releaseId=org.drools:drools-examples:6.2.0.Final,file=C:\Users\x3.mbetzel\Development\workspaces\jboss-drools\drools-examples-62\target\classes]
> Exception in thread "main" java.lang.RuntimeException: no debugger registered to handle breakpoint
> at org.mvel2.debug.DebuggerContext.checkBreak(DebuggerContext.java:98)
> at org.mvel2.MVELRuntime.execute(MVELRuntime.java:76)
> at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
> at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
> at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:113)
> at org.mvel2.MVEL.executeExpression(MVEL.java:930)
> at org.drools.core.util.MVELSafeHelper$RawMVELEvaluator.executeExpression(MVELSafeHelper.java:481)
> at org.drools.core.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:77)
> at org.drools.core.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:62)
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:230)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:187)
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:141)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:504)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:379)
> at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:290)
> at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:253)
> at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:370)
> at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:289)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1480)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1422)
> at org.drools.examples.helloworld.HelloWorldExample.main(HelloWorldExample.java:65)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFLY-9392) WorkerFailoverTestCase fails with security manager
by Ingo Weiss (JIRA)
[ https://issues.jboss.org/browse/WFLY-9392?page=com.atlassian.jira.plugin.... ]
Ingo Weiss reassigned WFLY-9392:
--------------------------------
Assignee: Ingo Weiss
> 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
> Assignee: Ingo Weiss
> 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, 3 months
[JBoss JIRA] (DROOLS-1744) Inclusion of kbases containing rule templates results in duplicate rule names and kbase build failure.
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1744?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1744:
-------------------------------------
Can you please provide a reproducer of this issue?
> 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, 3 months
[JBoss JIRA] (WFLY-9378) Attribute TransportResourceDefinition.Attribute#SOCKET_BINDING should be required and with DIAGNOSTICS_SOCKET_BINDING should not allow expressions
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9378?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-9378:
---------------------------------
Steps to Reproduce:
{noformat}
[standalone@localhost:9990 /] /subsystem=jgroups/stack=udp/transport=UDP:undefine-attribute(name=socket-binding
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
[standalone@localhost:9990 /] reload
{
"outcome" => "success",
"result" => undefined
}
{noformat}
was:
{noformat}
[standalone@localhost:9990 /] /subsystem=jgroups/stack=udp/transport=UDP:undefine-attribute(name=socket-binding
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
[standalone@localhost:9990 /] :reload
{
"outcome" => "success",
"result" => undefined
}
{noformat}
> Attribute TransportResourceDefinition.Attribute#SOCKET_BINDING should be required and with DIAGNOSTICS_SOCKET_BINDING should not allow expressions
> ---------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9378
> URL: https://issues.jboss.org/browse/WFLY-9378
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.CR1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Blocker
> Fix For: 11.0.0.Final
>
>
> {noformat}
> 18:26:26,514 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "jgroups"),
> ("channel" => "ee")
> ]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
> "Services that were unable to start:" => [
> "org.wildfly.clustering.group.ee",
> "org.wildfly.clustering.jgroups.channel.ee"
> ],
> "Services that may be the cause:" => ["org.wildfly.network.socket-binding.undefined"]
> }}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFLY-9393) Upgrade Jgroups to 3.6.14.Final
by Leandro Kersting de Freitas (JIRA)
Leandro Kersting de Freitas created WFLY-9393:
-------------------------------------------------
Summary: Upgrade Jgroups to 3.6.14.Final
Key: WFLY-9393
URL: https://issues.jboss.org/browse/WFLY-9393
Project: WildFly
Issue Type: Component Upgrade
Components: Clustering
Reporter: Leandro Kersting de Freitas
Assignee: Paul Ferraro
Fix For: 11.0.0.Final
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months