jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: oak api : initial draft
Date Wed, 28 Mar 2012 18:52:09 GMT


>> 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
>

Mime
View raw message