jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: oak api : initial draft
Date Wed, 28 Mar 2012 20:26:28 GMT

On Wed, Mar 28, 2012 at 8:52 PM, Michael Dürig <mduerig@apache.org> wrote:
>> 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.

Assuming we merge SessionInfo and Connection together, I suggest we
make the resulting interface extend Closeable instead of having a
custom dispose() method.

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

I'm a bit hesitant about this. It basically means that all
cross-workspace operations will need custom API calls. If we make the
login call per-repository and treat workspaces more or less just as a
convention on the content structure, then oak-jcr can easily implement
things like workspace management, etc. with no extra API or support
from the oak-core level.

If the only reason why we need to expose the workspace concept at this
level is to support potentially separate users per each workspace,
then I'd rather handle that with a virtual repository mechanism that
just connects to a separate underlying repository instance for each
requested workspace. I don't think we have too many existing
deployments where different workspaces are a) used in the first place,
or b) have separate sets of associated user accounts.

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

Commit failure is an "expected" error condition in the sense that I
can write client code that I can expect to always produce a failed
commit. There are also cases where a client can be expected to recover
from a failed commit, for example by using some application-level
algorithm to resolve merge conflicts or constraint violations. Thus I
think this situation should be handled either as an explicit return
value or a checked exception. In this case (the commit() signature as
drafted) a checked exception seems to me like the most natural choice.

In contrast I'd reserve RuntimeExceptions to unexpected conditions
that only occur at runtime. In other words I shouldn't be able to
write an otherwise valid client application (i.e. no null arguments to
methods that don't allow nulls) that I know in advance will cause an
unchecked exception to be thrown from within the repository


Jukka Zitting

View raw message