On 01/06/2017 12:38 AM, Dan Haywood wrote:
Hi Erik,
Looks like an error in BackgroundCommandServiceJdo [1]. It's setting the
child command's reference to the parent command, and then the latter gets
persisted due to persistence-by-reachability.
You can workaround this by creating your own version of
BackgroundCommandService2, with @DomainService(menuOrder="50") say so that
it is picked up first. Copy the existing class and adjust.
Ideally the implementatation needs to find out the ObjectAction
corresponding to the parent Command, and check its CommandFacet. That will
mean reaching deep into the Apache Isis metamodel, I think ... I don't
think there's any formal API for that I'm afraid.
Or, you could go for the cheap-n-cheerful approach which is to check for
the length of the targetStr of the parent Command, and set the child's
parent ref to null if too long. You could use code similar to that in
CommandServiceJdo to do this [2]
How many levels can a command tree have? If more than 2 it would have to
check this recursively...
Meantime I've raised an issue on the module [3]. PRs happily received if
you have the time to fix properly.
Thanks Dan, will see if/how I can fix this.
Thx
Dan
[1]
https://github.com/isisaddons/isis-module-command/blob/master/dom/src/main/java/org/isisaddons/module/command/dom/BackgroundCommandServiceJdo.java#L117
[2]
https://github.com/isisaddons/isis-module-command/blob/master/dom/src/main/java/org/isisaddons/module/command/dom/CommandServiceJdo.java#L92
[3] https://github.com/isisaddons/isis-module-command/issues/14
On Wed, 4 Jan 2017 at 14:18 Erik de Hair <[email protected]> wrote:
On 01/04/2017 10:14 AM, Erik de Hair wrote:
So now it seems an action in the registered domainEvent is persisted
as a command and while debugging I can see the finish()-action is it's
parent command. Will persisting the action from the domainEvent
trigger persistence of it's parent also, eventhough it shouldn't be
persisted? The targetStr-property of the finish()-command is not null.
Could that be messing things up?
It ís messing things up. The subscriber for the WbaOrderFinishedEvent
starts another background-command. If I disable this call everything
works fine. This call really needs to be done in the background so how
can I make this work?
On 01/04/2017 09:32 AM, Erik de Hair wrote:
Hi,
We have a view model with following action:
@Action(domainEvent = WbaOrderFinishedEvent.class, publishing =
Publishing.DISABLED, commandPersistence =
CommandPersistence.NOT_PERSISTED)
@Override
public AbstractEndUserAccessSubscription finish(){
....
}
The application is still trying to persist the action as a command
and it complains about the length of the target-column, while it
should be set to null for view models, isn't it?
INSERT INTO Command
(arguments,completedAt,`exception`,executeIn,memberIdentifier,memento,parentTransactionId,`result`,startedAt,targetAction,targetClass,target,`timestamp`,`user`,transactionId)
VALUES (<''>,<2017-01-04
09:13:53.264>,<'javax.jdo.JDOFatalUserException: Attempt to store
value
"*nl.pocos.dom.access.kpn.wba.order.WbaFiberOrderForm:PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPG1lbWVudG8-PGN1c3RvbWVyLmJvb2ttYXJrPm5sLnBvY29zLmRvbS5jb21wYW55LlBvcnRhbENvbXBhbnk6aV8xMDM8L2N1c3RvbWVyLmJvb2ttYXJrPjxjb25uZWN0aW9uQXJ0aWNsZS5ib29rbWFyaz5ubC5wb2Nvcy5kb20uYXJ0aWNsZS5BYnN0cmFjdEFydGljbGU6aV8xMzgxPC9jb25uZWN0aW9uQXJ0aWNsZS5ib29rbWFyaz48Y3VzdG9tZXJSZWZlcmVuY2U-a2xhbnRyZWZlcmVudGllPC9jdXN0b21lclJlZmVyZW5jZT48dGVjaG5vbG9neUltcGw-RnR0SDwvdGVjaG5vbG9neUltcGw-PGFydGljbGVQQy5ib29rbWFyaz5ubC5wb2Nvcy5kb20uYXJ0aWNsZS5BYnN0cmFjdEFydGljbGU6aV8xMzgwPC9hcnRpY2xlUEMuYm9va21hcms-PGNsYXNzT2ZTZXJ2aWNlUEM-U3RhbmRhcmQ8L2NsYXNzT2ZTZXJ2aWNlUEM-PGNvbm5lY3Rpb25BZGRyZXNzLmJvb2ttYXJrPipubC5wb2Nvcy5hcHBsaWIuQWRkcmVzczpQRDk0Yld3Z2RtVnljMmx2YmowaU1TNHdJaUJsYm1OdlpHbHVaejBpVlZSR0xUZ2lQejRLUEcxbGJXVnVkRzgtUEdodmRYTmxUblZ0WW1WeVBqRTFNand2YUc5MWMyVk9kVzFpWlhJLVBISmxjMmxrWlc1alpUNUZTVTVFU0U5V1JVNDhMM0psYzJsa1pXNWpaVDQ4YzNSeVpXVjBQa2RGVEVSU1QxQlRSVmRIUEM5emRISmxaWFEtUEhwcGNFTnZaR1UtTlRZeE5FRkZQQzk2YVhCRGIyUmxQand2YldWdFpXNTBiejQ9PC9jb25uZWN0aW9uQWRkcmVzcy5ib29rbWFyaz48Y29ubmVjdGlvblBvaW50RGV0YWlscz5beyJjdXJyZW50T2RmQWNjZXNzU2VydmljZUlkIjoiUkVGMDAwMTk3OTEyNCIsImZ1dHVyZU9kZkFjY2Vzc1NlcnZpY2VJZCI6IiIsImNvbm5lY3Rpb25UeXBlcyI6eyIwIjoiTm90IGluIHVzZSIsIjEiOiJGaXhlZCBsaW5lIHNlcnZpY2UiLCIyIjoiVGVsZXBob255IHNlcnZpY2UiLCIzIjoiTURGIGJyb2FkYmFuZCBzZXJ2aWNlIiwiNCI6IlNERiBicm9hZGJhbmQgc2VydmljZSIsIjUiOiJPREYgYnJvYWRiYW5kIHNlcnZpY2UiLCI2IjoiT0RGIGJyb2FkYmFuZCBzZXJ2aWNlIGJsb2NrZWQiLCI3IjoiT0RGIGJyb2FkYmFuZCBzZXJ2aWNlIGRlZmVjdCIsIjgiOiJVbmtub3duIHNlcnZpY2UiLCI5IjoiTm8gY2hhbmdlIiwiMTAiOiJNREYgQnVuZGxlIiwiMTEiOiJTREYgQnVuZGxlIn0sImN1cnJlbnRUeXBlT2ZDb25uZWN0aW9uIjoiNSIsImZ1dHVyZVR5cGVPZkNvbm5lY3Rpb24iOiI5In1dPC9jb25uZWN0aW9uUG9pbnREZXRhaWxzPjxuYXQ-ZmFsc2U8L25hdD48cG9ydGZvbGlvPldfQURTTDwvcG9ydGZvbGlvPjxzdGF0ZT5TVU1NQVJZX1BBR0U8L3N0YXRlPjx0ZWNobm9sb2d5PkZ0dEg8L3RlY2hub2xvZ3k-PG1heE5sc1R5cGU-NjwvbWF4TmxzVHlwZT48d2lzaERhdGU-MjAxNy0wMS0yNTwvd2lzaERhdGU-PG9yZGVyU2NlbmFyaW8-TmV3X0xpbmU8L29yZGVyU2NlbmFyaW8-PHNlcnZpY2VMZXZlbD5CRVNUX0VGRk9SVDwvc2VydmljZUxldmVsPjxjb25uZWN0aW9uQWRkcmVzc0NvbnRhY3ROYW1lPlBpZXQgU25vdDwvY29ubmVjdGlvbkFkZHJlc3NDb250YWN0TmFtZT48Y29ubmVjdGlvbkFkZHJlc3NDb250YWN0UGhvbmU-KzMxNDAyMTM0NTc4PC9jb25uZWN0aW9uQWRkcmVzc0NvbnRhY3RQaG9uZT48Y29ubmVjdGlvbkFkZHJlc3NDb250YWN0UGhvbmVBZGRpdGlvbmFsPiszMTQwMjEzNDU3OTwvY29ubmVjdGlvbkFkZHJlc3NDb250YWN0UGhvbmVBZGRpdGlvbmFsPjxjb25uZWN0aW9uQWRkcmVzc0NvbnRhY3RFbWFpbD5wZXRAcG9jb3Mubmw8L2Nvbm5lY3Rpb25BZGRyZXNzQ29udGFjdEVtYWlsPjx1bnRhZ2dlZD50cnVlPC91bnRhZ2dlZD48dm9pY2VQcmlvcml0eVBDPnRydWU8L3ZvaWNlUHJpb3JpdHlQQz48dm9pY2VQcmlvcml0eUFDPmZhbHNlPC92b2ljZVByaW9yaXR5QUM-PGluc3RhbGxTZXJ2aWNlPmZhbHNlPC9pbnN0YWxsU2VydmljZT48Yml0cmF0ZURvd24-MTAwMDAwMC4wPC9iaXRyYXRlRG93bj48Yml0cmF0ZVVwPjEwMDAwMDAuMDwvYml0cmF0ZVVwPjxmdHVBdENvbm5lY3Rpb25BZGRyZXNzPkZUVV9UWTAxPC9mdHVBdENvbm5lY3Rpb25BZGRyZXNzPjwvbWVtZW50bz4="
in column "target" that has maximum length of 2000. Please correct
your data!
How to fix this?
Thanks,
Erik
