You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Paco Avila <pa...@git.es> on 2007/09/06 08:59:30 UTC
Using observation
I'm adding a new feature in OpenKM (our DMS): document and folder
subscription, so OpenKM can notify of document changes. I've been
reading about Jackrabbit Observation and I know how to observe a node,
but I have some questions:
* Due to observation life cicle, it should be managed across a system
session which is alive all the time OpenKM is running, isn't it?
* I can get a list of registered even listeners, but how can I see which
nodes are observed?
* If there are several users who want to subscribe to a document node,
where should I store this list of users? In the observed node I can't
because the user perhaps don't have wirte access.
--
Paco Avila <pa...@git.es>
Re: Using observation
Posted by Marcel Reutegger <ma...@gmx.net>.
Paco Avila wrote:
> Thanks for the info. I have an user profile where I can store this data.
> If a observed node is moved to another location, I have to update the
> event listener. This seems a bit complex...
if your nodes are referenceable you can base the subscriptions on the uuid.
regards
marcel
Re: Using observation
Posted by Paco Avila <pa...@git.es>.
El jue, 06-09-2007 a las 09:56 +0200, Marcel Reutegger escribió:
> Paco Avila wrote:
> > I'm adding a new feature in OpenKM (our DMS): document and folder
> > subscription, so OpenKM can notify of document changes. I've been
> > reading about Jackrabbit Observation and I know how to observe a node,
> > but I have some questions:
> >
> > * Due to observation life cicle, it should be managed across a system
> > session which is alive all the time OpenKM is running, isn't it?
>
> Yes, for your use case that's probably the best option.
>
> > * I can get a list of registered even listeners, but how can I see which
> > nodes are observed?
>
> that's not possible, your application has to remember that. And keep in mind
> that you only get the event listeners that were registered with *your* session.
>
> > * If there are several users who want to subscribe to a document node,
> > where should I store this list of users? In the observed node I can't
> > because the user perhaps don't have wirte access.
>
> I'd keep it on the user profile (don't know if you have such a construct). On
> application start do a query for all subscriptions and keep them in memory. Add
> a listener for subscription changes, which keeps you informed about subscription
> changes. then add another listener for regular content changes which triggers
> notifications based on the subscriptions you have.
Thanks for the info. I have an user profile where I can store this data.
If a observed node is moved to another location, I have to update the
event listener. This seems a bit complex...
--
Paco Avila <pa...@git.es>
Re: Using observation
Posted by Marcel Reutegger <ma...@gmx.net>.
Paco Avila wrote:
> I'm adding a new feature in OpenKM (our DMS): document and folder
> subscription, so OpenKM can notify of document changes. I've been
> reading about Jackrabbit Observation and I know how to observe a node,
> but I have some questions:
>
> * Due to observation life cicle, it should be managed across a system
> session which is alive all the time OpenKM is running, isn't it?
Yes, for your use case that's probably the best option.
> * I can get a list of registered even listeners, but how can I see which
> nodes are observed?
that's not possible, your application has to remember that. And keep in mind
that you only get the event listeners that were registered with *your* session.
> * If there are several users who want to subscribe to a document node,
> where should I store this list of users? In the observed node I can't
> because the user perhaps don't have wirte access.
I'd keep it on the user profile (don't know if you have such a construct). On
application start do a query for all subscriptions and keep them in memory. Add
a listener for subscription changes, which keeps you informed about subscription
changes. then add another listener for regular content changes which triggers
notifications based on the subscriptions you have.
regards
marcel