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.
Ok that makes send. Let's keep it then.
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.
Yes that was my initial thinking too. That would mean the connections
are bound to a workspace. And workspaces (and workspace management)
would have to be exposed somehow through the oak API.
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.
Right.
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.
If we can live with the JCR dependency in oak-core, then I'm fine with
the first approach. That is, use a nested jcr exception. However, I
think we should not make CommitFailedException extend
RepositoryException but rather make it extend RuntimeException.
Michael
kind regards
angela
