jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: oak api : initial draft
Date Wed, 28 Mar 2012 16:12:22 GMT
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


Mime
View raw message