On 11/21/06, Jukka Zitting <[EMAIL PROTECTED]> 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
