On 5/26/10 8:09 AM, Jukka Zitting wrote:
> Hi,
> 
> Not sure how this became portrayed as a security problem. Not exposing
> implementation details through public API is a basic OO design
> principle.
> 
> BR,
> 
> Jukka Zitting
AFAICT, implementation details aren't exposed through the public API
either now or with the proposed patches in JCR-890. Implementation
details are exposed through other implementation classes which doesn't
seem that odd to me.

In one of Thomas's comments on JCR-2640 he pointed to what I think is
the real issue here:
> Users should use the API and not cast to implementation classes. I
> guess we were and still are not very clear about that.

o.a.j.core isn't the public API. o.a.j.api is. As a consumer of
Jackrabbit, I should NEVER be using classes in o.a.j.core.* regardless
of their visibility.

If someone thinks they need to, they're going to cast API objects
(either JCR or Jackrabbit API) to implementation objects. And regardless
of what levels of indirection you put between implementation classes,
people are going to dig through them. The only difference will be that
the wack code they post to the mailing list when it doesn't work will be
longer and more complex :)

My suggestion would be to look at the  reasons why people think they
need to cast from the API to implementation classes and either make it
very obvious on the site/docs why casting isn't necessary or, if it
actually is necessary, create new API methods which obviate the need to
cast.

My guess is that with Jackrabbit 2 and higher, most casting to
Jackrabbit implementation classes isn't necessary and when people think
they need to cast it is due to bad information. There is a need to cast
from the JCR API to Jackrabbit API (i.e. Session to JackrabbitSession),
but this is due to gaps in the JCR spec which I don't think are getting
filled anytime soon (e.g. user management).

Justin

Reply via email to