Please find it attatched.
-Ruchi
Alexandru Popescu ? wrote:
On 5/17/07, ruchi goel <[EMAIL PROTECTED]> wrote:
Hi,
As per Jukka's proposal, it is a good idea to
Can you provide a pointer to this?
* have repository as ServletContextAttribute within
ServletContextListener
* jcr session can be stored in httpSession
If I am using jcr mapping layer (OCM) , I access jackrabbit via OCM's
PersistenceManager which is something like
new PersistenceManagerImpl(mapper, objectConverter, queryManager,
jcrSession);
Is it a good idea to have
* mapper, objectConverter, queryManager set in ServletContext
(after reading mapping files as context parameters) within
ServletContextListener.
* store persistenceManager in httpSession whenever jcrSession is
added/modified , within HttpSessionAttributeListener .
In the mapped java objects , persistencemanager can be retrieved from
httpSession.
Well, probably I should read firstly Jukka's proposal, but based on my
usual parallel with Hibernate Session/JPA EntityManager I don't think
this will really work mainly due to concurrent access, serialization
issues.
./alex
--
.w( the_mindstorm )p.
Thanks,
Ruchi
--- Begin Message ---
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
--- End Message ---
