okay, published 1.12.1. Hopefully will fix the problem. Should be in the Maven central repo indexes in a couple of hours.
Dan On 26 April 2016 at 07:50, Dan Haywood <[email protected]> wrote: > Hi Igor, > > ok, have managed to track down the issue... it wasn't with the child > command being persisted, rather DN's persistence-by-reachability was trying > to persist the incomplete "parent" command. I think the solution is simply > to not attempt to associate the new background command with any parent > command (there is no "user intent"). > > I'll put out a release this evening. > > Thx > Dan > > > > > > On 14 April 2016 at 21:02, Dan Haywood <[email protected]> > wrote: > >> Ah, ok. >> Apologies that I didn't look at the test case that you kindly put >> together ; I right I had deduced the issue from rereading your email. >> I shall look into it once more! >> Thx, Dan. >> On 14 Apr 2016 20:53, "Igor Lobanov" <[email protected]> >> wrote: >> >>> Dan, >>> Thanks for looking into this. Apologies for not responding promptly, >>> somehow I managed to miss your response. I do use >>> BackgroundCommandExecutionFromBackgroundCommandServiceJdo in my Quartz job >>> to run background commands, but the problem arises before that class gets >>> into the picture, i.e. during the time when CommandJdo is being flushed >>> into the database, which happens in an ordinary Quartz job without any >>> command context. The test app which I have uploaded simlulates this using a >>> simple background thread. >>> -- Best regards, Igor Lobanov >>> >>> On Monday, 11 April 2016, 20:28, Dan Haywood < >>> [email protected]> wrote: >>> >>> >>> >>> Hi Igor, >>> just looking into this now and reminding myself of what the design was... >>> >>> ... did you look into using BackgroundCommandExecution, rather than >>> AbstractIsisSessionTemplate (of which it is a subclass?) This will >>> initialize the parent command for you, I think. >>> >>> The BackgroundCommandExecutionFromBackgroundCommandServiceJdo in turn is >>> a >>> concrete implementation which you could have Quartz call every 30 seconds >>> or so. There's actually an example QuartzJob at [1] >>> >>> HTH >>> Dan >>> >>> >>> [1] >>> >>> https://isis.apache.org/guides/rgsvc.html#_rgsvc_api_BackgroundService_BackgroundCommandExecution >>> >>> >>> >>> >>> On 9 April 2016 at 18:46, Dan Haywood <[email protected]> >>> wrote: >>> >>> > Thanks Igor, >>> > >>> > I'll do my best to take a look tomorrow. >>> > >>> > Dan >>> > >>> > >>> > On 9 April 2016 at 18:45, Igor Lobanov <[email protected]> wrote: >>> > >>> >> I've created simple project demonstrating the behaviour: >>> >> https://github.com/lobanov/apache-isis-bug1 >>> >> >>> >> README.md provides a sequence of steps required to reproduce the >>> >> behaviour, hopefully it is clear enough. >>> >> >>> >> -- Best regards, Igor Lobanov >>> >> >>> >> >>> >> On Saturday, 9 April 2016, 16:21, Dan Haywood < >>> >> [email protected]> wrote: >>> >> >>> >> >>> >> >>> >> Just use the simpleapp archetype and add in the minimal amount of >>> stuff >>> >> needed to demonstrate the issue. >>> >> Thx, >>> >> Dan >>> >> On 9 Apr 2016 16:05, "Igor Lobanov" <[email protected]> >>> >> wrote: >>> >> >>> >> Sure, although I need an advice on how to best approach it. Is there >>> an >>> >> easy way of bootstrapping Isis as a standalone app using HSQL or >>> something >>> >> similar? >>> >> -- Best regards, Igor Lobanov >>> >> >>> >> On Saturday, 9 April 2016, 15:33, Dan Haywood < >>> >> [email protected]> wrote: >>> >> >>> >> >>> >> >>> >> That does sound like an issue. Probably the issue is in the addons >>> >> implementation rather than in Isis "proper", so will a bit easier to >>> >> release a fix if that is a problem. >>> >> >>> >> Could you put together a simple example on github that demonstrates >>> the >>> >> problem, and document on its README how to reproduce? >>> >> >>> >> Thx, >>> >> Dan. >>> >> On 9 Apr 2016 15:28, "Igor Lobanov" <[email protected]> >>> >> wrote: >>> >> >>> >> All, >>> >> I am running business logic in background using Quartz. To that end I >>> am >>> >> extending AbstractIsisSessionTemplate in my job classes and overriding >>> >> doExecuteWithTransaction() to do something useful, so far so good. >>> Now I >>> >> need to schedule some actions to be executed in the background >>> outside the >>> >> main scheduled job. This is because spawned tasks themselves may >>> fail, but >>> >> it must not cause the main job to fail as well. >>> >> The project makes use of isis-module-command addon to schedule >>> background >>> >> commands from the UI, so I went on and wrote a logic that calls >>> >> BackgroundService#execute(...) in the job code. Apparently this >>> doesn't >>> >> work, as I'm getting a few 'cannot insert null into non-null column' >>> when >>> >> CommandJdo INSERTs are being flushed. It is difficult for me to work >>> out >>> >> what the problem is by reading the code, but it seems that >>> >> BackgroundService#execute(...) assumes invocation from the context of >>> >> another parent command, which apparently is not so when the code is >>> >> running >>> >> in a background thread. >>> >> >>> >> Ideally, I want to make use of BackgroundService#execute(...) rather >>> than >>> >> building something custom. Is there a particular way to invoke it >>> from a >>> >> background thread aside from >>> >> AbstractIsisSessionTemplate#doExecuteWithTransaction()? Do I need to >>> >> 'spoof' a parent command somehow? I would appreciate any suggestion. >>> >> -- Best regards, Igor Lobanov >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> > >>> >>> >>> >>> >> >> >
