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
