On Mar 28, 2012 9:27 PM, "Jukka Zitting" <[email protected]> wrote: > > Hi, > > On Wed, Mar 28, 2012 at 8:52 PM, Michael Dürig <[email protected]> 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.
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. Michael > 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
