This is a problem during resurrection and is mostly likely due to the signer and signerWithFullAccess sessions not having been created by the time the Session#readResolve method runs. In a newly-created DB with just these design elements and the ODA library enabled, this seems to happen consistently, but there were times during testing when this problem did NOT arise (for example, in a newly-created DB using my framework, as well as in a clean DB after tinkering). I'm not sure what causes this change in behavior, though. I can see four main options:
1) Modify this behavior so that, instead of trying to re-fetch the session via the same path, it will instead create a native named session for the original user/full-access level
2) Modify the session in such a way that it can delay this lookup. This may be difficult, as the lookup happens in a method called by the ObjectStream, not a manual thing on our side, and so it’d probably have to affect basically everything
3) Leave it unchanged and declare view-scoped signer sessions unsupported
4) Figure out what caused the problem to disappear in some of my tests and make that reproducible
4 would certainly be ideal, but otherwise I personally lean towards 3, as I don't put a lot of value in resurrectible sessions.
However, 2 could be implemented through the not-difficult-but-laborious process of having a sanity-check call at the start of each method to check a boolean that indicates that the session was resurrected in this way but had a delayed restoration to avoid the bug.
Example XPage:
Java class:
On first client, this works, but subsequent clicks hit an NPE:
This is a problem during resurrection and is mostly likely due to the signer and signerWithFullAccess sessions not having been created by the time the
Session#readResolve
method runs. In a newly-created DB with just these design elements and the ODA library enabled, this seems to happen consistently, but there were times during testing when this problem did NOT arise (for example, in a newly-created DB using my framework, as well as in a clean DB after tinkering). I'm not sure what causes this change in behavior, though. I can see four main options:1) Modify this behavior so that, instead of trying to re-fetch the session via the same path, it will instead create a native named session for the original user/full-access level 2) Modify the session in such a way that it can delay this lookup. This may be difficult, as the lookup happens in a method called by the ObjectStream, not a manual thing on our side, and so it’d probably have to affect basically everything 3) Leave it unchanged and declare view-scoped signer sessions unsupported 4) Figure out what caused the problem to disappear in some of my tests and make that reproducible
4 would certainly be ideal, but otherwise I personally lean towards 3, as I don't put a lot of value in resurrectible sessions.
However, 2 could be implemented through the not-difficult-but-laborious process of having a sanity-check call at the start of each method to check a boolean that indicates that the session was resurrected in this way but had a delayed restoration to avoid the bug.