[
https://issues.apache.org/jira/browse/ISIS-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13841392#comment-13841392
]
ASF subversion and git services commented on ISIS-627:
------------------------------------------------------
Commit a8381b5d60dfc7d6913e2740af04d5c393d65df1 in branch refs/heads/master
from [~danhaywood]
[ https://git-wip-us.apache.org/repos/asf?p=isis.git;h=a8381b5 ]
ISIS-627: fix for deleting lazily-loaded pojos
> Lazily loaded object cannot be deleted, throws an NPE
> -----------------------------------------------------
>
> Key: ISIS-627
> URL: https://issues.apache.org/jira/browse/ISIS-627
> Project: Isis
> Issue Type: Bug
> Components: Core
> Affects Versions: core-1.3.0
> Reporter: Dan Haywood
> Assignee: Dan Haywood
> Fix For: core-1.4.0
>
>
> In Estatio, the LeaseTerm entity forms a chain, each pointing to the previous
> and next. When a Lease is terminated, the algorithm is to spin through all
> the LeaseTerms and those in the future that are no longer needed. This is
> done recursively:
> LT1 -> LT2 -> LT3 -> LT4
> So, for example LT3 and LT4 would be deleted.
> The issue we've found is that calling container.remove() on LT4 fails with an
> NPE in core (PersistenceSession#destroyObject. This is because the adapter
> passed in is null.
> ~~~
> The root cause seems to be that LT4 is lazily loaded from LT3. JDO hasn't yet
> had occasion to load LT4, which means, in turn, that the pojoAdapter/pojo are
> not in Isis maps.
> In the call to PersistenceSession#destroyObject, the code is using
> AdapterManager#getAdapterFor(pojo), which will return null if the object is
> not yet loaded in the maps.
> The fix is a one-liner... use AdapterManager#adapterFor(pojo), which will map
> the pojo to a pojoAdapter if required.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
