[JBoss JIRA] (DROOLS-1825) [Guided Decision Table] Ability to change HIT policy in a decision table anytime
by Kris Verlaenen (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1825?page=com.atlassian.jira.plugi... ]
Kris Verlaenen updated DROOLS-1825:
-----------------------------------
Sprint: 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04, 2018 Week 05-06, 2018 Week 07-08, 2018 Week 09-10, 2018 Week 11-12, 2018 Week 13-14, 2018 Week 15-16, 2018 Week 17-18, 2018 Week 19-22, 2018 Week 23-24, 2018 Week 25-26, 2018 Week 27-29 (was: 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04, 2018 Week 05-06, 2018 Week 07-08, 2018 Week 09-10, 2018 Week 11-12, 2018 Week 13-14, 2018 Week 15-16, 2018 Week 17-18, 2018 Week 19-22, 2018 Week 23-24, 2018 Week 25-26)
> [Guided Decision Table] Ability to change HIT policy in a decision table anytime
> --------------------------------------------------------------------------------
>
> Key: DROOLS-1825
> URL: https://issues.jboss.org/browse/DROOLS-1825
> Project: Drools
> Issue Type: Enhancement
> Components: Guided Decision Table Editor
> Affects Versions: 7.1.0.Beta2
> Reporter: Ivo Bek
> Assignee: Toni Rikkola
> Priority: Critical
> Labels: UX, UXTeam
> Attachments: DROOLS-1825 (Parent Rule).png, DecisionTable1.png, DecisionTable2.png, GDTAnalysis(a)2x.png, GDTColumns(a)2x.png
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> Today, it's possible to set 1 of 5 HIT policies when we create a new guided decision table. However, the user might not know which HIT policy he/she should use at this early beginning. Therefore, it should be possible to set the policy to None when we create a new guided decision table and set the HIT policy later after we add columns and rows, fill in some data and see and decide based on the created table how the rules should behave using the HIT policy.
> Thus, it should be possible to change HIT policy in a decision table anytime.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (DROOLS-1609) Augment FEEL AST node at compilation with return type
by Kris Verlaenen (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1609?page=com.atlassian.jira.plugi... ]
Kris Verlaenen updated DROOLS-1609:
-----------------------------------
Sprint: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04, 2018 Week 05-06, 2018 Week 07-08, 2018 Week 09-10, 2018 Week 11-12, 2018 Week 13-14, 2018 Week 15-16, 2018 Week 17-18, 2018 Week 19-22, 2018 Week 23-24, 2018 Week 25-26, 2018 Week 27-29 (was: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04, 2018 Week 05-06, 2018 Week 07-08, 2018 Week 09-10, 2018 Week 11-12, 2018 Week 13-14, 2018 Week 15-16, 2018 Week 17-18, 2018 Week 19-22, 2018 Week 23-24, 2018 Week 25-26)
> Augment FEEL AST node at compilation with return type
> -----------------------------------------------------
>
> Key: DROOLS-1609
> URL: https://issues.jboss.org/browse/DROOLS-1609
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Minor
>
> This is needed so to be able to determine the result of a boxed function at compile time, in turn to be able at compile time to determine a valid compilation without error of a BKM for instance.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (DROOLS-1942) [DMN Editor] InformationItem's "Name" is always the same as the containing node
by Kris Verlaenen (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1942?page=com.atlassian.jira.plugi... ]
Kris Verlaenen updated DROOLS-1942:
-----------------------------------
Sprint: 2018 Week 13-14, 2018 Week 15-16, 2018 Week 17-18, 2018 Week 19-22, 2018 Week 23-24, 2018 Week 25-26, 2018 Week 27-29 (was: 2018 Week 13-14, 2018 Week 15-16, 2018 Week 17-18, 2018 Week 19-22, 2018 Week 23-24, 2018 Week 25-26)
> [DMN Editor] InformationItem's "Name" is always the same as the containing node
> -------------------------------------------------------------------------------
>
> Key: DROOLS-1942
> URL: https://issues.jboss.org/browse/DROOLS-1942
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Michael Anstis
>
> Whilst an {{InformationItem}} Node has a "Name" its value is always the same as the containing Node's "Name" (for {{InputData}}, {{Decision}} and {{BusinessKnowledgeModel}}). {{ContextEntry}}'s "Name" are not the same as outer most node's "Name" (as a {{ContextEntry}} is contained within a {{Context}} and not directly in a node itself).
> It is proposed that this synchronization should be handled in the "Stunner to (org.kie) DMN model" marshalling. Therefore we need to remove the "Name" {{@FormField}} from {{InformationItem}}.
> [~tari_manga] [~tirelli] Please confirm.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (DROOLS-1964) [DMN Editor] Input Data typeRef
by Kris Verlaenen (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1964?page=com.atlassian.jira.plugi... ]
Kris Verlaenen updated DROOLS-1964:
-----------------------------------
Sprint: 2018 Week 13-14, 2018 Week 15-16, 2018 Week 17-18, 2018 Week 19-22, 2018 Week 23-24, 2018 Week 25-26, 2018 Week 27-29 (was: 2018 Week 13-14, 2018 Week 15-16, 2018 Week 17-18, 2018 Week 19-22, 2018 Week 23-24, 2018 Week 25-26)
> [DMN Editor] Input Data typeRef
> -------------------------------
>
> Key: DROOLS-1964
> URL: https://issues.jboss.org/browse/DROOLS-1964
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Labels: reported-by-qe
>
> The Input Data nodes specifies the datatype via _typeRef_ attribute. Allowed are simple datatypes, enumerations of allowed values and complex data types like Person.
> During work on this were added *typeRef* selection widgets for three DMN nodes: BKM, Decision, and Input. These selection widgets offer [BuiltInType|https://github.com/kiegroup/kie-wb-common/blob/master/kie-wb-..., data types of project, editor for allowed values (enumerations).
> h2. Acceptance test
> - Load dmn from other tool, check data types recognized appropriately, can be edited, saved, reopened
> - Create new dmn, define different data types for different nodes, save, reopen, check values preserved
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (DROOLS-1946) DMN Editor
by Kris Verlaenen (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1946?page=com.atlassian.jira.plugi... ]
Kris Verlaenen updated DROOLS-1946:
-----------------------------------
Sprint: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04, 2018 Week 05-06, 2018 Week 07-08, 2018 Week 09-10, 2018 Week 11-12, 2018 Week 13-14, 2018 Week 15-16, 2018 Week 17-18, 2018 Week 19-22, 2018 Week 23-24, 2018 Week 25-26, 2018 Week 27-29 (was: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04, 2018 Week 05-06, 2018 Week 07-08, 2018 Week 09-10, 2018 Week 11-12, 2018 Week 13-14, 2018 Week 15-16, 2018 Week 17-18, 2018 Week 19-22, 2018 Week 23-24, 2018 Week 25-26)
> DMN Editor
> ----------
>
> Key: DROOLS-1946
> URL: https://issues.jboss.org/browse/DROOLS-1946
> Project: Drools
> Issue Type: Feature Request
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Labels: UX
> Fix For: 7.9.0.Final
>
>
> Place holder for all DMN Editor related activities
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (WFCORE-3949) Cannot use server-file audit logger handler in JMX audit logging
by Yeray Borges (JIRA)
Yeray Borges created WFCORE-3949:
------------------------------------
Summary: Cannot use server-file audit logger handler in JMX audit logging
Key: WFCORE-3949
URL: https://issues.jboss.org/browse/WFCORE-3949
Project: WildFly Core
Issue Type: Bug
Components: JMX, Logging
Reporter: Yeray Borges
Assignee: Yeray Borges
When we are working in domain mode, we can register two kinds of audit logger handlers into JMX audit logging.
Those predefined handlers are {{host-file}} handler, which has a log file relative to {{jboss.domain.data.dir}}, and {{server-file}} handler, which has a log file relative to {{jboss.server.data.dir}}.
When we try to register {{server-file}} handler into JMX audit logging, its relative path cannot be resolved and when a log entry is written, we can see the following error log:
{code:java}
ERROR [org.jboss.as.controller.management-operation] (MSC service thread 1-1) WFLYCTL0037: Update of the management operation audit log failed in handler 'server-file': java.lang.IllegalArgumentException: WFLYCTL0256: Could not find a path called 'jboss.server.data.dir'
[Host Controller] at org.jboss.as.controller.services.path.PathManagerService.resolveRelativePathEntry(PathManagerService.java:110)
[Host Controller] at org.jboss.as.controller.audit.AbstractFileAuditLogHandler.initialize(AbstractFileAuditLogHandler.java:62)
[Host Controller] at org.jboss.as.controller.audit.AuditLogHandler.writeLogItem(AuditLogHandler.java:82)
[Host Controller] at org.jboss.as.controller.audit.ManagedAuditLoggerImpl.writeLogItem(ManagedAuditLoggerImpl.java:266)
[Host Controller] at org.jboss.as.controller.audit.ManagedAuditLoggerImpl.storeLogItem(ManagedAuditLoggerImpl.java:248)
[Host Controller] at org.jboss.as.controller.audit.ManagedAuditLoggerImpl.logJmxMethodAccess(ManagedAuditLoggerImpl.java:122)
[Host Controller] at org.jboss.as.jmx.PluggableMBeanServerImpl$LogAction.doLog(PluggableMBeanServerImpl.java:1281)
[Host Controller] at org.jboss.as.jmx.PluggableMBeanServerImpl.log(PluggableMBeanServerImpl.java:1184)
[Host Controller] at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.log(MBeanServerAuditLogRecordFormatter.java:331)
[Host Controller] at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.registerMBean(MBeanServerAuditLogRecordFormatter.java:147)
[Host Controller] at org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(PluggableMBeanServerImpl.java:880)
[Host Controller] at org.jboss.threads.EnhancedQueueExecutor$1.run(EnhancedQueueExecutor.java:385)
[Host Controller] at org.jboss.threads.EnhancedQueueExecutor$1.run(EnhancedQueueExecutor.java:379)
[Host Controller] at java.security.AccessController.doPrivileged(Native Method)
[Host Controller] at org.jboss.threads.EnhancedQueueExecutor.<init>(EnhancedQueueExecutor.java:379)
[Host Controller] at org.jboss.threads.EnhancedQueueExecutor$Builder.build(EnhancedQueueExecutor.java:671)
[Host Controller] at org.jboss.as.controller.remote.AbstractModelControllerOperationHandlerFactoryService.start(AbstractModelControllerOperationHandlerFactoryService.java:112)
[Host Controller] at org.jboss.as.host.controller.mgmt.MasterDomainControllerOperationHandlerService.start(MasterDomainControllerOperationHandlerService.java:90)
[Host Controller] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
[Host Controller] at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
[Host Controller] at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
[Host Controller] at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
[Host Controller] at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
[Host Controller] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
[Host Controller] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
[Host Controller] at java.lang.Thread.run(Thread.java:748)
{code}
Registering a {{host-file}} does not throw any errors and work as expected. Althought there is a capability reference to jboss.server.data.dir in HostPathManagerService, when the handler is registered for JMX, jboss.server.data.dir cannot be resolved.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (WFCORE-3949) Cannot use server-file audit logger handler in JMX audit logging
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3949?page=com.atlassian.jira.plugi... ]
Yeray Borges updated WFCORE-3949:
---------------------------------
Steps to Reproduce:
# Start a domain mode
# enables the audit log at server level
{noformat}
/host=master/core-service=management/access=audit/server-logger=audit-log:write-attribute(name=enabled,value=true)
{noformat}
# Add the file-handler to the JMX audit loggin
{noformat}
/host=master/subsystem=jmx/configuration=audit-log:add()
/host=master/subsystem=jmx/configuration=audit-log/handler=server-file:add()
{noformat}
# reload the host master
{noformat}
/host=mas:reload
{noformat}
was:
# Start a domain mode
# enables the audit log at server level
{noformat}
/host=master/core-service=management/access=audit/server-logger=audit-log:write-attribute(name=enabled,value=true)
{noformat}
# Add the file-handler to the JMX audit loggin
{noformat}
/host=master/subsystem=jmx/configuration=audit-log:add()
/host=master/subsystem=jmx/configuration=audit-log/handler=server-file:add()
{noformat}
# reload the host master
{noformat}
/host=mas:reload
{noformat}
> Cannot use server-file audit logger handler in JMX audit logging
> -----------------------------------------------------------------
>
> Key: WFCORE-3949
> URL: https://issues.jboss.org/browse/WFCORE-3949
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX, Logging
> Reporter: Yeray Borges
> Assignee: Yeray Borges
>
> When we are working in domain mode, we can register two kinds of audit logger handlers into JMX audit logging.
> Those predefined handlers are {{host-file}} handler, which has a log file relative to {{jboss.domain.data.dir}}, and {{server-file}} handler, which has a log file relative to {{jboss.server.data.dir}}.
> When we try to register {{server-file}} handler into JMX audit logging, its relative path cannot be resolved and when a log entry is written, we can see the following error log:
> {code:java}
> ERROR [org.jboss.as.controller.management-operation] (MSC service thread 1-1) WFLYCTL0037: Update of the management operation audit log failed in handler 'server-file': java.lang.IllegalArgumentException: WFLYCTL0256: Could not find a path called 'jboss.server.data.dir'
> [Host Controller] at org.jboss.as.controller.services.path.PathManagerService.resolveRelativePathEntry(PathManagerService.java:110)
> [Host Controller] at org.jboss.as.controller.audit.AbstractFileAuditLogHandler.initialize(AbstractFileAuditLogHandler.java:62)
> [Host Controller] at org.jboss.as.controller.audit.AuditLogHandler.writeLogItem(AuditLogHandler.java:82)
> [Host Controller] at org.jboss.as.controller.audit.ManagedAuditLoggerImpl.writeLogItem(ManagedAuditLoggerImpl.java:266)
> [Host Controller] at org.jboss.as.controller.audit.ManagedAuditLoggerImpl.storeLogItem(ManagedAuditLoggerImpl.java:248)
> [Host Controller] at org.jboss.as.controller.audit.ManagedAuditLoggerImpl.logJmxMethodAccess(ManagedAuditLoggerImpl.java:122)
> [Host Controller] at org.jboss.as.jmx.PluggableMBeanServerImpl$LogAction.doLog(PluggableMBeanServerImpl.java:1281)
> [Host Controller] at org.jboss.as.jmx.PluggableMBeanServerImpl.log(PluggableMBeanServerImpl.java:1184)
> [Host Controller] at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.log(MBeanServerAuditLogRecordFormatter.java:331)
> [Host Controller] at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.registerMBean(MBeanServerAuditLogRecordFormatter.java:147)
> [Host Controller] at org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(PluggableMBeanServerImpl.java:880)
> [Host Controller] at org.jboss.threads.EnhancedQueueExecutor$1.run(EnhancedQueueExecutor.java:385)
> [Host Controller] at org.jboss.threads.EnhancedQueueExecutor$1.run(EnhancedQueueExecutor.java:379)
> [Host Controller] at java.security.AccessController.doPrivileged(Native Method)
> [Host Controller] at org.jboss.threads.EnhancedQueueExecutor.<init>(EnhancedQueueExecutor.java:379)
> [Host Controller] at org.jboss.threads.EnhancedQueueExecutor$Builder.build(EnhancedQueueExecutor.java:671)
> [Host Controller] at org.jboss.as.controller.remote.AbstractModelControllerOperationHandlerFactoryService.start(AbstractModelControllerOperationHandlerFactoryService.java:112)
> [Host Controller] at org.jboss.as.host.controller.mgmt.MasterDomainControllerOperationHandlerService.start(MasterDomainControllerOperationHandlerService.java:90)
> [Host Controller] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
> [Host Controller] at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
> [Host Controller] at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> [Host Controller] at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> [Host Controller] at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> [Host Controller] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> [Host Controller] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> [Host Controller] at java.lang.Thread.run(Thread.java:748)
> {code}
> Registering a {{host-file}} does not throw any errors and work as expected. Althought there is a capability reference to jboss.server.data.dir in HostPathManagerService, when the handler is registered for JMX, jboss.server.data.dir cannot be resolved.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (JGRP-2227) Use of AUTH does not result in a SecurityException, but instead nodes create separate clusters with the same name
by Robert Cernak (JIRA)
[ https://issues.jboss.org/browse/JGRP-2227?page=com.atlassian.jira.plugin.... ]
Robert Cernak edited comment on JGRP-2227 at 7/2/18 5:38 AM:
-------------------------------------------------------------
In our application we have 2 jgroups communications channels. One for infinispan communication and second for sending commands between nodes.
I realized that it will be more beneficial to focus to this 2nd mentioned pure jgroups "commands channel", so we will separate any relation to Infinispan.
So I made test case again. This time I made try/catch block on place where this command channel is being created and connected:
{code:java}
this.commandsChannel = new JChannel(this.commandsChannelFile);
this.commandsChannel.setName(nodeName + "-" + String.format("%05x", new Random().nextInt(0xfffff)));
this.commandsChannel.setDiscardOwnMessages(true);
try {
this.commandsChannel.connect(createClusterNameForChannel(clusterName));
} catch (Exception e) {
System.out.println("Here should be thrown SecurityException");
}
//this.commandsChannel is org.jgroups.JChannel
{code}
I started node 1, in logs can be seen that it correctly forms new cluster as the first member. After that I started node 2. In logs can be seen that it tries to connect for 10 times and afterwards it forms new cluster. However no SecurityException was thrown.
Including trace logs from both nodes for org.jgroups.protocols and as well only logs for org.jgroups.protocols.pbcast.GMS:
[^traceLogs.zip]
if you are interested in configuration file of command channel, it is included in previously updated zip file: jgroupsDoesNotThrowSecurityExceptionWithJgroups4012.zip
was (Author: robertcernak):
In our application we have 2 jgroups communications channels. One for infinispan communication and second for sending commands between nodes.
I realized that it will be more beneficial to focus to this 2nd mentioned pure jgroups "commands channel", so we will separate any relation to Infinispan.
So I made test case again. This time I made try/catch block on place where this command channel is being created and connected:
{code:java}
this.commandsChannel = new JChannel(this.commandsChannelFile);
this.commandsChannel.setName(nodeName + "-" + String.format("%05x", new Random().nextInt(0xfffff)));
this.commandsChannel.setDiscardOwnMessages(true);
try {
this.commandsChannel.connect(createClusterNameForChannel(clusterName));
} catch (Exception e) {
System.out.println("Here should be thrown SecurityException");
}
//this.commandsChannel is org.jgroups.JChannel
{code}
I started node 1, in logs can be seen that it correctly forms new cluster as the first member. After that I started node 2. In logs can be seen that it tries to connect for 10 times and afterwards it forms new cluster. However no SecurityException was thrown.
Including trace logs from both nodes for org.jgroups.protocols and as well only logs for org.jgroups.protocols.pbcast.GMS:
[^traceLogs.zip]
> Use of AUTH does not result in a SecurityException, but instead nodes create separate clusters with the same name
> -----------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2227
> URL: https://issues.jboss.org/browse/JGRP-2227
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.6
> Reporter: Robert Cernak
> Assignee: Bela Ban
> Fix For: 4.0.12
>
> Attachments: jgroupsDoesNotThrowSecurityExceptionWithJgroups4012.zip, jgroupsLogs.zip, traceLogs.zip
>
>
> I implemented method org.jgroups.auth.AuthToken#authenticate(AuthToken token, Message msg) in my class and its body contained only one line: return false;
> In this way authentication should be false and I should get SecurityException.
> When I started joining of nodes together to form a cluster, instead of getting SecurityException, nodes formed 2 different clusters with the same name.
> I am sure method was evaluated, since I tried to run it also with breakpoint, which was triggered during joining process.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months