hi michi ui, that was fast :)
SessionInfo.dispose(): do we need this? To me SessionInfo looks like a state less data object (i.e. a value) carrying information related to a user's session.
well, i am quite sure that i need it once i have a real authentication mechanism associated with it. and once a session is logged out i would like to make sure that the session info associated with it is aware of this.
Whether a Connection is repository bound or bound to a single workspace depends on whether we want to expose the concept of a workspace through the oak API or whether the oak API should rather expose a tree and we decorate workspaces on top in oak-jcr. Maybe thinking of the other bindings for the oak API gives us a better clue.
may take on this was the following: right now i plan to have the RepositoryService#login to take the workspace name into account as imo the user/groups should continue to be defined on a workspace level (or at least that should be possible). in this case the session info was already bound to a given workspace and subsequently the Connection was bound to that workspace as well. similarly i don't think that oak-jcr should be in charge of defining what the default workspace name was. imo that was the responsibility of the overall repository setup process that would imo reside somewhere in oak-core.
CommitFailedException (mechanism to inform the oak-jcr level about the specific type of exception): - nested jcr exception: this would create a dependency of oak-core on jcr which we might want to avoid.
well, yes. but i am not yet totally sure if we can avoid it.
- extends RepositoryException: same as above but much worse: checked exceptions don't compose. That is, we'll get into lot of problems being forced to handle these exceptions in implementations of interfaces which do not allow exceptions to be thrown (Iterator.next, Comperator.compare, ...). - Status code: I think this is the way to go. I'd include the status code as an enum in the exception.
as far as i am concerned i dislike using a status code when in fact i encounter an exceptional state. why shouldn't i throw AccessDeniedException right away when i find a permission violation upon validating a given write operation in oak-core? having a status code and then relying that oak-jcr is making the right lookup and really is raising the exception looks a bit odd and error-prone to me. kind regards angela
