[
https://issues.apache.org/jira/browse/JCR-890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-890:
------------------------------
Attachment: session-class-move-norename.patch
As a first step to implementing this, I'd like to make the following moves of
session-related classes form o.a.j.core to a new o.a.j.core.session package. As
discussed on dev@, the rationale for this change is to be able to better manage
the code paths to and from the internal state of each session.
cd jackrabbit-trunk/src/main/java/org/apache/jackrabbit/core
svn mkdir session
svn move AbstractNodeData.java session
svn move BatchedItemOperations.java session
svn move ItemData.java session
svn move ItemImpl.java session
svn move ItemLifeCycleListener.java session
svn move ItemManager.java session
svn move ItemValidator.java session
svn move LazyItemIterator.java session
svn move NodeData.java session
svn move NodeDataRef.java session
svn move NodeImpl.java session
svn move PropertyData.java session
svn move PropertyImpl.java session
svn move ProtectedItemModifier.java session
svn move SessionImpl.java session
svn move SessionListener.java session
svn move SystemSession.java session
svn move VersionManagerImpl.java session
svn move WorkspaceImpl.java session
svn move XASessionImpl.java session
svn move XAWorkspace.java session
The attached patch (session-class-move.patch) contains all the import statement
changes and other minor refactorings required to make the trunk compile and
pass all tests after the above moves.
Note that the patch includes dummy child classes in org.apache.jackrabbit.core
for the JCR implementation classes ItemImpl, NodeImpl, PropertyImpl,
SessionImpl, VersionManagerImpl and WorkspaceImpl. These classes simply inherit
the similarly named classes that were moved to o.a.j.core.session. The purpose
of these classes is to maintain compatibility with client code that casts JCR
objects to Jackrabbit implementation classes. Later on it may be a good idea to
turn these classes into facades that access the underlying functionality in
o.a.j.core.session after taking care of trivial operations like name/path
parsing, etc.
This step is a purely structural refactoring, it does not introduce any
functional changes in the code. All code outside o.a.j.core and
o.a.j.core.session can be updated to reflect these changes simply by updating
the relevant import statements. To make reviewing the patch easier, I've
attached also a version without all the trivial package renames
(session-class-move-rename.patch). Note that the new package boundary required
changes to the visibility of a number of methods and classes. My plan is to
refactor these cases so that we don't expose more of the Jackrabbit internals
to client code.
> concurrent read-only access to a session
> ----------------------------------------
>
> Key: JCR-890
> URL: https://issues.apache.org/jira/browse/JCR-890
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-core
> Reporter: David Nuescheler
> Assignee: Jukka Zitting
> Fix For: 2.2.0
>
> Attachments: session-class-move-norename.patch
>
>
> Even though the JCR specification does not make a statement about Sessions
> shared across a number of threads I think it would be great for many
> applications if we could state that sharing a read-only session is supported
> by Jackrabbit.
> On many occasions in the mailing lists we stated that there should not be an
> issue with sharing a read-only session, however I think it has never been
> thoroughly tested or even specified as a "design goal".
> If we can come to an agreement that this is desirable I think it would be
> great to start including testcases to validate that behaviour and update the
> documentation respectively.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
