You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Lukas Lang <lu...@inode.at> on 2008/07/17 17:30:44 UTC
Eventcache dependency to JMS
Hello,
I'm wondering, why the eventcache block has dependencies on
the JMS block and not the other way round?
For those who are familiar with these blocks,
in my opinion the JMSEventListener makes use of eventcache capabilities.
So I would say, JMS provides callback support via eventcache.
What do you think?
Regards,
Lukas
RE: Eventcache dependency to JMS
Posted by Ard Schrijvers <a....@onehippo.com>.
Hello,
>
> Hey,
>
> I'm sorry for my delayed answer too ;-)
>
> Well, what I'm trying to gain is implementation independent blocks.
> I cleaned up the JMS block using Spring provided mechanisms
> (templates) for message delivery.
>
> The sample block is now based on the ActiveMQ implementation
> running in embedded mode (initialized via Spring namespace).
> For demonstration purpose, it uses the
> JMSEventMessageListener component for invalidating cached responses.
>
> As far as I get this, there are no dependencies between
> eventcache and jms-impl at all?
> If we consider (re)placing the JMSEventMessageListener into
> the jms-sample block, because it is a concrete subclass of
> the AbstractMessageListener, we would get a more satisfying situation.
Doesn't the JMSEventMessageListener have a dependency on eventcache, or
none at all (it's been a while so I might be off here...)
>
> The way you might go, consists of writing a concrete listener
> in a separate block, using whatever other block (e.g.
> eventcache) you might need.
I must also admit I haven't yet been working with 2.2 and only 2.1. Do I
get correctly, that we would have in the end a jms block and a separate
event block, and if you want the event block using the jms, you need to
add a separate block containing the concrete listener impl? Or is it not
necessary to add a block...?
>
> Can you live with that?
Honestly, you can better judge it then I can, because I am still to much
thinking and looking at it from the 2.1 days... :-). So if it makes the
architecture of the blocks better, you ahead
-Ard
>
> Regards,
> Lukas
>
> Ard Schrijvers schrieb:
> > Hello Lukas,
> >
> > Sry for my late respond
> >
> >> Hello,
> >>
> >> I'm wondering, why the eventcache block has dependencies
> on the JMS
> >> block and not the other way round?
> >
> > I do not know what you would win by switching the
> dependency around.
> > JMS seems to me more uncoupled from eventcache then
> eventcache to jms.
> > Perhaps I would like to use JMS listeners, while at the
> same time I do
> > not have any eventcache at all. I would for example just use JMS
> > to...I don't know, trigger an email to send...
>
>
>
> >
> >> For those who are familiar with these blocks, in my opinion the
> >> JMSEventListener makes use of eventcache capabilities.
> >>
> >> So I would say, JMS provides callback support via eventcache.
> >>
> >> What do you think?
> >
> > It's been a while for since I last worked with it, and I
> suppose it is
> > targeted for Cocoon 2.2 where my knowledge is mainly 2.1.x,
> so I might
> > be missing something. Anyway, it is not directly clear for
> me what to
> > gain with this dependency switch
> >
> > -Ard
> >
> >> Regards,
> >> Lukas
> >>
> >>
> >
> >
>
>
>
Re: Eventcache dependency to JMS
Posted by Lukas Lang <lu...@inode.at>.
Hey,
I'm sorry for my delayed answer too ;-)
Well, what I'm trying to gain is implementation independent blocks.
I cleaned up the JMS block using Spring provided mechanisms (templates) for message delivery.
The sample block is now based on the ActiveMQ implementation running in embedded
mode (initialized via Spring namespace). For demonstration purpose,
it uses the JMSEventMessageListener component for invalidating cached responses.
As far as I get this, there are no dependencies between eventcache and jms-impl at all?
If we consider (re)placing the JMSEventMessageListener into the jms-sample block,
because it is a concrete subclass of the AbstractMessageListener,
we would get a more satisfying situation.
The way you might go, consists of writing a concrete listener in a separate block,
using whatever other block (e.g. eventcache) you might need.
Can you live with that?
Regards,
Lukas
Ard Schrijvers schrieb:
> Hello Lukas,
>
> Sry for my late respond
>
>> Hello,
>>
>> I'm wondering, why the eventcache block has dependencies on
>> the JMS block and not the other way round?
>
> I do not know what you would win by switching the dependency around. JMS
> seems to me more uncoupled from eventcache then eventcache to jms.
> Perhaps I would like to use JMS listeners, while at the same time I do
> not have any eventcache at all. I would for example just use JMS to...I
> don't know, trigger an email to send...
>
>> For those who are familiar with these blocks, in my opinion
>> the JMSEventListener makes use of eventcache capabilities.
>>
>> So I would say, JMS provides callback support via eventcache.
>>
>> What do you think?
>
> It's been a while for since I last worked with it, and I suppose it is
> targeted for Cocoon 2.2 where my knowledge is mainly 2.1.x, so I might
> be missing something. Anyway, it is not directly clear for me what to
> gain with this dependency switch
>
> -Ard
>
>> Regards,
>> Lukas
>>
>>
>
>
RE: Eventcache dependency to JMS
Posted by Ard Schrijvers <a....@onehippo.com>.
Hello Lukas,
Sry for my late respond
>
> Hello,
>
> I'm wondering, why the eventcache block has dependencies on
> the JMS block and not the other way round?
I do not know what you would win by switching the dependency around. JMS
seems to me more uncoupled from eventcache then eventcache to jms.
Perhaps I would like to use JMS listeners, while at the same time I do
not have any eventcache at all. I would for example just use JMS to...I
don't know, trigger an email to send...
>
> For those who are familiar with these blocks, in my opinion
> the JMSEventListener makes use of eventcache capabilities.
>
> So I would say, JMS provides callback support via eventcache.
>
> What do you think?
It's been a while for since I last worked with it, and I suppose it is
targeted for Cocoon 2.2 where my knowledge is mainly 2.1.x, so I might
be missing something. Anyway, it is not directly clear for me what to
gain with this dependency switch
-Ard
>
> Regards,
> Lukas
>
>