Behaviours not triggering consistently

[aweber1nj]

Not entirely sure what to expect here.  Especially given that there was a presentation "promoting" the use of behaviours at DevCon, I would expect them to be pretty stable.

What I am seeing is that the "onRemoveAspect" for sys:incomplete is not consistently triggering my class.  Sometimes it does.  Sometimes it doesn't.  It may be that it is not triggering if the node is already running another behaviour-method (such as onUpdateProperties) – but that doesn't make a lot of sense, since Alfresco shouldn't care that both apply to the node, and it should trigger them both.

I have a logging statement as the first line in the method, and it doesn't show up in the log when you'd expect it – in fact, it doesn't show up ever for some of the nodes I'm testing with.  I know, based upon other logging that the node has sys:incomplete aspect (and it should, because there are mandatory properties missing).  After updating some properties, it should no longer have the aspect, and based upon the output of onUpdateProperties, and checking with node-browser, that is correct – the aspect is gone…but the code for onRemoveAspect never ran.

So are we to trust behaviours or not?  Are they "best effort", or "contractual"?  It makes a big difference when you're trying to code business logic.

Thanks,
AJ

[andy]

Hi

I suggest you also turn on logging for
org.alfresco.repo.node.integrity.IncompleteNodeTagger

The IncompleteNodeTagger builds a list of stuff to consider via the behaviour binding and does all its work on the beforeCommit as it is a TransactionListener - but it should still fire the behaviour related to the aspect removal.

Can you provide a bit more detail about what you are doing? How the behaviour is bound, if you bind any transaction listener, how you deal with transactions etc.

Hope this helps

Andy

[aweber1nj]

Thanks for the quick reply.  I'll try to add some more details, but feel free to ask-away…

The behaviour class is java, with 3 methods bound to our custom document type on init with policyComponent.bindClassBehaviour:

onCreateNode
onMoveNode
onUpdateProperties

The same class is bound using the same method (I think this is correct since there is no explicit "bindAspectBehaviour" that I can find) to sys:incomplete as follows:

onRemoveAspect = new JavaBehaviour(this, "onRemoveAspect", NotificationFrequency.TRANSACTION_COMMIT);
policyComponent.bindClassBehaviour(QName.createQName(NamespaceService.ALFRESCO_URI, "onRemoveAspect"),
                ContentModel.ASPECT_INCOMPLETE, this.onRemoveAspect);‍‍‍

The init and some portions of the code are modeled from Jeff's "Behavior Article v2".

We need to mandate some properties for imported document-nodes in certain paths of the repository.  The properties are setup as mandatory=true, enforced=false.  We detect the import and pop-up the "doclib-simple-metadata" properties form for each.  This happens after the Folder Rule has already "specialised type" to our document type.  We also have some automated rendition services and optional OCR processing, so we have built a custom Action to call (run async) that sends the document for its Thumbnail and either an automatic PDF rendition or, in the case of images/PDF-Images, for OCR.

The execution of the rendering Action should optimally be started "ASAP" once content is saved for the node, but in order to workaround bug (sorry, issue) https://issues.alfresco.com/jira/browse/ALF-9688, we added code to the behaviour class to detect when the properties are done being set.  We determined that one of the most appropriate manners to detect this is when the node is no longer "incomplete", because the user has added the necessary properties.

What I was describing in my OP is a theory that the threading model of the behaviour classes in general is insufficient to allow this, because the behaviour is (sometimes – and the inconsistency drives me crazy) already executing the onUpdateProperties when the onRemoveAspect would also be called.  (Again, theory/conjecture)

I don't even have the automated pop-up installed in one env (removing it from the variables), and importing an object it gets correctly "specalised" as per rule, and if I look at my behaviour log it correctly notes that it is incomplete (most times – I have seen cases where the aspect is apparently applied "later", again lack of execution-order-consistency is killing me).  Checking node browser confirms the aspect is applied.  Then I use Share to edit the properties, and upon saving them, the behaviour's onUpdateProperties is successfully called, but not the onRemoveAspect.  Navigating to the node browser confirms that the incomplete-aspect is gone from the node, but reviewing the log (second…third time…) shows no call made to the behaviour for the removal.

I am trying to think of another reason it wouldn't be called, but even at that, I would expect some kind of error or warning to be logged if it couldn't, and I don't find anything in alfresco.log or catalina.out…so I'm back to wondering if it's being detected and called at all?

Hopefully that tells the whole story.  I appreciate any insight, tips, and direction provided.  We are developing and testing against 4.0.

-AJ

[andy]

Hi

The incomplete tagging and your behaviour are both bound into the end of transaction from what I can see.
These are then taken out of a set and executed in random order - once executed they may see notifications but never get the beforeCommit call …
So sometimes the incomplete tagging comes first, sometimes second is my guess.

As the aspect is added in the beforeCommit - your behaviour beforeCommit may have been done and then unregistered the listener => It never saw the aspect added next. The debug will show this.


You need to change IncompleteNodeTagger to do what you want in one step - fix it up and wire up the changed version in place of what we ship.

Andy

[aweber1nj]

Thanks very much for the quick and detailed replies, Andy.  It's very much appreciated.

I'll grab that source and see if I should work with that.

Can you enlighten me what package/classes might be performing the tasks as they

are then taken out of a set and executed in random order

?  I'm very curious to understand what "services" and whatnot are responsible for determining actions and callbacks that need to be executed and how they thread them and in what order.  Hopefully there's some reference already, or if you know of a starting-point class-name I can work my way through, that would be great.

Thanks again for the help.

-AJ