Hi, On 6/4/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
- The org.apache.jackrabbit.commons.repository.ProxyRepository class does not only access the repository lazily but "re-acquires" the repository on each call. This seems somewhat too expensive. I suggest to add an accessor method, which accesses the repository realy lazily.
I considered that but then we'd need explicit invalidation of the memorized repository reference. I want to be able to for example restart the repository accessed through JNDI or across servlet contexts without having to redeploy also all the applications that use the repository. Re-acquiring the reference for each method call achieves this in a clean and simple way. Most often the repository is also used just for a login() call, which in any case is more expensive than the typical repository lookup. The only time I think the lookup time will dominate access time is when a client reads the repository descriptors. This would typically be an administration operation so I don't think optimizing that is very important. Typically the repository lookup is also very fast for example when using local JNDI or a servlet context. The only case where the lookup would be more expensive is when accessing a remote repository, but such cases would typically not be performance-critical in any case and even there the typical performance hit would be a few extra milliseconds per login() call.
- I tend to not like the inclusion of Serlvet API specific methods in the commons and rmi libraries. IMHO using JCR in a Servlet Context is a very valid and probably most often used use case but it is not the sole and primary and most important use case. So adding dependencies to the Servlet API to these two libraries seems unfit. Rather I suggest to have a separate library supporting the important Servlet Context use case which combines the servlet support packages from the commons and rmi libraries.
We already have quite a few components to manage, so I'd prefer to avoid creating a yet another component. The servlet-api dependency scope is provided, so an application that doesn't use classes in the o.a.j.*.servlet packages would not be affected by the dependency. I could of course create such an extra component, but then it becomes a question of whether we should have separate components for the generic classes and ones specific to jackrabbit-jcr-rmi or jackrabbit-core or if we should just have a single jackrabbit-servlet component that depends on all these pieces. Following the former option (that doesn't impose extra dependencies to clients) would give us (at least): jackrabbit-jcr-servlet (depends on jackrabbit-jcr-commons) jackrabbit-jcr-rmi-servlet (depends on jackrabbit-jcr-rmi, jackrabbit-jcr-servlet) jackrabbit-core-servlet (depends on jackrabbit-core, jackrabbit-jcr-servlet) This simply duplicates the existing jcr-commons/jcr-rmi/core triple, so in my opinion we would be better of just accepting the (provided) servlet-api dependency in existing components. BR, Jukka Zitting
