...
- Fixed Bean component to avoid ambiguous error for classes that extends generic interface and calling which could lead to falsely duplicate methods (due Java type erasure inserts bridge methods)
- Fixed splitting using tarfile could cause OOME if splitting big files which was mistakenly loaded into memory. Now we work on the tar stream directly.
- Fixed Netty HTTP and Netty4 HTTP issue when not specifying a port number then port 80 would not be used but an error about port -1 is not allowed.
- Fixed Swagger Java when using property placeholders in Rest DSL could cause invalid parameters to be included that was from the placeholder.
- The
threadsEIP now lets Error handling in Camel perform redeliveries if the thread pool would otherwise reject accepting the task. This allows the error handler to perform redeliveries to attempt to put the task on the thread pool queue, or eventually move the message to a dead letter queue etc. - Fixed Rest DSL adding empty header if specifying a non required query parameter that has no default value assigned.
- Fixed doWhile loop which could potentially loop forever.
- Fixed a NPE in Zookeeper consumer if no zookeeper node path was set
- Spring-DM for OSGi moved out of camel-spring into a separate camel-spring-dm module.
- When using continued with onException then dead letter channel endpooint should not be invoked.
- Fixed Error Handler to not log exceptions when using
continued(true)by default. - Fixed so using shareUnitOfWork would now also call specialized
AggregationStrategyfor onTimeout, onCompletion etc. - Fixed Jetty consumer incorrectly handle multipart/form data not being mapped as attachments on the Camel Message.
- Fixed Netty4 HTTP may fail reading the http content from the raw netty stream if the Exchange was routed asynchronously.
- Fixed Netty4 HTTP leak ByteBuf's on the producer side which was not released in all corner cases before they may be gargage collected.
- Fixed Dozer not able to use variables in mapping files when using OSGi.
- Fixed a potential dead-lock when doing request/reply over JMS and requests are timing out concurrently and continued routing the exchanges are calling another JMS endpoint that is also doing request/reply which also timeout.
New Enterprise Integration Patterns
...