Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: event aware object cache?
Date: Wed, 23 Nov 2005 15:13:00 +0100
Message-ID: <A955EA1F8FE31749AEC8C998082F6C7C41A896@hai01.hippo.local>
Thread-Topic: event aware object cache?
Thread-Index: AcXwLk53w7Fcafq3SBKTjljZE8oxqgABoDqg
From: "Max Pfingsthorn" <m.pfingsthorn@hippo.nl>
To: <dev@cocoon.apache.org>


Geoff Howard [mailto:geoff.howard@gmail.com] wrote:
> On 11/23/05, Max Pfingsthorn <m.pfingsthorn@hippo.nl> wrote:
> >
> > Geoff Howard [mailto:geoff.howard@gmail.com] wrote:
> > > On 11/21/05, Max Pfingsthorn <m.pfingsthorn@hippo.nl> wrote:
...
>=20
> I missed the deprecation of the Stores discussion. Do you have some
> pointers in the dev list archives?

Oh, no, nevermind. The Store interfaces moved into excalibur(?), but the =
stores in general aren't deprecated... My mistake.

>=20
> Would it be sufficient to configure JMSEventMessageListener with a
> list of EventAwares?  If the EAManager is necessary, I guess it would
> have to be configured with such a list unless you can think of a way
> for it to discover all EventAwares in the system?

Well, I was thinking of registering event awares with that manager so =
its more up to the components... Then again, if you have multiple jms =
providers, you might want to listen to a specific topic, or only forward =
events to a subset of EAs...
Its hard to do this kind of thing with lookup IoC.
Also, its a tradeoff between configuring the connections between source =
and sink of the events (e.g. the path between the jms listener and the =
cache) as roles to look up or as some sort of routing configuration.
We could do this by:
1. Letting event awares choose sources/topics to listen to
2. Configuring a name per event source

Then, a listener can say, I want to listen to topic "foo", no matter =
where from, or even listen to "bar" only from source "baz" and "bas".

WDYT?

...
> > Another usecase in favor of having a general=20
> EventAwareManager to keep track of EventAware instances would=20
> be to have a way to notify a business object model when the=20
> backend changes, or generally notify it via JMS. We'll be=20
> running into that soon over here, so it would be nice to get=20
> some ground work done.
>=20
> That is outside the original intention but should work.  There may be
> some odd block dependencies if someone wants to do that but not use an
> EventAwareCache, they could wind up requiring both the JMS block and
> the EventAware block anyway.  If you can see a way to allow your
> use-case but avoid that false dependency, that'd be great.

I don't really see that problem as you still have to configure which =
cache to use in your cocoon.xconf. Otherwise, if you want to use =
jms/eventaware, of course you need both blocks... I don't really =
understand the false dependency, can you explain?


max