On 1 March 2013 18:19, Jukka Zitting wrote:
> Hi,
>
> On Thu, Feb 28, 2013 at 11:55 PM, Ian Boston wrote:
>> Are there plans to expose kernel stats from Oak ?
>
> Yes, see OAK-364 [1]. Though so far we haven't yet implemented
> anything along these lines.
Nice thanks.
I am more interested in cou
Hi,
On Thu, Feb 28, 2013 at 11:55 PM, Ian Boston wrote:
> Are there plans to expose kernel stats from Oak ?
Yes, see OAK-364 [1]. Though so far we haven't yet implemented
anything along these lines.
One related idea I was already thinking about implementing is exposing
cache statistics [2] from
Hi,
Are there plans to expose kernel stats from Oak ?
>From a client point of view:
I am thinking access to an immutable map of read only long values that
give the client information about the internal health and throughput
of an Oak kernel, rather like the information available under /proc on
lin
This is a test that is failing getting the session twice,
testAdminSessionTwice() fails, the first testAdminSession() works. The
problem can be solved by not logging out of the session (recycling the jcr
session on all tests), but I am not sure this is how the Session must be
handled.
8<-
On 27.2.13 12:15, Jukka Zitting wrote:
Hi,
On Wed, Feb 6, 2013 at 6:55 PM, Michael Dürig wrote:
Since we now have branches in the Microkernel I suggest, we remove this
feature entirely. That is, remove the KernelNodeBuilder and
KernelRootBuilder classes. Unless we want to further pursue gett
On 27.2.13 13:14, Jukka Zitting wrote:
Hi,
On Wed, Feb 27, 2013 at 3:00 PM, Michael Dürig wrote:
I am though. Such in flight refreshes render internal invariants to break.
Fair enough.
The other alternative, as discussed, would be to utilize better
control over the Impl/Delegate barrier.
Hi,
Below are some notes of recent development in Oak. Please feel free to
comment, correct and complete as necessary.
* The segment based MicroKernel prototyping effort is coming along nicely:
° Two backends, memory and MongoDB
° Mostly functionally equivalent with other MKs, some isolated e
Hi,
On Tue, Feb 26, 2013 at 1:11 PM, Angela Schreiber wrote:
> usually the specification explicitly states if a given validation
> may be postponed until the save-call which is not the case here.
I think we should probably suggest to JSR 333 to relax that
constraint, but until we do I guess you'