[midPoint] HA: HA: HA: HA: Prohibit having particular assignments
Алексей Ващенков
a.vashchenkov at solarsecurity.ru
Wed May 27 13:18:53 CEST 2015
Thanks! This code works.
________________________________________
От: midPoint [midpoint-bounces at lists.evolveum.com] от имени Pavol Mederly [mederly at evolveum.com]
Отправлено: 26 мая 2015 г. 18:42
Кому: midpoint at lists.evolveum.com
Тема: Re: [midPoint] HA: HA: HA: Prohibit having particular assignments
Well, the main problem is in the addSecondaryDelta method. It is a method in LensElementContext, a superclass of LensFocusContext and LensProjectionContext. And the focus just ignores secondaryDelta; it uses secondaryDeltas instead. I understand that this is (at best) misleading - and I'll fix this (MID-2381<https://jira.evolveum.com/browse/MID-2381>).
In the meanwhile, I have two options for you; preferring the second one.
The first one is to use correct method to set the secondary delta - along with correctly computing the delta itself.
focusClone = focus.clone();
focusClone.assignment.removeAll(rolesToDelete);
delta = focus.asPrismObject().diff(focusClone.asPrismObject());
log.info("delta = {}", delta.debugDump());
for (itemDelta in delta.getModifications()) {
modelContext.focusContext.swallowToSecondaryDelta(itemDelta);
}
As you can see, I've left out the getObject operation. Because in your case, you were comparing the computed ObjectNew state with original object state in repository. They may differ in much more than the assignments you want to delete. In contrast to that, what I suggest concentrates only on the role assignment removal. And, it does not modify objects in the model context; it modifies a clone instead.
But there still is the question of (possible) secondary delta recomputation yielding the loss of your added delta. So I would not hesitate to put the changes directly into the primary delta, to be sure they will not be lost during the processing:
focusClone = focus.clone();
focusClone.assignment.removeAll(rolesToDelete);
delta = focus.asPrismObject().diff(focusClone.asPrismObject());
log.info("delta = {}", delta.debugDump());
modelContext.focusContext.addPrimaryDelta(delta);
modelContext.setFresh(false);
SetFresh(false) causes immediate recomputation of the context.
I've tested both options in my environment and they seem to work (tested with removing all assignment, not only selected ones).
Hope this helps,
Pavol
On 26. 5. 2015 16:52, Pavol Mederly wrote:
Hello Алексей,
I've studied the logs you've sent here.
Look at the line 9182, just after the text "2015-05-26 12:46:50,285 TRACE: Evaluating hook 'Example scripting hook'".
You see that "User old" and "User current" have all the assignments, namely:
assignment:
id=2
targetRef: oid=5e8b8660-a788-4b7c-8a6c-f08f3ff3d4a1(RoleType)
id=3
targetRef: oid=7faa8e52-d8d8-487f-8a25-987a0eaf4521(RoleType)
id=4
targetRef: oid=cdb06bb4-c134-4ce5-b0f9-483b32832114(RoleType)
id=5
targetRef: oid=3427d715-52a1-4806-9f81-0304f57ffb90(RoleType)
id=1
targetRef: oid=aa1de21f-33a9-46c9-a3fb-f92e88b71377(OrgType)
and "User new" does not have them. So far so good.
BUT.
The secondary delta(s) do not contain the delta that caused that removal:
User secondary delta:
ObjectDeltaWaves:2 waves
wave 0:
ObjectDelta<UserType>(UserType:1e0a1255-9a03-415f-9bef-1ea5d4d4bbd8,MODIFY):
extension/hrStatus
REPLACE: REJ
assignment
ADD:
id=null
targetRef: oid=c2af1367-9ebd-4806-a7fa-05c0914083e0(OrgType)
DELETE:
id=null
targetRef: oid=aa1de21f-33a9-46c9-a3fb-f92e88b71377(OrgType)
activation/administrativeStatus
REPLACE: DISABLED
parentOrgRef
ADD: oid=c2af1367-9ebd-4806-a7fa-05c0914083e0(OrgType)
DELETE: oid=aa1de21f-33a9-46c9-a3fb-f92e88b71377(OrgType)
wave 1:
ObjectDelta<UserType>(UserType:1e0a1255-9a03-415f-9bef-1ea5d4d4bbd8,MODIFY):
extension/hrStatus
REPLACE: REJ
activation/effectiveStatus
REPLACE: DISABLED
activation/disableTimestamp
REPLACE: 2015-05-26T12:46:45.745+03:00
parentOrgRef
ADD: oid=c2af1367-9ebd-4806-a7fa-05c0914083e0(OrgType)
DELETE: oid=aa1de21f-33a9-46c9-a3fb-f92e88b71377(OrgType)
And the deltas are what counts. ChangeExecutor executes deltas, not the "User new" state. The "User new" state is dynamically recomputed (using deltas), at many places.
I'm refering to this code:
result = new OperationResult("get_object_by_oid");
task = taskManager.createTaskInstance("get_user_by_oid");
focus.assignment.removeAll(rolesToDelete);
current = modelController.getObject(UserType.class, focus.oid, null, task, result);
delta = current.diff(focus.asPrismObject(), true, true);
context.engineScope.get("modelContext").focusContext.addSecondaryDelta(delta)
So, I have two recommendation:
1) Do not call removeAll(rolesToDelete) on live object from the model context. Use a clone instead.
2) Try to find why the computed deltas are not incorporated in the context.
As for 2, I would recommend putting some kind of logging to make sure the delta is computed well.
In particular, I would replace current.diff(focus.asPrismObject(), true, true) by
current.diff(focus.asPrismObject()). But that does not seem like the cause.
There's probably one more caveat - not showing in your particular case, but still present.
If you put something into secondary delta, there's a risk that these deltas will get recomputed
if clockwork would think that the context is not fresh - around lines 236-241 of Clockwork:
if (!context.isFresh()) {
context.cleanup();
projector.project(context, "PROJECTOR ("+state+")", task, result);
} else {
LOGGER.trace("Skipping projection because the context is fresh");
}
Note that the projector.project simply re-computes secondary deltas from the beginning (i.e. from the primary delta). I'm not sure how to work around this. (Rado? Have you any idea?) Maybe modifying the primary delta instead of secondary one? Or just hoping this situation would not occur? :)
Anyway, if I find a little bit more time, I could play for a while with this. Until that, you could consider modifying your code according to the recommendations above.
Regards,
Pavol
On 26. 5. 2015 11:59, Алексей Ващенков wrote:
Send the log in attachment
________________________________________
От: midPoint [midpoint-bounces at lists.evolveum.com<mailto:midpoint-bounces at lists.evolveum.com>] от имени Pavol Mederly [pavol.mederly at gmail.com<mailto:pavol.mederly at gmail.com>]
Отправлено: 26 мая 2015 г. 12:38
Кому: midpoint at lists.evolveum.com<mailto:midpoint at lists.evolveum.com>
Тема: Re: [midPoint] HA: HA: Prohibit having particular assignments
I think this thread https://lists.evolveum.com/pipermail/midpoint/2015-May/000995.html would be a better place to discuss this issue because the initial problem is rooted there.
OK, so continuing here.
System configuration is in attachments. How properly setup logs? If I enable model logger to debug, then each time hook is fired logs increase by 6MB
Yes, model diagnostic is quite verbose. Anyway, I suggest the following:
<classLogger>
<level>TRACE</level>
<package>com.evolveum.midpoint.model.impl.lens.Clockwork</package>
</classLogger>
<classLogger>
<level>TRACE</level>
<package>com.evolveum.midpoint.model.impl.lens.projector.Projector</package>
</classLogger>
...and remove the DEBUG placed at the level of model, i.e. this one:
<classLogger>
<level>DEBUG</level>
<package>com.evolveum.midpoint.model</package>
<appender>IDM-PROFILE_LOG</appender>
</classLogger>
I really suspect that the secondary deltas get recomputed during the process.
Pavol
_______________________________________________
midPoint mailing list
midPoint at lists.evolveum.com<mailto:midPoint at lists.evolveum.com>
http://lists.evolveum.com/mailman/listinfo/midpoint
_______________________________________________
midPoint mailing list
midPoint at lists.evolveum.com<mailto:midPoint at lists.evolveum.com>
http://lists.evolveum.com/mailman/listinfo/midpoint
More information about the midPoint
mailing list