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
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'
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'
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
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
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
Hi,
I just discovered this little book Functional Programming for Java
Developers from O'Reilly [1]. This book seems to nicely introduce some
of the topics I mentioned in my presentation at the February F2F [2
slides 14 and 15]. Being aware of these topics will help us coping with
[
https://issues.apache.org/jira/browse/OAK-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting resolved OAK-42.
--
Resolution: Fixed
Done in revision 1306847.
Prepare for first release
Hi all,
Just checked out oak and I notice there are o.a.j.mk packages in both the
oak-core and the oak-mk projects. I think this is fundamentally wrong and may
even lead to split packages.
In addition it really leads to confusion as expressed in an early statement by
Tom: If I have a class,
Hi,
On Thu, Mar 29, 2012 at 5:22 PM, Felix Meschberger fmesc...@adobe.com wrote:
So I suggest we either move the mk packages to the mk project or
rename the mk packages in core to oak instead.
Yes, that's the idea [1].
[1]
Hi
Ok, thanks and sorry for the noise, then.
Regards
Felix
Am 29.03.2012 um 11:26 schrieb Jukka Zitting:
Hi,
On Thu, Mar 29, 2012 at 5:22 PM, Felix Meschberger fmesc...@adobe.com wrote:
So I suggest we either move the mk packages to the mk project or
rename the mk packages in core to oak
[
https://issues.apache.org/jira/browse/OAK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241333#comment-13241333
]
Jukka Zitting commented on OAK-6:
-
I added a basic JCR TCK setup to oak-it/jcr in revision
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
Incomplete journal when move and copy operations are involved
-
Key: OAK-43
URL: https://issues.apache.org/jira/browse/OAK-43
Project: Jackrabbit Oak
Issue Type: Bug
Hi,
Thinking about how to implement the jcr operations on top of the oak api
I noted some impedance mismatch: while there are move and copy
operations on both the Microkernel API and on JCR, the oak-api does not
provide these operations directly. Instead they have to be expressed in
terms
15 matches
Mail list logo
