jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edgar Poce" <edgarp...@gmail.com>
Subject Re: web based jcr browser contribution
Date Tue, 21 Nov 2006 19:44:19 GMT
On 11/21/06, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Should we target at eventually merging the two webapps, or is it
> better to keep them separate?
>

IMHO it's better to keep them separated, when the navigator is mature
enough to join to the jackrabbit release cycle we could review it.

> > Btw, sharing the jcr session between the webdav servlets and the
> > navigator is in my todo list.
>

I gave it a second thought and even when the webdav server is deployed
in the same webapp I think that sharing the jcr session between the
navigator and the webdav server is not a good option. The jcr
navigator make use of the same transient space among several requests
and sharing the session with jackrabbit-server would cause the user to
lose control on when to perform a save operation.

> It would probably be good to come up with some best practice on how
> access a JCR session from a servlet or a JSP page.
>
> Note that unless we use a SynchronizedSession decorator,  it's better
> if the JCR session is placed in request scope than in the session
> scope to avoid problems with concurrent requests.

I think the jcr-navigator app should not bind the jcr session to the
request scope, a SynchronizedSession seems a better option for this
scenario.

Currently, the user logs in via Container managed security, a
ServletFilter logs in the given user in jackrabbit with an empty
password and stores the jcr session in the http session. when the http
session is invalidated a SessionListener is responsible of logging out
the jcr session

> We should perhaps
> use a ServletRequestListener (or a Filter if servlet 2.3 support is
> needed) that uses some SessionProvider interface to acquire and
> release the JCR session using login credentials stored in the servlet
> session scope. This would make it easy to implement session pooling or
> request synchronization depending on the needs of the application.
>
> Note also that we can't use the standard Repository interface as a
> facade to a session pool without decorating almost the entire JCR API
> since there is no easy way to catch Session.logout() calls.
>

IMHO a connection pool is not required for the navigator, we could add
comments about session reuse in a best practices section in the wiki
or the site. Personally, I used the jca contrib project when I had a
use case where binding the jcr session to the http request was a good
option. With jca the client code is unaware of the connection reuse.

> > I'll take a look to integrating the ntdoc contrib project.
>
> Thanks. It'll probably need some adjustment since the ntdoc code was
> originally targeted at statically producing output from CND files. In
> the webapp context it would probably make more sense to produce
> similar output directly from the NodeType instances.
>
> BR,
>
> Jukka Zitting
>

Mime
View raw message