jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mic...@gmail.com>
Subject Re: oak api : initial draft
Date Wed, 28 Mar 2012 20:51:10 GMT
On Mar 28, 2012 9:27 PM, "Jukka Zitting" <jukka.zitting@gmail.com> wrote:
> Hi,
> 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
> > bound to a workspace. And workspaces (and workspace management) would
> > 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
> > first approach. That is, use a nested jcr exception. However, I think we
> > should not make CommitFailedException extend RepositoryException but
> > 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.

Yes I know this has been standard Java practise for long. However it
introduces more troubles than its worth: some methods on the call tree
might neither be able to meaningfully handle nor throw an exception. In
these cases you are left with two options: wrap into a RuntimeException
which makes the whole thing pointless or log and ignore which might not
even be possible if you have to return a value.
For this reason l would prefer to extend from RuntimeException only.


> 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
> implementation.
> BR,
> Jukka Zitting

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message