jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ahmed Elshereay" <AElsher...@idc.com>
Subject Re: onEvent() invocation
Date Wed, 21 Apr 2010 11:04:57 GMT
Hi Alex,

Thank you very much. I have only one comment about your reply!
I doubt listeners are registered per-session! We use the session to get 
the a reference to the Workspace Object, then use that reference to obtain 
another to ObservationManager to register the listeners, those listeners 
are available even in case when logging out the session that was used to 
register them!
At the begining I thought the same, but I tested it some how, registered 
the listeners, then logged out from created a new session then called 
observationManager.getRegisteredEventListeners() and I found the listeners 
which I registered with the previous session although I didn't register 
them with the new one.

Regardless the problem which I posted I have another one that is more 
with onEvent() method, I obtain the path of the added node by 
event.getPath(), then I call jcrSessionFactory to getSession(), this 
breaks everything at this point, I get the following excpetion which 
doesn't tell anything!
Here's what I am trying to do:

1. Add a new node.
2. As I registered a NODE_ADDED listener, a new event is fired, and 
onEvent() I get the path to that node, do something with it, then create a 
new node.

WARN  [ObservationDispatcher] EventConsumer threw exception: 

Also, after your reply I tried something, I made the Session singleton, 
making the getSession() method synchronized and static, and made the 
session global static property in the JcrSessionFactory class.
This Fixed all the problems, invoking the onEvent() more than once and the 
EventConsumer one!

Although the problem is fixed, but making the session a state is not 
thread safe!

Then I made another change, 
removed the singleton pattern work, made session global but not static, 
and moved all the mothods from everywhere that needs a session to do 
something, to one place (in JcrSessionFactory) to make sure all operations 
will use the same session!
now I have the exception again: 
WARN  [ObservationDispatcher] EventConsumer threw exception: 
it breaks at that point, don't know why!!

Could you or anyone help to resolve this issue?

Thank you in advance.

Alexander Klimetschek <aklimets@day.com> 
04/19/2010 02:38 PM
Please respond to


Re: onEvent() invocation

On Mon, Apr 19, 2010 at 12:04, Ahmed Elshereay <AElshereay@idc.com> wrote:
> Then I installed jackrabbit-jca on jboss, and I don't know how to 
> spring to obtain the session(hope if you can help me in this it will be
> perfect because I'd like to use spring to look after all that stuff 
> I know it's not the point to talk about here),

Well, can't help you here. I personally don't like the
spring-jcr-module stuff, as it is no longer maintained (quite a few
people had various complaints that don't get fixed - just search this
mailing list for it) and the indirect, hidden way to acquire sessions
can be confusing. With the jcr api I would refrain from putting
another abstraction layer above it.

> so I created my own class
> that has getSession() and registerListeners() methods.
> I also created ObservationUtil.java class to registerListener() and 
> isRegisteredListener().
>            Session session = repository.login(credentials);
>            this.registerListeners(session);
>            return session;

registerListeners () and thus the isRegisteredListener() check is
always called with a new session. Event listeners are per-session and
are running until you log out of that session. Since you alway create
a new session when calling getSession(), you end up with many open
sessions, each with both of your event listeners registered.

Typically you have a session per request (in a webapp context) that
you log in upon start of the request, using the actual user if
possible (having users and acls in the repository), do your work and
logout that session at the end of the request.

Event listeners are typically using a "background" session, that is
long-running and independent of requests.

Hope that helps,

Alexander Klimetschek

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message