jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger" <Felix.Meschber...@day.com>
Subject Re: Proposal for managing JCR resources in webapps
Date Wed, 16 May 2007 08:07:03 GMT
Hi Jukka,

Thank you very much for this proposal. I like it because it is simple and
straight forward.

+1 for this

Just one note: Have you considered the issue of accessing the repository
accross web apps ?

Regards
Felix

On 5/15/07, Jukka Zitting <jukka.zitting@gmail.com> wrote:
>
> Hi,
>
> I must confess that I don't really like the RepositoryStartupServlet
> and RepositoryAccessServlet mechanisms we currently have in
> jackrabbit-webapp. The classes are complex and correctly configuring
> them is non-trivial. To simplify things I propose an alternative
> approach to managing JCR resources (Repositories, Sessions, Items,
> etc.) in webapps, including the jackrabbit-webapp.
>
> The proposal is based on using the standard servlet scope and
> attribute model for managing JCR resources. The JCR repository used by
> a webapp would be placed in the servlet context as the
> "javax.jcr.Repository" attribute. If a webapp uses multiple
> repositories, they can be managed as "javax.jcr.Repository.<name>"
> attributes. A JCR session would typically be managed as the
> "javax.jcr.Session" attribute of a servlet session or a request.
>
> The canonical code to access the repository would be something like this:
>
>     String name = getInitParameter(Repository.class.getName());
>     if (name == null) {
>         name = Repository.class.getName();
>     }
>     Repository repository = getServletContext().getAttribute(name);
>
> Using the standard attribute model allows nice separation of concerns
> and plays very well with various tools available in the servlet
> environment. For example I could implement the Repository startup or
> lookup code as a ServletContextListener that manages the repository
> lifecycle. Separate ServletContextAttributeListeners could be used to
> optionally expose the repository instance through RMI or JNDI. I could
> also easily mix and match things, for example to configure a
> ServetContextAttributeListener that automatically provides a decorated
> version of the repository as a separate attribute, which could again
> be further processed by other attribute listeners or servlets.
>
> The same options also apply to JCR sessions on a servlet session or
> request level. A typical approach could be to use a session or request
> listener or a filter to associate a JCR session with the processing of
> a request. The servlet or JSP page that ends up processing the request
> can simply look up the respective attribute to get the JCR session.
>
> What this would mean for jackrabbit-webapp? First I would move the RMI
> and JNDI binding code from RepositoryStartupServlet into separate
> ServletContextAttributeListeners. Then I would replace the
> RepositoryStartupServlet dependencies in the other serlets like
> SimpleWebdavServlet with the standard servlet context attributes.
> Finally I'd split the configuration part of the
> RepositoryStartupServlet into a separate class and perhaps turn the
> remaining RepositoryStartupServlet code into a
> ServletContext(Attribute)Listener class.
>
> BR,
>
> Jukka Zitting
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message