hi michael
that's not sufficient IMO. if the content tree presents the
"Node" than it might simply be that you don't have access to it
due to access constraints that are are being enforced in oak-core.
Well the peculiarities of this is what I wanted to find out about in the
questions in my original mail... Anyway, I find it odd that one should
be able to access say /x/y but not /x. That is, there is no difference
from having an x which you can't to nothing with but use it to retrieve
its child y and being able to retrieve /x/y directly.
even if you find it odd, there are real use case for that (in
contrast to the repo-view ;). maybe you can set 2 hours aside and
take a look at the software your employer is selling? ;-)
That's not my point. My point was, that we can get the same behaviour on
the JCR API as we currently have through the ContentTree methods as I
sketched them earlier. Maybe you could set 2 hours aside too and think
about this ;-)
*LOL* will do that...
as i said in a previous post i wouldn't mind if it works out with
some sort of segment-only-entry in the content tree where it was
possible to find out that no is granted here without performing an
extra check in oak... that's all. in any case we will have the
prove at the point we have the complete access control stuff
implemented.
kind regards
angela
Michael
honestly, this was the first thing we had to fix both in jackrabbit-core
and in jcr2spi... in the latter case it even
was another company that pushed to me to make that change.
kind regards
angela
