Spring Integration 2.0 M5 has been released

[Mark Fisher]

2.0 M5 includes fully refactored HTTP outbound adapters that build upon RestTemplate and HttpMessageConverters, additional SpEL functionality including resolution of @bean within expressions, a persistent queue backed Message Channel option, global channel-adapters that are applied based on channel name patterns, an optional error-handling strategy for gateways to create a reply Message from an Exception, enhanced XPath support including a new xpath-header-enricher, new adapters for XMPP supporting both Messages and Presence notifications, continued evolution of the adapters for JDBC, additional configuration options for the Mail adapters such as providing a reference to a Session, and more. You can see the full JIRA changelog here: http://jira.springsource.org/secure/...fixfor=11 446

The artifacts are available in the S2 Milestone Maven repository (maven.springframework.org/milestone) and the full distribution, including docs and samples, is available at the SpringSource community download site:
http://www.springsource.com/download...%20Integration

We're closing in on the 2.0 Final release (one more milestone is planned), so this is a great opportunity to provide some feedback before it's too late!

Cheers,
Mark

[rock_star]

Hi Mark,
I am planning to migrate from 1.0.4 to 2.0 M6. Did not see the M6 notification though.
Hopefully, the migration should be straight forward.

And, seems like M7 is in development. Please let me know when is the 2.0 final release date( may be tentative one )

Thanks

[wims.tijd]

just migrated from 1.0.3 to 2.0.0.M7

and i've found out i had to use underscore in transformer

@Header("criteria_entity")

whereas router defined in context

header-value-router header-name="criteria-entity-type"

still continued to work

toolsuite 2.5.0.M3 did not pick up the new 2.0 xsd either,
is this why it not a release ?

outbound-gateway

:
previously i added in a transformer

.setHeader(HttpHeaders.REQUEST_METHOD, "GET")
        .setHeader(HttpHeaders.REQUEST_URL,outboundUrl)

this is not picked up by the HttpRequestExecutingMessageHandler

[Mark Fisher]

The HttpRequestExecutingMessageHandler no longer determines the HTTP Method or URL from headers. Those values should be configured on the adapter element. It does now support URI placeholders (e.g. "http://server/foo/{bar}"), and those can be provided via "uri-variable" sub-elements on the adapter. The value can be either a literal or a result of evaluating a SpEL expression.

As far as the underscore vs. hyphens in headers, that is not really enforced by Spring Integration, and it looks like the example you provided was using header names that you defined yourself. Are you sure there's not something else involved there?

The XSD should be picked up as long as it's on the classpath in STS. You may see some warnings in the editor, but you can actually choose a configuration option (under the 'Spring' menu) for resolving the latest version from the classpath.

HTH,
Mark

[wims.tijd]

Thx,

<int-http:outbound-gateway 
		request-channel="http-requests"
		extract-request-payload="true"
		charset="UTF-8"
		request-factory="rim-template-client-factory"
		url="${gateway.rim.url}?{request}"
		message-converters="http-template-message-converters"
		http-method="GET"
		expected-response-type="java.lang.String"
		reply-channel="http-replies">
		<int-http:uri-variable name="request" expression="payload['request']"/>
	</int-http:outbound-gateway>

works perfectly,

i understood the header name with hyphen was no longer valid as
an SpEL exception was thrown

Field or property 'criteria' cannot be found on object of type 'org.springframework.integration.MessageHeaders'

a custom header "criteria-entity" had been added and was chopped off after the hyphen
i was surpised though the

<int:header-value-router input-channel="http-replies" header-name="criteria-entity-type">

did not complain about this

selecting the 2.0 xsd in STS did the trick,

Thank you,

[Mark Fisher]

Okay, sorry. Now I understand what you are seeing with the hyphen and SpEL resolution of the header name. Can you please open an issue for that? We might not get it into 2.0, but I will make sure to set its target for 2.0.1 at least. In the meantime, we might be able to suggest a workaround.

The <header-value-router> is directly using that String in a Map lookup (i.e. headers.get("this-is-fine")), but I believe the SpEL evaluation is relying upon dot-notation as a Map value accessor and the hyphen is a different operator.

If you could provide a simple-as-possible failing unit test, that would be great!

Thanks,
Mark

[Mark Fisher]

Actually, I reproduced this problem with a test case, and I've created the following issue: https://jira.springsource.org/browse/INT-1534

I just committed a fix and resolved the issue, so please try with the trunk build, the next nightly snapshot, or RC1 (which should be available within 1-2 days).

Thanks for pointing out the issue!
Mark

[wims.tijd]

Thank you for the fix,

I just wanted to try out the jmx integration and encountered what is described below

<context:mbean-server id="jmx.server" />
	<int-jmx:mbean-exporter id="int.jmx.exporter" mbean-server="jmx.server"/>

combined with

<int:header-value-router />

produces :
Error creating bean with name 'org.springframework.integration.config.RouterFact oryBean

Found ambiguous parameter type [interface java.util.List] for method match: [public void org.springframework.integration.monitor.SimpleMess ageHandlerMonitor.handleMessage(org.springframewor k.integration.Message) throws org.springframework.integration.MessageRejectedExc eption,org.springframework.integration.MessageHand lingException,org.springframework.integration.Mess ageDeliveryException, public double org.springframework.integration.monitor.SimpleMess ageHandlerMonitor.getStandardDeviationDuration(), public void org.springframework.integration.monitor.SimpleMess ageHandlerMonitor.setSource(java.lang.String)]

version : 2.0.0.M7

[krzychu]

Good morning,

Any idea when 2.0.2 will be released? It is scheduled for 07/Feb/11 and todays is the 8th

Thanks.

Regards,
Krzysztof

[Mark Fisher]

We are hoping to get it out today, but it will definitely happen this week. As you may have noticed, we have resolved all issues as of the end of last week, but we had to address a few things related to the release process. I updated the date in JIRA.

Thanks,
Mark