[JBoss JIRA] (WFLY-3214) Builders for AttributeDefinitions don't all pass in all settings to the AD
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-3214:
--------------------------------------
Summary: Builders for AttributeDefinitions don't all pass in all settings to the AD
Key: WFLY-3214
URL: https://issues.jboss.org/browse/WFLY-3214
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Domain Management
Affects Versions: 8.0.0.Final
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 9.0.0.CR1
While working on WFLY-3184 I discovered that ObjectListAttributeDefinition.Builder does not pass any configured ParameterCorrector into the AD. I believe this is a problem common to a number of the builders.
The way the AD constructors work is also very problematic. When we add a new field to a class deep in the hierarchy, like AD itself, we then add a new constructor with a new param and then need to expose that param all the way up the hierarchy by doing the same thing in the subclasses. Very fragile.
I intend to deal with both these issues:
1) Deprecate the public or protected AD constructors except for the simple ones in SimpleAttributeDefinition, which are potentially more commonly used.
2) Add getters for all the fields in AbstactAttributeDefinitionBuilder and subclasses.
3) Add a protected constructor to AD and all subclasses (private where possible) that takes the relevant Builder as its param and then populates its fields from the getters. The build() method in the builders will call this constructor.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JGRP-1817) OverlappingMergeTest testSameCreatorDifferentIDs fails to create correct merged view
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1817?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1817:
-------------------------------------------
If I run the test case in a debugger, I see what is expected:
{noformat}
==== triggering merge solicitation ====:
Discovery:A received GET_MBRS_REQ
ping_rsps: size = 0, id = []
Discovery:C received GET_MBRS_REQ
Discovery:B received GET_MBRS_REQ
Discovery: C: received GET_MBRS_REQ from A, sending response [PING: type=GET_MBRS_RSP, arg=C, view_id=[A|7] ([A|7] [A, B, C]), is_server=true, is_coord=false]
Discovery: B: received GET_MBRS_REQ from A, sending response [PING: type=GET_MBRS_RSP, arg=B, view_id=[A|6] ([A|6] [A, B]), is_server=true, is_coord=false]
Discovery:A received GET_MBRS_RSP
Discovery:A received GET_MBRS_RSP
Discovery: A adding ping rsp (to responses) from C
Responses: calling add response (not present): address = C
Discovery: A adding ping rsp (to responses) from B
ping_rsps: size = 1, id = [C, view_id=[A|7] ([A|7] [A, B, C]), is_server=true, is_coord=false]
Responses: calling add response (not present): address = B
ping_rsps: size = 2, id = [C, view_id=[A|7] ([A|7] [A, B, C]), is_server=true, is_coord=false, B, view_id=[A|6] ([A|6] [A, B]), is_server=true, is_coord=false]
{noformat}
If I run excatly the same test case in the testsuite from a shell, I see this:
{noformat}
==== triggering merge solicitation ====:
298102 [TRACE] TCPPING: - A: sending discovery request to 127.0.0.1:27231
298104 [TRACE] TCPPING: - A: sending discovery request to 127.0.0.1:27232
298105 [TRACE] TCPPING: - A: sending discovery request to 127.0.0.1:27230
ping_rsps: size = 0, id = []
ping_rsps: size = 1, id = [C, view_id=[A|7] ([A|7] [A, B, C]), is_server=true, is_coord=false]
ping_rsps: size = 2, id = [C, view_id=[A|7] ([A|7] [A, B, C]), is_server=true, is_coord=false, B, view_id=[A|6] ([A|6] [A, B]), is_server=true, is_coord=false]
301106 [TRACE] TCPPING: - A: discovery took 3004 ms: responses: 2 total (2 servers (0 coord), 0 clients)
301107 [TRACE] MERGE2: - Discovery results:
[C]: view_id=[A|7] ([A|7] [A, B, C])
[B]: view_id=[A|6] ([A|6] [A, B])
[A]: view_id=[A|5] ([A|5] [A])
301107 [DEBUG] MERGE2: - A found different views : [A|6], [A|7], [A|5]; sending up MERGE event with merge participants [B, C, A].
Discovery results:
[C]: coord=A
[B]: coord=A
[A]: coord=A
{noformat}
> OverlappingMergeTest testSameCreatorDifferentIDs fails to create correct merged view
> ------------------------------------------------------------------------------------
>
> Key: JGRP-1817
> URL: https://issues.jboss.org/browse/JGRP-1817
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.14
>
>
> This test does the following:
> - creates three channels a,b,c
> - injects views
> {noformat}
> A: {A|5 A}, B:{A|6 A,B}, C:{A|7 A,B,C}
> {noformat}
> - calls MERGE.sendMergeSolicitation() on channel A to simulate the calling of the periodic task MERGE.findSubgroupsTask which should find all views of all reachable members, check if there are different views, and if there are prepare and send a MERGE event up to GMS
> - checks that all channels have the final view of size 3
> The test fails intermittently but frequently on RHEL, with the same failure each time:
> {noformat}
> -------------------------------------------------------------------
> GMS: address=A, cluster=OverlappingMergeTest, physical address=10.16.95.7:27215
> -------------------------------------------------------------------
> -------------------------------------------------------------------
> GMS: address=B, cluster=OverlappingMergeTest, physical address=10.16.95.7:27216
> -------------------------------------------------------------------
> -------------------------------------------------------------------
> GMS: address=C, cluster=OverlappingMergeTest, physical address=10.16.95.7:27217
> -------------------------------------------------------------------
> ------------- testSameCreatorDifferentIDs -----------
> [A] view=[A|5] [A]
> [B] view=[A|6] [A, B]
> [C] view=[A|7] [A, B, C]
> A's view: [A|5] [A]
> B's view: [A|6] [A, B]
> C's view: [A|7] [A, B, C]
> Enabling TRACE debugging for GMS, MERGE2 and Discovery
> ==== triggering merge solicitation ====:
> 212534 [TRACE] TCPPING: - A: sending discovery request to 10.16.95.7:27216
> 212537 [TRACE] TCPPING: - A: sending discovery request to 10.16.95.7:27218
> 212538 [TRACE] TCPPING: - A: sending discovery request to 10.16.95.7:27217
> 215538 [TRACE] TCPPING: - A: discovery took 3004 ms: responses: 1 total (1 servers (0 coord), 0 clients)
> 215539 [TRACE] MERGE2: - Discovery results:
> [B]: view_id=[A|6] ([A|6] [A, B])
> [A]: view_id=[A|5] ([A|5] [A])
> 215539 [DEBUG] MERGE2: - A found different views : [A|5], [A|6]; sending up MERGE event with merge participants [B, A].
> Discovery results:
> [B]: coord=A
> [A]: coord=A
> ==== checking views after merge ====:
> ....................Disabling TRACE debugging for GMS, MERGE2 and Discovery
> A's view: [A|7] [A, B]
> B's view: [A|7] [A, B]
> C's view: [A|7] [A, B, C]
> {noformat}
> Whenever this test fails, it is the discovery phase which fails to find the correct set of views. Instead of finding views for channels A, B and C, it only finds views for channels A and B.
>
> Also, the discovery requests are sent to host:port combinations which are offset by 1. For example, in the case above, the host:port combinations of the channels are 10.16.95.7:27215, 10.16.95.7:27216, and 10.16.95.7:27217, but the pings go put to 10.16.95.7:27216, 10.16.95.7:27217, and 10.16.95.7:27218. Not sure if this is significant as it still covers the channels B and C.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-3213) Make default-cache attribute of cache-container element optional
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-3213:
----------------------------------
Summary: Make default-cache attribute of cache-container element optional
Key: WFLY-3213
URL: https://issues.jboss.org/browse/WFLY-3213
Project: WildFly
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: 8.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Not every cache container requires a default cache. We can make default-cache an optional attribute and only specify it where it makes sense.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-3072) Support Referrals for security realms using LDAP for authentication or group loading.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3072?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-3072:
-----------------------------------
Description:
I see the following scenarios to cover for this: -
- Authentication - A search is performed e.g against 'uid' and a referral is encountered, the URL needs to be extracted from the referral and a new connection created using the referral URL to load any additional attributes for the user, the referral URL is then used to establish the connection as the user to verify that their password is correct.
Group loading then has a couple of issues, firstly where the user was a referral.
The search for group membership information is a fresh start but now we potentially have 2 simple named and 2 distinguished names that could be referenced from the group object. We may want a config option to specify which one to actually use and even possibly use both.
Next could a group also be a referral, i.e. it contains the reference to the user as an attribute so was matched in the search but is also a referral to the true named group in another location. In this situation I suggest any iterative search takes into account the context containing the actual group definition and continues the search from there.
And then where the principal contains an attribute that references, this one should be a simple following of a referral and once followed continue the attribute loading using the new connection.
The connection manager logic is going to need reworking, ideally for a referral we should check if we have a connection definition that matches based on the URL returned otherwise we will need to try and establish a connection based on the settings of the last connection used, this probably also introduces a notion of some form of connection stack of the connections used for the current request - referrals could have us bouncing back and forth so connections should be cached and re-used where possible during authentication and group loading.
was:This also needs to take into account compatibility with caching.
> Support Referrals for security realms using LDAP for authentication or group loading.
> -------------------------------------------------------------------------------------
>
> Key: WFLY-3072
> URL: https://issues.jboss.org/browse/WFLY-3072
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 8.0.1.Final
>
>
> I see the following scenarios to cover for this: -
> - Authentication - A search is performed e.g against 'uid' and a referral is encountered, the URL needs to be extracted from the referral and a new connection created using the referral URL to load any additional attributes for the user, the referral URL is then used to establish the connection as the user to verify that their password is correct.
> Group loading then has a couple of issues, firstly where the user was a referral.
> The search for group membership information is a fresh start but now we potentially have 2 simple named and 2 distinguished names that could be referenced from the group object. We may want a config option to specify which one to actually use and even possibly use both.
> Next could a group also be a referral, i.e. it contains the reference to the user as an attribute so was matched in the search but is also a referral to the true named group in another location. In this situation I suggest any iterative search takes into account the context containing the actual group definition and continues the search from there.
> And then where the principal contains an attribute that references, this one should be a simple following of a referral and once followed continue the attribute loading using the new connection.
> The connection manager logic is going to need reworking, ideally for a referral we should check if we have a connection definition that matches based on the URL returned otherwise we will need to try and establish a connection based on the settings of the last connection used, this probably also introduces a notion of some form of connection stack of the connections used for the current request - referrals could have us bouncing back and forth so connections should be cached and re-used where possible during authentication and group loading.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (DROOLS-451) Timed rules, different name, same timer, same LHS, different RHS, one mask the other
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-451?page=com.atlassian.jira.plugin... ]
Mario Fusco reassigned DROOLS-451:
----------------------------------
Assignee: Mario Fusco (was: Mark Proctor)
> Timed rules, different name, same timer, same LHS, different RHS, one mask the other
> ------------------------------------------------------------------------------------
>
> Key: DROOLS-451
> URL: https://issues.jboss.org/browse/DROOLS-451
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Attachments: 2014-03-11_18-52-25.png, 20140311.drools6test.timerrulessamelhs.zip
>
>
> Consider the following KB:
> {code}
> rule "Dummy timer rule 1"
> timer (cron: 0 0 0 * * ?)
> when
> Integer()
> then
> insert("Dummy timer rule 1");
> System.out.println("Dummy timer rule 1");
> end
> rule "Dummy timer rule 2"
> timer (cron: 0 0 0 * * ?)
> when
> Integer()
> then
> insert("Dummy timer rule 2");
> System.out.println("Dummy timer rule 2");
> end
> {code}
> Then consider the following steps:
> # insert new Integer
> # advance clock by +1 day
> *Expected result:* 3 facts in the working memory, the original Integer, and two String.
> *Actual results:* 2 facts in the working memory, the original Integer, and only 1 String, from the former of the two rules.
> I hope this is not another duplicate report, I've done search on Jira before submitting, but kindly excuse me if I didn't found an already open bug which is a greater case of this one =)
> I will attach relevant source code to replicate the issue, and related material
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (DROOLS-451) Timed rules, different name, same timer, same LHS, different RHS, one mask the other
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-451?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-451.
--------------------------------
Fix Version/s: 6.1.0.Beta3
Resolution: Done
> Timed rules, different name, same timer, same LHS, different RHS, one mask the other
> ------------------------------------------------------------------------------------
>
> Key: DROOLS-451
> URL: https://issues.jboss.org/browse/DROOLS-451
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Fix For: 6.1.0.Beta3
>
> Attachments: 2014-03-11_18-52-25.png, 20140311.drools6test.timerrulessamelhs.zip
>
>
> Consider the following KB:
> {code}
> rule "Dummy timer rule 1"
> timer (cron: 0 0 0 * * ?)
> when
> Integer()
> then
> insert("Dummy timer rule 1");
> System.out.println("Dummy timer rule 1");
> end
> rule "Dummy timer rule 2"
> timer (cron: 0 0 0 * * ?)
> when
> Integer()
> then
> insert("Dummy timer rule 2");
> System.out.println("Dummy timer rule 2");
> end
> {code}
> Then consider the following steps:
> # insert new Integer
> # advance clock by +1 day
> *Expected result:* 3 facts in the working memory, the original Integer, and two String.
> *Actual results:* 2 facts in the working memory, the original Integer, and only 1 String, from the former of the two rules.
> I hope this is not another duplicate report, I've done search on Jira before submitting, but kindly excuse me if I didn't found an already open bug which is a greater case of this one =)
> I will attach relevant source code to replicate the issue, and related material
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (DROOLS-451) Timed rules, different name, same timer, same LHS, different RHS, one mask the other
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-451?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated DROOLS-451:
-------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1083669
> Timed rules, different name, same timer, same LHS, different RHS, one mask the other
> ------------------------------------------------------------------------------------
>
> Key: DROOLS-451
> URL: https://issues.jboss.org/browse/DROOLS-451
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Reporter: Matteo Mortari
> Assignee: Mark Proctor
> Attachments: 2014-03-11_18-52-25.png, 20140311.drools6test.timerrulessamelhs.zip
>
>
> Consider the following KB:
> {code}
> rule "Dummy timer rule 1"
> timer (cron: 0 0 0 * * ?)
> when
> Integer()
> then
> insert("Dummy timer rule 1");
> System.out.println("Dummy timer rule 1");
> end
> rule "Dummy timer rule 2"
> timer (cron: 0 0 0 * * ?)
> when
> Integer()
> then
> insert("Dummy timer rule 2");
> System.out.println("Dummy timer rule 2");
> end
> {code}
> Then consider the following steps:
> # insert new Integer
> # advance clock by +1 day
> *Expected result:* 3 facts in the working memory, the original Integer, and two String.
> *Actual results:* 2 facts in the working memory, the original Integer, and only 1 String, from the former of the two rules.
> I hope this is not another duplicate report, I've done search on Jira before submitting, but kindly excuse me if I didn't found an already open bug which is a greater case of this one =)
> I will attach relevant source code to replicate the issue, and related material
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months