Hi Richard:
The prohibition on consumers generating events themselves isn't a bug, it is
intentional, and follows the design.
It's hard to explain succinctly, but basically the idea is this:
all consumers should see the same logical, consistent set of changes to the
data model.
If consumers can create data model changes then this will no longer be true.
One consumer could 'undo' what another one did,
the order of consumers would matter, etc - the whole processing model would
break down.
Having said this, I completely understand the use-case, and Andrea's ingenious
workaround will do what is needed.
We need better ways of adding extension points in the code for injecting
behavior of the sort you describe.
I'm prototyping some approaches in 'mds' ('LifeCycle Hooks') that operate in
that space and can hopefully migrate to the DSpace codebase in time.
Thanks,
Richard
On Jun 23, 2013, at 6:45 PM, Andrea Schweer wrote:
> Hi,
>
> On 24/06/13 09:21, Richard Jones wrote:
>> I'm trying to write an event consumer which attempts to determine if
>> an item should be withdrawn from the archive on install. I have a
>> consumer which binds to Item+Install, which carries out a test on the
>> item and then calls item.withdraw() if necessary. item.withdraw()
>> triggers a MODIFY event on the item, which is appended to the list of
>> events attached to the context, resulting in a
>> ConcurrentModificationException in the BasicDispatcher. Is there a
>> way around this?
>
> My workaround for this type of situation is to queue a curation task
> from the event consumer and make the change in the curation task. I use
> a special queue that gets worked off every couple minutes since in my
> case, a 2-minute delay isn't a big issue. I haven't managed to find a
> better way to do this (I'm still on 1.8.2 as well).
>
> cheers,
> Andrea
>
> --
> Dr Andrea Schweer
> IRR Technical Specialist, ITS Information Systems
> The University of Waikato, Hamilton, New Zealand
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Dspace-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dspace-devel
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
