John: I guess before making any firm recommendation, I'd need to know what your requirements are. Do you, e.g., require transactional closure over the content change that generates the first event and the additions you want your consumer to make based on it? Can you describe what you are trying to accomplish? As noted, both options 2 & 3 cause your code to fork from the distribution, creating maintenance issues in the future.
If you don't need closure, why not just have your consumer add to a list of updates to be made? This is one of the intended uses of the event system when it's hooked up to a message queue, e.g. Thanks, Richard Quoting John Preston <[EMAIL PROTECTED]>: > Sorry to bother you again, but quick question. When does the end() method > get called. Is it after the events arraylist has completed iterations of all > events. if so then I could move all my processing of the bundles, > bitstreams and items to this method. The only other thing I would have to > guard against would be more events of the same type, subject and object > with the same transaction ID. > > > This may be a wise thing to try, yes it is done after "consume" has > completed on all the events, the dispatcher is done with the list of events > at that point. most of the consumers actually do complete their processing > at this point too. But be careful of what I stated above, you need to make > sure this list of Events is coming from the correct Context. > > On Wed, Jun 18, 2008 at 9:33 PM, John Preston <[EMAIL PROTECTED]> wrote: > >> Ok, I think I understand what is happening. When I create or remove >> bundles, or bitstreams or any of these objects >> that generate events, these add new events which cause a concurrent >> modification conflict with the events arraylist, that is being used >> to dispatch the events in the first place. So having anew context will not >> help me. I need to bypass adding new events for any modifications. >> >> I think I have three choices, and your thoughts would be welcome on them. >> >> 1) Keep my code as mediafiletsr run periodically, and wait for 2.0; >> 2) extend the code for Bundles, Items, Bitstreams, etc, anything that >> issues events when the update() method is called, and add another >> update(boolean issueEvent) merthod that performs the database update >> with or without issuing any events, depending on the >> parameter passed; >> 3) implement my own event system; >> >> I'm leaning towards 2 or 3, but I don't know how many DSpace objects issue >> events. I'm playimg with a GWT front end application to some >> RPC services that actually interact with the dspace objects via the >> dspace-api codebase. It has gone pretty quickly up till this point so I'm >> looking for >> the quickest long lasting method. >> >> > I'd avoid (3). I think (2) will be coming in the DSpace 2.0 next year > sometime (we are still at the drawing board on this so its very early). If > you take this route and it isn't compatible with what gets done in our > development, it may be difficult to integrate. (1) Is your safest bet, but I > understand why you want to get away from it. > > If you would, please forward a summary of this to the dspace-tech list as > a reply so that we have a complete thread there. > > Cheers, > Mark > > >> John >> >> >> On Wed, Jun 18, 2008 at 7:26 PM, John Preston <[EMAIL PROTECTED]> >> wrote: >> >>> We do not recommend using a Event Consumer to directly manipulate the Item >>>> in question by adding Bitstreams or altering its metadata because not only >>>> is that available Contexts transactional window is closed by the >>>> time you've >>>> reached processing the Event in the consumer, but its difficult to predict >>>> the behavior or risk of getting the Event System in the state of of an >>>> infinite event loop because your alterations will in turn, also alter the >>>> Item and generate new events in the process. >>>> >>> Yes, I saw that, that's why I started to use >>> context().getDBConnection.commit() to avoid infinite event loops. >>> >>> >>>> Unfortunately, this is the sort of task most folks were hoping the >>>> Event System would solve in DSpace 1.5. I feel we are attempting >>>> to address >>>> its shortcomings in the DSpace 2.0 roadmap to come up with a solution. >>>> >>> That would be great. >>> >>> >>>> If you do decide to attempt to use the Event System in such a manner as >>>> to alter the Object in question and update it again, I would >>>> recommend using >>>> a new dspace Context and make sure you can trap the events in some sort of >>>> conditional check to make sure they should be propagated to through your >>>> Consumer again. >>>> >>> I tried this but I still get the error. I did the following: >>> >>> Context c = new Context(); >>> ctx.setCurrentUser(context.getCurrentUser()); >>> ctx.setCurrentLocale(context.getCurrentLocale()); >>> >>> I'll look again at the code in the morning to see if I can understand >>> where the problem lies. >>> >>> Thanks. >>> >>> John >>> >>>> >>>> >>>> Sincerely, >>>> Mark >>>> >>>> On Jun 18, 2008, at 4:31 PM, John Preston wrote: >>>> >>>> Can someone say whether it is advisable or not to use the new event >>>> system under 1.5 to add metadata or bitstreams to an item. >>>> >>>> I am moving some of my code to event consumers that would add metadata >>>> for various item types as well as add bitstreams based on >>>> bitstreams already >>>> ingested. However I'm getting an exception when I try to commit these >>>> additions within the consumer (either the consume, end or finish methods). >>>> The particular exception is: >>>> >>>> java.util.ConcurrentModificationException >>>> at >>>> java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372) >>>> at java.util.AbstractList$Itr.next(AbstractList.java:343) >>>> at >>>> org.dspace.event.BasicDispatcher.dispatch(BasicDispatcher.java:122) >>>> at org.dspace.core.Context.commit(Context.java:286) >>>> at >>>> org.ejamaica.server.dspace.DSpaceInstance.addSaying(DSpaceInstance.java:1906) >>>> at >>>> org.ejamaica.server.dspace.DSpaceInstance.updateSaying(DSpaceInstance.java:1060) >>>> at >>>> org.ejamaica.server.MyLibraryServiceImpl.myMethod(MyLibraryServiceImpl.java:147) >>>> >>>> Just for info. the section in my code that triggers the initial >>>> context.commit() occurs in DSpaceInstance.java:1906. >>>> >>>> If I don't commit after I add some metadata and/or bitstreams then I >>>> don't get the error, but then the data and bitstreams don't appear. If I >>>> even try and use the context.getDBConnection().commit(); I get the same >>>> exception. >>>> >>>> John >>>> >>>> >>>> ~~~~~~~~~~~~~ >>>> Mark R. Diggory - DSpace Developer and Systems Manager >>>> MIT Libraries, Systems and Technology Services >>>> Massachusetts Institute of Technology >>>> Home Page: http://purl.org/net/mdiggory/homepage >>>> >>>> >>>> >>>> >>>> >>>> >>> >> > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
