Re: oak api : initial draft
Hi, 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. Just for completeness, could you give an example? For this reason l would prefer to extend from RuntimeException only. Me too. Regards, Thomas
Re: oak api : initial draft
hi Assuming we merge SessionInfo and Connection together for the time being i would like to keep it separated as from my point of view the result of login to the repository was something different than operating on the data contained therein. furthermore, having slept over the 'Connection' interface i am not so confident any more that it's name really fits the purpose that i was looking for... for me 'Connection' sounds very vague. i am fine with that for the time being as we are still very vague and just need something to get started. but i in the long run this may need some refinement. 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. yes... somehow that was my idea as well. and i am not convinced that mixing the repository-workspace concept on the oak-api was the right way to go... currently this is more of a gut feeling with some individual concerns popping up here and there. 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. i am not sure if we can really easily implement things like workspace management: for example creating a new workspace needs some initial workspace setup (creating the root node, initial permissions, users) and i doubt that oak-jcr was the right place to do that. 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. well, didn't we decide at the last f2f that we are not going to implement a virtual repository mechanism? for me that proposal generates quite some question marks. having users being represented as regular items in a given workspace feels very natural to me and it has proven to fit our needs very well. kind regards angela
Re: oak api : initial draft
Assuming we merge SessionInfo and Connection together for the time being i would like to keep it separated as from my point of view the result of login to the repository was something different than operating on the data contained therein. furthermore, having slept over the 'Connection' interface i am not so confident any more that it's name really fits the purpose that i was looking for... for me 'Connection' sounds very vague. i am fine with that for the time being as we are still very vague and just need something to get started. but i in the long run this may need some refinement. I quite like the name Connection and the idea of merging it with SessionInfo and have the Connection provide access to some AuthInfo. To me SessionInfo sounds vague ;-) Anyhow, I attached a patch to OAK-18 demonstrating my line of thinking. Michael
Re: oak api : initial draft
hi michi furthermore, having slept over the 'Connection' interface i am not so confident any more that it's name really fits the purpose that i was looking for... for me 'Connection' sounds very vague. i am fine with that for the time being as we are still very vague and just need something to get started. but i in the long run this may need some refinement. I quite like the name Connection and the idea of merging it with SessionInfo and have the Connection provide access to some AuthInfo. To me SessionInfo sounds vague ;-) Anyhow, I attached a patch to OAK-18 demonstrating my line of thinking. AuthInfo or SessionInfo... both fine with me. similarly i can live with that info being exposed from the Connection and that latter being Closeable. feel free to apply the patch. i think it's important that we play around with draft code, get a feeling if the pros and cons while using it. and last but not least changing each others draft code will help us become familiar with each others code and reach consensus on how to built that oak-api (that's my feeling). kind regards angela
Re: oak api : initial draft
hi michi i am not sure if we can really easily implement things like workspace management: for example creating a new workspace needs some initial workspace setup (creating the root node, initial permissions, users) and i doubt that oak-jcr was the right place to do that. What about an solution which covers both, workspace bound connections and repository bound connections? In such a setup you'd get a workspace bound connection from the RepositoryService and you could get a Repository bound connection from the a given Connection. The latter could then be used for cross workspace operations. why not... let's give it a try. but let's keep the following aspects in mind: - the oak-api boundary has to offer the ability for remoting in some way or the other. - the oak-api implementation (oak-core) should be responsible for all the consistency checks and overall system security. - how does it feel from a API design perspective that the oak-api will expose versioning methods, query, possibly locking. there needs also be some sort of 'hasPermission' check... we will hopefully see pretty soon if that works and if the API looks consistent and complete. regards angela
Re: oak api : initial draft
On 29.3.12 11:20, Angela Schreiber wrote: hi michi i am not sure if we can really easily implement things like workspace management: for example creating a new workspace needs some initial workspace setup (creating the root node, initial permissions, users) and i doubt that oak-jcr was the right place to do that. What about an solution which covers both, workspace bound connections and repository bound connections? In such a setup you'd get a workspace bound connection from the RepositoryService and you could get a Repository bound connection from the a given Connection. The latter could then be used for cross workspace operations. why not... let's give it a try. but let's keep the following aspects in mind: I added this in revision 1306786 and 1306787. However we might want to further refine this into a WorkspaceConnection and a RepositoryConnection in case it turns out that too many of the methods on Connection don't make sense for both. But for the time being let of with this and see if it works at all. Michael - the oak-api boundary has to offer the ability for remoting in some way or the other. - the oak-api implementation (oak-core) should be responsible for all the consistency checks and overall system security. - how does it feel from a API design perspective that the oak-api will expose versioning methods, query, possibly locking. there needs also be some sort of 'hasPermission' check... we will hopefully see pretty soon if that works and if the API looks consistent and complete. regards angela
Re: oak api : initial draft
Hi, Am 29.03.2012 um 11:55 schrieb Jukka Zitting: (6) CommitFailedException is a checked exception. Do we really want this? I do, but others disagree. To be discussed. In addition, we said, there should be a root exception, right ? Why? This is a specific, strongly typed part of the commit() signature as drafted. I don't (yet) see a need for it to be related to any other exception in the API. Most notably I don't see much need for a generic Oak- or RepositoryException that a client can't do anything reasonable with. Let's just use RuntimeException for such cases. Well, if I cannot do anything about the exception, this is a sure sign for a RuntimeException. But I might still want to catch them regardless of the actual detail and do something about it. Having a common root exception here helps tremendously. Otherwise I would have to catch all sorts of exceptions and replicate the same actions. Having a common root exception does not hurt the implementation but helps the user. Regards Felix
Re: oak api : initial draft
Great! I was just about to start working on this since this is also a prerequisite for getting OAK-20 resolved. I'll have a look at the draft and let you know. Michael On 28.3.12 15:11, Angela Schreiber wrote: hi all jukka and myself just were sitting together to define an very first draft of the oak-api just to have something to start with and to have a basis for further discussions. i will commit it as soon as i run the build without error. it will consist of an initial Service that provides - login providing a sessioninfo - ability to retrieve a Connection for that sessioninfo the Connection (still to be defined it this represent a workspace or the whole repository) would then give access to node states (based on permissions for the session associated with it), be in charge of validating changes to be committed and executing queries. will doing so we still had a lot of open questions some of which are marked as todos in the interfaces. feedback is welcome regards angela On 3/28/12 3:50 PM, Michael Dürig wrote: On 28.3.12 14:27, Thomas Mueller wrote: Hi, Could you come up with an implementation which does not directly depend on the Microkernel but rather uses a (to be defined) API on oak-core? Sure, let's define such an API. I'll try to come up with some ideas later today. Need to get a clearer picture for myself first. I'm in the process of removing all dependencies from oak-jcr to oak-mk (OAK-20) so this will ultimately break. Sure. What I used is a temporary workaround, this is not meant to stay as it is. Ok great. Michael Regards, Thomas
Re: oak api : initial draft
hi michi just as an additional side note: the conversation between jukka and myself also included some first ideas on how a given repository is being created, who is being in charge of the initial setup and creating the mk and the service instance and how once the repository exists a new instance of the JCR repository is being retrieved from the factory. jukka promised to work on this such that we will soon be able to get a clearer picture here as this basically has an impact on everything related to oak-jcr and oak-core. kind regards angela On 3/28/12 4:58 PM, Michael Dürig wrote: Great! I was just about to start working on this since this is also a prerequisite for getting OAK-20 resolved. I'll have a look at the draft and let you know. Michael On 28.3.12 15:11, Angela Schreiber wrote: hi all jukka and myself just were sitting together to define an very first draft of the oak-api just to have something to start with and to have a basis for further discussions. i will commit it as soon as i run the build without error. it will consist of an initial Service that provides - login providing a sessioninfo - ability to retrieve a Connection for that sessioninfo the Connection (still to be defined it this represent a workspace or the whole repository) would then give access to node states (based on permissions for the session associated with it), be in charge of validating changes to be committed and executing queries. will doing so we still had a lot of open questions some of which are marked as todos in the interfaces. feedback is welcome regards angela On 3/28/12 3:50 PM, Michael Dürig wrote: On 28.3.12 14:27, Thomas Mueller wrote: Hi, Could you come up with an implementation which does not directly depend on the Microkernel but rather uses a (to be defined) API on oak-core? Sure, let's define such an API. I'll try to come up with some ideas later today. Need to get a clearer picture for myself first. I'm in the process of removing all dependencies from oak-jcr to oak-mk (OAK-20) so this will ultimately break. Sure. What I used is a temporary workaround, this is not meant to stay as it is. Ok great. Michael Regards, Thomas
Re: oak api : initial draft
Hi, Some initial comments to the API draft below: 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. I think we should try to not associate any resources to be disposed with this. These should go into Connection. That is, I'd remove the dispose() method initially and add them back later on when we have a compelling reason to do so. 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. 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. - 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. Michael On 28.3.12 15:11, Angela Schreiber wrote: hi all jukka and myself just were sitting together to define an very first draft of the oak-api just to have something to start with and to have a basis for further discussions. i will commit it as soon as i run the build without error. it will consist of an initial Service that provides - login providing a sessioninfo - ability to retrieve a Connection for that sessioninfo the Connection (still to be defined it this represent a workspace or the whole repository) would then give access to node states (based on permissions for the session associated with it), be in charge of validating changes to be committed and executing queries. will doing so we still had a lot of open questions some of which are marked as todos in the interfaces. feedback is welcome regards angela On 3/28/12 3:50 PM, Michael Dürig wrote: On 28.3.12 14:27, Thomas Mueller wrote: Hi, Could you come up with an implementation which does not directly depend on the Microkernel but rather uses a (to be defined) API on oak-core? Sure, let's define such an API. I'll try to come up with some ideas later today. Need to get a clearer picture for myself first. I'm in the process of removing all dependencies from oak-jcr to oak-mk (OAK-20) so this will ultimately break. Sure. What I used is a temporary workaround, this is not meant to stay as it is. Ok great. Michael Regards, Thomas
Re: oak api : initial draft
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
Re: oak api : initial draft
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
Re: oak api : initial draft
Hi, Some more things that crossed my mind: - Is it possible to open multiple Connection instances with one SessionInfo? What would be the purpose of this? Can I commit a NodeState created with a NodeBuilder from one Connection into another Connection? - Wouldn't it be simpler and sufficient to have a 1:1 relationship between SessionInfo and Connection? Again: can I commit a NodeState created with a NodeBuilder from one Connection into another Connection (from another SessionInfo in this case)? - Do we want to make any guarantees wrt. thread safety on Connection? - Having NodeState and NodeBuilder in the oak-core API currently introduces a dependency on oak-mk for clients of that API. We should probably move the interfaces which are used across the stack to some common location. - ... probably more to come ;-) Michael On 28.3.12 15:11, Angela Schreiber wrote: hi all jukka and myself just were sitting together to define an very first draft of the oak-api just to have something to start with and to have a basis for further discussions. i will commit it as soon as i run the build without error. it will consist of an initial Service that provides - login providing a sessioninfo - ability to retrieve a Connection for that sessioninfo the Connection (still to be defined it this represent a workspace or the whole repository) would then give access to node states (based on permissions for the session associated with it), be in charge of validating changes to be committed and executing queries. will doing so we still had a lot of open questions some of which are marked as todos in the interfaces. feedback is welcome regards angela On 3/28/12 3:50 PM, Michael Dürig wrote: On 28.3.12 14:27, Thomas Mueller wrote: Hi, Could you come up with an implementation which does not directly depend on the Microkernel but rather uses a (to be defined) API on oak-core? Sure, let's define such an API. I'll try to come up with some ideas later today. Need to get a clearer picture for myself first. I'm in the process of removing all dependencies from oak-jcr to oak-mk (OAK-20) so this will ultimately break. Sure. What I used is a temporary workaround, this is not meant to stay as it is. Ok great. Michael Regards, Thomas
Re: oak api : initial draft
Hi, On Wed, Mar 28, 2012 at 9:13 PM, Michael Dürig mdue...@apache.org wrote: - Is it possible to open multiple Connection instances with one SessionInfo? What would be the purpose of this? Can I commit a NodeState created with a NodeBuilder from one Connection into another Connection? - Wouldn't it be simpler and sufficient to have a 1:1 relationship between SessionInfo and Connection? Again: can I commit a NodeState created with a NodeBuilder from one Connection into another Connection (from another SessionInfo in this case)? I think it would make sense to merge SessionInfo and Connection to a singe interface. The main reason we didn't do that yet is the handling of credentials and session attributes (i.e. as a way for custom authentication components to pass information back and forth across the API) that felt out of place in Connection. I'd rather get rid of session attributes entirely at this level (and use the JAAS model for any across-the-stack communcation), but I think we need to keep it for now for compatibility with existing authentication components designed for Jackrabbit 2.x. Anyway, having thought about this a bit more, I'd support merging SessionInfo and Connection to a single Connection (or some other similarly named) interface. - Do we want to make any guarantees wrt. thread safety on Connection? I don't see a strong use case where we'd need thread-safety at this level. Unless we come up with one, I suggest we don't make such guarantees on Connection level. - Having NodeState and NodeBuilder in the oak-core API currently introduces a dependency on oak-mk for clients of that API. We should probably move the interfaces which are used across the stack to some common location. Right. This would be a non-issue if we hadn't split oak-core apart... Anyway, I'd rather keep the oak-mk reference as is for now until we encounter a case of why we'd truly need a different tree model on the oak-core level. For example the CoreValue class that Thomas now has for the query code might well be something that we need to consider also from an API perspective. BR, Jukka Zitting
Re: oak api : initial draft
Hi, On Wed, Mar 28, 2012 at 8:52 PM, Michael Dürig mdue...@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 implementation. BR, Jukka Zitting
Re: oak api : initial draft
On Mar 28, 2012 8:52 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Wed, Mar 28, 2012 at 9:13 PM, Michael Dürig mdue...@apache.org wrote: - Is it possible to open multiple Connection instances with one SessionInfo? What would be the purpose of this? Can I commit a NodeState created with a NodeBuilder from one Connection into another Connection? - Wouldn't it be simpler and sufficient to have a 1:1 relationship between SessionInfo and Connection? Again: can I commit a NodeState created with a NodeBuilder from one Connection into another Connection (from another SessionInfo in this case)? I think it would make sense to merge SessionInfo and Connection to a singe interface. The main reason we didn't do that yet is the handling of credentials and session attributes (i.e. as a way for custom authentication components to pass information back and forth across the API) that felt out of place in Connection. I'd rather get rid of session attributes entirely at this level (and use the JAAS model for any across-the-stack communcation), but I think we need to keep it for now for compatibility with existing authentication components designed for Jackrabbit 2.x. Anyway, having thought about this a bit more, I'd support merging SessionInfo and Connection to a single Connection (or some other similarly named) interface. Connection seems like a good name to me. Re. Session attributes: we could encapsulate these and other information regarding authentication in a AuthInfo class which can be retrieved from the connection. - Do we want to make any guarantees wrt. thread safety on Connection? I don't see a strong use case where we'd need thread-safety at this level. Unless we come up with one, I suggest we don't make such guarantees on Connection level. +1. Let's state this explicitly in the javadoc. - Having NodeState and NodeBuilder in the oak-core API currently introduces a dependency on oak-mk for clients of that API. We should probably move the interfaces which are used across the stack to some common location. Right. This would be a non-issue if we hadn't split oak-core apart... ;-) Anyway, I'd rather keep the oak-mk reference as is for now until we encounter a case of why we'd truly need a different tree model on the oak-core level. For example the CoreValue class that Thomas now has for the query code might well be something that we need to consider also from an API perspective. Ok ack. Afaics we might need a different tree model anyway at some point. 1. Since we probably want to return CoreValue instances instead if Scalar. And 2. Since the tree builder needs to expose additional information for transient nodes (e.g. isNew, isModified). Michael BR, Jukka Zitting
Re: oak api : initial draft
On Mar 28, 2012 9:27 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Wed, Mar 28, 2012 at 8:52 PM, Michael Dürig mdue...@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. 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
