Ok, thanks all makes sense.
On a related note, upgrading AccessManager to 15
Question:
Is there a better way to make Jackrabbit IoC friendly than extending
RespositoryImpl and replacing class.newInstance() methods with
injector.getInstance() (Guice10) ?
Background:
I notice that 1.5 has change the structure of the access manager and
the way in which sessions startup.
The application I am working on uses Guice to perform Constructor IoC.
This causes problems with Jackrabbit as it does class.newInstance()
which bypasses all chance of constructor IoC.
In 14 I was able to extend RepositoryImpl and override the various
create* methods.
eg createSessionInstance().
unfortunately in 15 the structure under XASessionImpl has changed and
it looks like its no longer possible to override createAccessManager
as it depends on rep.getFileSystem() and rep.getSecurityManager() both
of which are package private.
Also if I try and override getSecurityManager() from the
RepositoryImpl I find that its WokspaceInfo is similarly package
protected.
In 15 the RepositoryInfo.WorkspaceInfo class is preventing me from
getting an Instance of an IoC'd JackrabbitSecurityManager
I could just put it in a o.a.j.core but that will eventually play
havoc with Java7 and or OSGi.
Ian
On 5 Mar 2009, at 11:21, Stefan Guggisberg wrote:
hi ian
On Thu, Mar 5, 2009 at 2:26 AM, Ian Boston <[email protected]> wrote:
I have an AccessManager implementation that uses its own session to
get
properties (ACL) on nodes and the parents of nodes that it is
controlling.
I get lots of
WARN: overwriting cached item b38c5119-2aa2-4e08-b4bf-41dd1720c197
(2009-03-03 17:10:59,740
TP-Processor3_org.apache.jackrabbit.core.ItemManager)
I think this is because the ItemManager is checking with the
AccessManager,
which is adding the item to the cache in ItemManager, and when the
current
thread returns to ItemManager to put the item in...... its already
been
pulled in by AccessManager.. hence the warn.
that's correct.
I am using 1.4.8, I couldn't find anything in jira to help.
So, my questions:
If I want to store ACL's on the nodes, can I use the same session
as is
accessing the node, or do I have to create a second session just for
accessing the ACL's ?
i would recommend using a dedicated session for accessing the ACL's.
Will creating a second session per AccessManager have a performance
impact ?
a session is not light-weight and does have a considerable memory
footprint.
assuming you've got enough jvm heap it shouldn't cause performance
issues.
you might try to use a shared ACL reading session for multiple
AccessManagers
in order to reduce memory consumption. we've tried to make read-only
sessions
thread-safe, however this has only been a best effort. you might still
run into the
occasional concurrency issue under heavy load. our 'official' stamenet
is: a Session
is not thread-safe.
cheers
stefan
Ian
