You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Kim Altintop <ki...@gmail.com> on 2007/02/07 11:54:56 UTC

EventListener gets empty jcr:data

Hi,

I'm trying to implement a simple "Drop Folder" setup where users would 
connect to one Jackrabbit workspace using (simple) WebDAV, drop files 
in there, and an EventListener listening for NODE_ADDED events 
(restricted to "nt:file") would then copy the file(s) to another 
workspace. As it turned out, the EventListener is able to locate the 
just-dropped file and read its properties but the jcr:data property is 
always empty (i.e. contains no data). If I change my listener to 
implement SynchronousEventListener it works fine. However, from the 
spec I would expect it to work just the other way round...

Am I getting something wrong here?

Regards,
Kim



Re: Session and server state

Posted by Michael Neale <mi...@gmail.com>.
I think session creation is not expensive, so #2 is perhaps simplest. I
guess the session can act as a cache, but perhaps a cache targeted more
specifically at an application would better serve performance then the
Session itself.

Thoughts?

On 2/8/07, Pruitt, Steve <SP...@exstream.com> wrote:
>
> I am interested in managing server state in regards to repository
> sessions.  Specifically, the scenario of a load balancer distributing
> user requests across multiple servers.  There are a number of questions
> that come to mind and I was wondering how others have approached the
> problem.
>
> In no particular order...
>
> 1) To avoid recreating a new session per user request, the repository
> session can be cached until the user "logs off".
>
> 2) Or, if session creation is not expensive then maybe the session is
> committed and then destroyed per user request?
>
> 3) If the session is persisted across user requests, how can the session
> be serialized to sync up the other servers.
>
> 4) Or, the session cannot be serialized and server affinity must be
> enforced.
>
> There may be other and obvious issues, but these are forefront for me.
> Any comments and ideas are appreciated.
>
>
> -S
>

Session and server state

Posted by "Pruitt, Steve" <SP...@exstream.com>.
I am interested in managing server state in regards to repository
sessions.  Specifically, the scenario of a load balancer distributing
user requests across multiple servers.  There are a number of questions
that come to mind and I was wondering how others have approached the
problem.

In no particular order...

1) To avoid recreating a new session per user request, the repository
session can be cached until the user "logs off".

2) Or, if session creation is not expensive then maybe the session is
committed and then destroyed per user request?

3) If the session is persisted across user requests, how can the session
be serialized to sync up the other servers.

4) Or, the session cannot be serialized and server affinity must be
enforced.

There may be other and obvious issues, but these are forefront for me.
Any comments and ideas are appreciated.


-S

Re: EventListener gets empty jcr:data

Posted by Marcel Reutegger <ma...@gmx.net>.
Hi Kim,

I'm not able to reproduce the behaviour you described. Though I didn't use 
WebDAV to import files, but just imported them using a JCR session.

Can you please provide a code fragment that shows how you access the content 
from within the event listener?

regards
  marcel

Kim Altintop wrote:
> Hi,
> 
> I'm trying to implement a simple "Drop Folder" setup where users would 
> connect to one Jackrabbit workspace using (simple) WebDAV, drop files in 
> there, and an EventListener listening for NODE_ADDED events (restricted 
> to "nt:file") would then copy the file(s) to another workspace. As it 
> turned out, the EventListener is able to locate the just-dropped file 
> and read its properties but the jcr:data property is always empty (i.e. 
> contains no data). If I change my listener to implement 
> SynchronousEventListener it works fine. However, from the spec I would 
> expect it to work just the other way round...
> 
> Am I getting something wrong here?
> 
> Regards,
> Kim
> 
>