Timer Source Endpoint

[Mark Fisher]

David,

So, I guess you are looking for something like this instead?:

<inbound-channel-adapter payload="somePrototypeBean" channel="x">
    <poller ... />
</inbound-channel-adapter>

Can you go ahead and add an issue via JIRA and then link to this thread?

In reality, I would most likely not use that approach above directly ("poller" does not make much sense in this context). It is more like a scheduled publisher. The new scheduling namespace in Spring 3 (I will be starting work on that today hopefully) will simplify this, but I could still see something more like this in Spring Integration:

<publisher payload="somePrototypeBean" channel="x">
    <interval-trigger ... />
</publisher>

Regards,
Mark

P.S. Iwein is just as lazy .... a great virtue IMO

[iwein]

P.S. Iwein is just as lazy .... a great virtue IMO

I'm too lazy for a witty response even

I like the publisher suggestion. Being an actual pattern from the book it makes more sense to do this than to reuse an non fitting name (channel adapter) or something out of thin air (heartbeat). In fact we had something like it in an early milestone iirc, right Mark?

[Mark Fisher]

We had a @Publisher annotation (in a 1.0 milestone) for using AOP interception on existing methods. So it was similar, but still a bit different. The reason we deferred that is that the determination of payload from the MethodInvocation seemed like a great case for using EL. With Spring 3.0 as the base for Spring Integration 2.0, we will be re-adding that feature and likely enabling EL for that role. We should therefore consider these two features together:

1) AOP-interceptor-driven publisher
2) trigger-driven publisher

[david_geary]

Thanks for the feedback on this - I've raised INT-650 for it. Both the publisher and new spring 3 scheduling namespace sound like good approaches that should provide what I'm looking for.