Reference Manual feedback please!

[Mark Fisher]

That will be revised for 2.0.5. We have it as an issue in JIRA: https://jira.springsource.org/browse/INT-1938

Thanks,
Mark

[Wrangler]

I created Jira https://jira.springsource.org/browse/INT-1950 for a reference manual incorrect link.

[xiaoyu1985ban]

I hope there will be more infomation about monitoring and controlling the message flow,example : start, stop , resume, etc.

[dnlegge]

Specifically in the 1 to 2 Migration guide there's no reference to AbstractSingleChannelRouter being removed so that you need to extend a normal AbstractMessageRouter instead.

Because it didn't mention it nor work out of the box it was fairly mystifying.

[oleg.zhurakousky]

So you were using AbstractSingleChannelRouter? that is interesting. I'll update the Migration Guide, but would you mind sharing your use case for using it in the first place?

[dnlegge]

So you were using AbstractSingleChannelRouter? that is interesting. I'll update the Migration Guide, but would you mind sharing your use case for using it in the first place?

Oleg, it was used in a codebase I inherited a few months ago. Looking at it the use case was as effectively a binary router:

Having checked some 'state' in the Message it either:
- returns null, and is sent to the "default-output-channel"
- or is routed to the channel specified in the xml (passed in to the constructor)

It only took a little work to convert to AbstractMessageRouter once I knew that's what I needed to do.

More time was spent working out what happened to AbstractSingleChannelRouter and that AbstractMessageRouter was the thing to use in Spring 2 as I could find no reference to it (or the decision)

[Mark Fisher]

It doesn't sound like that use-case should require a custom implementation. It could most likely be handled as a simple POJO invocation from a normal 'router' element (or in 2.0, using a SpEL expression instead of the POJO). Also, it might be worth considering a 'filter' element, where the expression or POJO-method-return-value can be a simple boolean. When TRUE the Message goes to the output-channel, and when FALSE it goes to a discard-channel if one has been provided (in such a case, it too can serve as a "binary router").

Hope that helps.
-Mark

[dnlegge]

Mark,

Thanks very much for the suggestions.

I'm happy that it's existence probably wasn't justified, it was just I couldn't migrate by 'just turning the handle' (which might actually be a good thing I suppose!)

But its the old 'legacy code' problem where the original decision is lost to the mists of time and upgrading SI was part of getting the codebase under control.

A reference to AbstractSingleChannelRouter in the migration guide would (have) suffice(d), perhaps with why it was removed (too niche an application?).

Perhaps any further discussion should take place in a new thread.

Regards
David

[Mark Fisher]

I understand and agree that it should be mentioned in the migration guide. I just wanted to make sure you knew why it's typically not necessary to extend those framework classes in the first place. Thanks again though for bringing up the topic - we will definitely add it to the doc.

[maryquiryp]

any tips as well on how to use ApplicationEvent?

if springapp services could be managed via JMX?

regards
marco

A pdf version would be good.

An overview of how spring integration compares with other intergration frameworks (or esbs) such as mule or servicemix would be useful.

Detailed documentation on the tags would be useful. If there are annotation versions of the tags, it would be best if the xml tags were documented by reference to the annotation classes as well as comments in an xsd.
_____________________
website promotion