040a44985d
refactored the UriPathHandlerMapping to only provide an implementation of the abstract method changed uriVariables to pathVariables added pathVariables and requestParams as variables to the EvaluationContext setting the HttpEntity as the rootObject of the EvauationContext (it includes the converted 'body' if present and 'headers') removed requirement for an ID, polished schema, added more tests, and tested with server finished the namespace support for payload-expression attribute and header sub-element, added parser test updated 2.1 schema with new 'payload-expression' attribute as well as 'header' elements polished UriPathHandlerMapping to address comments from the review added UriPathHandlerMapping to aid in support of the 'path' attribute fixed thread safety for EvaluationContext since it has to be created per request due to the fact that we are adding request data to it added support for SpEL expressions
Spring Integration
Checking out and Building
To check out the project and build from source, do the following:
git clone --recursive git://github.com/SpringSource/spring-integration.git
cd spring-integration
./gradlew build
Note: the
--recursiveswitch above is important, as spring-integration uses git submodules, which must themselves be cloned and initialized. If--recursiveis omitted, the checkout becomes a multi-step process.
If you encounter heap space errors during the build, increase the heap size for Gradle:
GRADLE_OPTS="-Xmx1024m"
Using Eclipse
To generate Eclipse metadata (.classpath and .project files), do the following:
./gradlew eclipse
Once complete, you may then import the projects into Eclipse as usual:
File -> Import -> Existing projects into workspace
Browse to the 'spring-integration' root directory. All projects should import free of errors.
Using IntelliJ IDEA
To generate IDEA metadata (.iml and .ipr files), do the following:
./gradlew idea
Generating JavaDoc
To build the JavaDoc, do the following from within the root directory:
./gradlew :docs:api
The result will be available in 'docs/build/api'.
OSGI Notes
- Dependency on Third Party Bundles Some adapters depend on third party libraries (bundles). Spring hosts the Enterprise Bundle Repository (EBR) at https://ebr.springsource.com/repository/app/, where you can download many third-party JARs as valid OSGi bundles. If a particular bundle is not available in Spring's EBR, there are tools that can convert a regular JAR to a bundle JAR. One of them is Bundlor http://www.springsource.org/bundlor which can auto-generate an OSGi MANIFEST.MF as part of standard project lifecycle or simply convert a non-bundle JAR to a bundle JAR.
- Boot delegation Some adapters depend on extension packages that are available to the boot class loader. As a case in point, the Feed Adapter depends on com.sun.syndication.feed. Since by default OSGi only loads java.* from the boot class loader, other packages that must be loaded from the boot class loader can therefore be specified with the 'org.osgi.framework.bootdelegation' System property. For example: org.osgi.framework.bootdelegation=com.sun.,org.w3c.. . . .
Resources
For more information, please visit the Spring Integration website at: http://www.springsource.org/spring-integration