PK
HAoa, mimetypeapplication/epub+zipPK
HA META-INF/PK
HA OEBPS/PK
HA
OEBPS/images/PK
HA OEBPS/imagesdb/PK
HAh h META-INF/container.xml
Table of Contents
All JBI-related modules have been removed from Apache CXF. From now on, the recommended approach is to use the Apache CXF JBI component in Fuse ESB Enterprise—for details, see Using the Apache CXF Binding Component.
The selectAlternative method from the
org.apache.cxf.ws.policy.AlternativeSelector interface now takes an
additional argument of type, List<List<org.apache.neethi.Assertion>>. On
the server outbound side, this new argument will contain the policy alternatives from the
request that were successfully met by the request. The selector implementation should take
this list into account, in order to narrow down the set of alternatives.
The getEffectiveServerResponsePolicy method from the
org.apache.cxf.ws.policy.PolicyEngine interface now takes an additional
argument of type, List<List<org.apache.neethi.Assertion>>. The
PolicyEngine implementation can take this information into account, when
deciding which policy to return.
If Apache CXF is deployed in a container with an MBeanServer instance,
such as OSGi or Spring, the InstrumentationManager will be automatically
enabled using the MBeanServer instance and the Apache CXF MBeans will be
registered.
When deployed into an OSGi container, the bus ID now automatically includes the bundle's symbolic name, in order to make it easier to identify the bus instance.
Integration with Java 2 security has been improved. At various points in the code where
security checks are likely to be required (for example, accessing the file system or system
properties), calls are wrapped by the
java.security.AccessController.doPrivileged method. For more details, see
CXF-2683.
An empty partial response message is returned as an HTTP 202 response with no content, instead of an HTTP 200 response with an empty SOAP body.
The Logging interceptors now log using service-specific categories and loggers, instead
of just LoggingInInterceptor and LoggingOutInterceptor. The logger
name is given by the value of
org.apache.cxf.services.ServiceName.PortName.PortTypeName. This enables the
user to configure specific per-service filters and formatters in their logging
configuration.
The following changes have been made to the Java API:
Since 2.0, the org.apache.camel.ProducerTemplate class has
been refactored so that sendBody methods now return void for
InOnly messaging. Use one of the requestBody
methods for InOut messaging. See Producer and Consumer Templates in Programing EIP Components for more details.
Since 2.0, all specializations of org.apache.camel.Exchange
are now removed. You should now always use the
org.apache.camel.impl.DefaultExchange type. After analyzing the how
exchanges are used, it was realized that the specialized exchanges were not really
necessary and by removing them we can avoid a lot of unnecessary copying and improve
throughput.
One implication of this change is that Producer and
Consumer types no longer use generic type declarations. For example,
instead of referring to Producer<DefaultExchange> you can just refer
to a plain Producer.
getFault() and setFault() methodsSince 2.0, the getFault() and setFault()
methods are now removed from Exchange. Faults represent application
specific errors and are recognized by some protocols. Consequently, it makes more
sense to store a fault as the Out message in an exchange
(accessed using getOut() and setOut()). The
org.apache.camel.Message interface now exposes the boolean
isFault() and setFault() methods that are used to identify
Out messages that represent faults.
Because faults represent persistent errors (as opposed to exceptions, which represent transient errors), Camel does not try (as in previous versions) to recover from them (for example, the error handler does not trigger) unless handling faults as exceptions is explicitly enabled.
Since 2.0, the following changes have been made to the implementation of
org.apache.camel.processor.aggregate.AggregationStrategy:
The aggregate() method is now invoked on the very first exchange.
For this first invocation, the oldExchange parameter is
null.
The payload is now always stored in the In message when you do custom aggregation using this strategy interface.
Since 2.3, the aggregator has been re-implemented and some options have
been replaced. In particular, the algorithms for determining batch completeness have
changed significantly, so that the batchSize, outBatchSize,
batchTimeout, and batchConsumer options are no longer
supported. To understand the new mechanisms for completeness testing, it is
recommended that you read Aggregator in Implementing Enterprise Integration Patterns.
Since version 2.1, the following changes have been made to the
CamelContext class:
The shouldStartContext() method is replaced by the
autoStartup() method.
The getLifecycleStrategy() method has been renamed
getLifecycleStrategies() and now returns a
java.util.List.
Since version 2.5, the following changes have been made to the
CamelContext class:
The stopRoute() method is now integrated with the graceful
shutdown strategy (see Controlling Start-Up and Shutdown of Routes in Implementing Enterprise Integration Patterns). You can revert to the old behavior by specifying an
explicit timeout.
Since version 2.1, the
org.apache.camel.spi.ManagementNamingStrategy has had methods renamed
and method signatures changed in order to accomodate the JMX features in this
release.
Since version 2.3, the begin() method from
org.apache.camel.spi.PollingConsumerPollStrategy returns a boolean
value, where true indicates that polling can now start, while
false indicates that polling should be skipped.
Since version 2.3, the org.apache.camel.spi.RoutePolicy
interface has the new method, onInit().
Since version 2.9, the org.apache.camel.spi.RoutePolicy
interface has the following new methods: onRemove, onStart,
onStop, onSuspend, and onResume.
Since version 2.3, the org.apache.camel.Message interface
has the new method, removeHeaders().
Since version 2.3, the getExecutorService() and
setExecutorService() methods have been removed from the
org.apache.camel.impl.DefaultComponent and
org.apache.camel.impl.DefaultEndpoint classes. To create a thread pool,
use the ExecutorServiceManager object that is returned by the
CamelContext.getExecutorServiceManager() method.
For full details of the new threading model, see Threading Model in Implementing Enterprise Integration Patterns.
If you have developed a custom component and you have implemented an endpoint by
inheriting from the DefaultEndpoint class, it is strongly recommended
that you override the doStart() and doStop() methods,
instead of overriding the start() and stop() methods. Since
version 2.7, the default endpoint implementation ensures that the
doStart() and doStop() methods are called once and once
only.
Since version 2.3, the
org.apache.camel.component.file.GenericFile class is no longer
serializable (does not inherit from java.io.Serializable).
Since version 2.3, the adviceWith() method from
org.apache.camel.model.RouteDefinition takes a
CamelContext instance as its first parameter.
Since version 2.4, the toAsync() DSL command has been
removed. Asynchronous dispatch is now implemented directly (where appropriate) in
specific components and DSL commands.
Since version 2.4, the org.apache.camel.spi.Policy interface
has the new method, beforeWrap(). For quick migration of your
Policy classes, simply add an empty method implementation.
Since version 2.4, the retryUntil option on
onException has been renamed to retryWhile, because this
reflects the meaning of the option more accurately (it continues to retry while its
argument is true).
Since version 2.4, you can use either a string or an expression to
specify the name of the routing slip header. The Spring DSL has changed, such that the
headerName attribute is now replaced by the headerName
child element. For example, to specify the name of the routing slip header to be
myHeader, use an XML fragment like the following:
<route>
<from uri="direct:a"/>
<routingSlip ignoreInvalidEndpoints="true">
<headerName>myHeader</headerName>
</routingSlip>
</route> Since version 2.4, all sendBody and requestBody
methods from the ProducerTemplate class throw a
CamelExecutionException, which wraps the original exception.
Since version 2.4, the simple and xpath
expression builder methods are built into the RouteBuilder class. It is,
therefore, no longer necessary to use static imports to access these languages. In
your existing code, the Java compiler might complain, if you use static imports for
simple and xpath. To fix this, just remove the static
imports.
Since version 2.6, the org.apache.camel.spi.ManagementAware
interface is deprecated. If you want to expose a bean through JMX, use the Spring JMX
annotations instead.
For example, you would annotate a class using the Spring
@ManagedResource annotation, and then annotate each managed attribute
using @ManagedAttribute and each managed operation using
@ManagedOperation—see the Spring Reference Guide for details.
Since version 2.6, when implementing a custom data format class, you can
also optionally implement the Service and CamelContextAware
interfaces in order to receive callbacks at initialization and shutdown time. For
example, you can implement the MyCustomDataFormat class with callbacks,
as follows:
// Java
...
public class MyCustomDataFormat implements DataFormat, Service, CamelContextAware {
...
}Since version 2.6, the poll method in
ScheduledPollConsumer now returns the number of messages actually
processed from the poll.
Since version 2.7, the FATAL logging level has been removed
from org.apache.camel.LoggingLevel. Use ERROR
instead.
Since version 2.7, the getLeftValue() and
getRightValue() methods have been removed from
org.apache.camel.BinaryPredicate.
Since version 2.7, the parsePropertyValue() method from the
org.apache.camel.component.properties.PropertiesParser interface has
been renamed to parseProperty() and the signature has changed
from:
// Java // Versions prior to 2.7 String parsePropertyValue(String value);
To the new signature:
// Java // Camel 2.7 or later String parseProperty(String key, String value, Properties properties);
Since version 2.7, the sendBody and requestBody
methods from the org.apache.camel.management.mbean.ManagedCamelContext
take an Object instead of a String as their second
parameter. Two new methods, sendStringBody and
requestStringBody, have been added that take a String as
their second parameter.
The new method signatures are as follows:
// NEW method signagures void sendBody(String endpointUri, Object body); Object requestBody(String endpointUri, Object body); void sendStringBody(String endpointUri, String body); Object requestStringBody(String endpointUri, String body);
Since version 2.8, the deprecated handled methods on
errorHandler have been removed. If you need the functionality of the
handled method (for example, to set handled(false)), you must migrate to
use onException, which still supports the handled
method.
Since version 2.8, the semantics of the
wrapProcessorInInterceptors method from the
org.apache.camel.spi.InterceptStrategy class have changed, so that the
actual OutputDefinition instance is passed to
wrapProcessorInInterceptors.
Since version 2.9, the
org.apache.camel.spi.ExecutorServiceStrategy is deprecated in favor of
the new ExecutorServiceManager class, which has a slightly reduced and
improved API. For more details, see Threading Model in Implementing Enterprise Integration Patterns.
Since version 2.9, the
org.apache.camel.component.ResourceBasedComponent class from
camel-spring is deprecated. Use
org.apache.camel.impl.DefaultComponent from camel-core
instead.
Since version 2.9, the
org.apache.camel.component.ResourceBasedEndpoint class from
camel-spring is deprecated in favor of the new
org.apache.camel.component.ResourceEndpoint in camel-core,
and its dependency on Spring JARs has been removed. Use the new APIs on
ResourceEndpoint to load resources.
Since version 2.9, the signature of the method, beforePoll,
from the org.apache.camel.PollingConsumerPollingStrategy class has
changed.
Since version 2.9, ServiceSupport does not handle child
services any more. The new class,
org.apache.camel.support.ChildServiceSupport, now handles this case.
Additionally the org.apache.camel.StatefulService interface has been
added, which provides access to ServiceSupport methods without knowing
the implementation.
Since version 2.9, DataFormatResolver does not support the
resolveDataFormatDefinition method anymore. The current implementations
for OSGi and Default were exactly the same, so this code was moved to
DefaultCamelContext.
Since version 2.9, all methods in CamelContext that
reference model elements are deprecated. The new interface,
org.apache.camel.model.ModelCamelContext, has been created to hold
these methods
Since version 2.9, renameFile from
org.apache.camel.util.FileUtil has a new
copyAndDeleteOnRenameFail boolean option and throws
IOException in case of an exception.
Since version 2.9, the context, template, and consumer fields in
orb.apache.camel.test.CamelTestSupport are no longer static.
Since version 2.9, the org.apache.camel.WrappedFile
interface has been introduced, as an abstraction of the GenericFile
class, for use outside the file component.
Since version 2.9, all Spring-related methods in the
org.apache.camel.builder.script.ScriptBuilder class have been removed
(for example, methods taking org.springframework.core.io.Resource as an
argument).
Since version 2.9, the
org.apache.camel.builder.ErrorHandlerBuilder interface's
configure method takes a org.apache.camel.spi.RouteContext
argument.
Since version 2.9.0.fuse (back-ported from Apache Camel 2.10), the
org.apache.camel.spi.LifecycleStrategy interface has added the
onThreadPoolRemove method and the onErrorHandlerRemove
method.
Since version 2.9.0.fuse (back-ported from Apache Camel 2.10), the
convertTo methods defined on the
org.apache.camel.TypeConverter interface will throw a
TypeConversionException, if an exception occurs during type
conversion.
Since version 2.9.0.fuse (back-ported from Apache Camel 2.10), the
org.apache.camel.TypeConverter interface has added
tryConvertTo methods. The tryConvertTo methods are similar
to the convertTo methods, except that the invocation is wrapped in a try
block, so that it does not throw an exception.
The following classes have been removed from the API:
org.apache.camel.processor.CompositeProcessor org.apache.camel.impl.ProducerTemplateProcessor org.apache.camel.impl.NoPolicy org.apache.camel.spi.Provider org.apache.camel.spring.handler.LazyLoadingBeanDefinitionParser org.apache.camel.spring.handler.ScriptDefinitionParser org.apache.camel.spring.remoting.SendBeforeInterceptor org.apache.camel.spring.spi.SpringConverters
Since Apache Camel version 2.8, the following classes have been removed:
org.apache.camel.spi.ScriptEngineResolver
The following classes have moved to a different Java package:
PollingConsumerPollStrategy has moved from
org.apache.camel to org.apache.camel.spi.
PatternBasedPackageScanFilter has moved from
org.apache.camel.impl.scan to
org.apache.camel.spring.
The following classes have been renamed:
org.apache.camel.management.event.ExchangeFailureEvent has been renamed
to ExchangeFailedEvent.
Since Apache Camel version 2.7, the following classes have been renamed:
org.apache.camel.processor.Logger has been renamed to
org.apache.camel.processor.CamelLogger (and now uses slf4j
as the logger).
Since Apache Camel version 2.7, the following classes have moved to a different package:
JdbcAggregationRepository has moved from
org.apache.camel.component.jdbc.aggregationrepository to
org.apache.camel.processor.aggregate.jdbc.
Since Apache Camel version 2.8, the following classes have moved to a different package:
GZIPHelper has moved from the HTTP, HTTP4, and GHttp components to the
org.apache.camel.util package in camel-core.
CxfHeaderFilterStrategy has moved from
org.apache.camel.component.cxf (in camel-cxf) to
org.apache.camel.component.cxf.common.header (in
camel-cxf-transport).
ProxyInstantiationException has moved from
org.apache.camel.impl to org.apache.camel.
Since Apache Camel version 2.9, the following classes have moved to a different package:
Ordered has moved from org.apache.camel.util to
org.apache.camel.
BytesSource and StringSource have moved from
org.apache.camel.converter.jaxp to org.apache.camel.
TimeoutMap has moved from org.apache.camel.util to
org.apache.camel.
DefaultTimeoutMap has moved from org.apache.camel.util to
org.apache.camel.support.
Some management interfaces have moved from org.apache.camel.management
to org.apache.camel.spi.management.
DefaultChannel has moved from org.apache.camel.processor
to org.apache.camel.processor.interceptor.
ModelHelper has moved from org.apache.camel.util to
org.apache.camel.model.
ServiceSupport has moved from org.apache.camel.impl to
org.apache.camel.support (the old class is kept, but is
deprecated).
EventNotifierSupport has moved from
org.apache.came.management to org.apache.camel.support (the
old class is kept, but is deprecated).
Since version 2.0, the following changes have been made to the File and the FTP components:
Only a directory name can be specified directly in the endpoint, not a
filename. In other words, you must specify a File endpoint with the syntax,
file:
and an FTP component with the syntax,
directoryName[?options]ftp://[.
It is still possible to select individual files, however, by appending the
username@]hostname[:port]/directoryname[?options]fileName option, which enables you to specify files using the file expression
language.
File producer endpoints and FTP producer endpoints now overwrite existing files by
default (previously, the default behavior was to append to files).You can use the new
fileExist option to specify what happens when a producer attempts to
write a file that already exists. Valid values for the fileExist option
are: Override, Append, Fail, or
Ignore.
![]() | Important |
|---|---|
Both the File component and the FTP component have been extensively rewritten in Apache Camel 2.0. In particular, many of the component options have been renamed or modified. It is recommended that you check the configuration of your File and FTP endpoints against the latest component documentation—see File2 in Apache Camel Documentation and FTP2 in Apache Camel Documentation. |
Since Apache Camel 2.8, the default value of the useFixedDelay option has
changed from false to true.
The JMS correlationId is determined differently to before. Now, JMS always
uses the messageId as the correlationId, if configured to do so by
setting useMessageIDAsCorrelationID to true. If the setting is
false, the JMSCorrelationID header value is used, if present,
and the messageId value is used as a fallback, if the header is not
present.
Since Apache Camel version 2.5, the following changes have been made to the JMS component:
The JMS 1.0.2 API is no longer supported.
Durable topic subscribers now must provide a clientId value, otherwise
Apache Camel fails fast on start-up.
Since Apache Camel version 2.6, a URI of the form,
jms:queue:Foo?replyTo=FooReply&preserveMessageQos=true, can be used to
set the JMSReplyTo header in the outgoing message, even if the
Exchange has an InOnly MEP. In previous Apache Camel
versions, the URI replyTo option was ignored for InOnly
exchanges. For more details, see JMS in Apache Camel Documentation.
Since Apache Camel version 2.8, the default cache level has changed for JMS endpoints, from
CACHE_CONSUMER to CACHE_AUTO. When transactions are enabled,
CACHE_AUTO resolves to CACHE_NONE (caching disabled), in order
to guarantee compatibility with XA transactions. If you do not use XA
transactions, however, it is strongly recommended that you set the
caching level explicitly to CACHE_CONSUMER to improve performance. For more
details, see Configuring the JMS Component in EIP Transactions Guide.
The Bean component now enforces stricter matching of bean method parameters. Previously,
if a parameter could not be converted to the appropriate type, it was passed as
null. Now, all parameters must be convertible to the relevant types.
The allowMultipleConsumers option has been removed. A Direct endpoint can
now have only one consumer.
Since version 2.2, HTTP proxy configuration is set using
CamelContext properties instead of Java system properties.
Since version 2.3, the HTTP authentication options have been renamed, to avoid
clashing with the username and password URI parameters.
Authentication is now set using the authUsername, authPassword,
and authDomain options. In addition, you must specify the authentication method
using the authMethod option, which can take the values Basic,
Digest, or NTLM.
For the full list of HTTP authentication options, see HTTP in Apache Camel Documentation.
Since 2.0, these components support request/reply semantics. Endpoints of SEDA or VM type will wait for a reply, if a reply is expected.
Since 2.3, the size of the SEDA queue (which holds incoming exchanges) is unbounded, whereas previously it had a maximum size of 1000.
Since version 2.3, the header key,
MinaConsumer.HEADER_CLOSE_SESSION_WHEN_COMPLETE, is replaced by
MinaConstants.MINA_CLOSE_SESSION_WHEN_COMPLETE.
Since version 2.3, the Jetty component has been upgraded from Jetty 6.1.22 to Jetty 7.0.1. The Jetty API has changed significantly between these two versions. Because Jetty is now hosted at Eclipse, all Java packages have been renamed. If you use the Jetty API directly, you could use the Jetty 6 to Jetty 7 migration tool from Eclipse to simplify the migration of your source code.
Since version 2.3, the CXF component's PAYLOAD mode has been
improved to delegate all SOAP message parsing to CXF.
Since version 2.7, when using POJO data format, the CXF message attachments are
not copied to the attachment properties of the
In message—which means it is no longer possible to access a CXF
attachment by calling org.apache.camel.Message.getAttachment(). But the
attachments are still accessible from the message body. This avoids the problem affecting
earlier versions of Apache Camel, where the attachments must be explicitly cleared on the
message, in order to avoid being copied into the CXF response.
Since version 2.8, the Camel transport for CXF and the cxfbean
component have been moved from the camel-cxf artifact to the
camel-cxf-transport artifact. If you need to use either of these components,
you must a Maven dependency on the camel-cxf-transport artifact.
Since version 2.4, the following changes have been made to the FTP component:
The ftps default port has been changed from 2222 to 21.
The ftps protocol now uses a secure data channel while transferring
files, whereas previously only secure login was enabled. You can now use the
disableSecureDataChannelDefaults, execProt, and
execPbsz options to customize the behavior of the security channel. See
FTP2 in Apache Camel Documentation for details.
The FTP base directory can now be specified using an absolute path. In the endpoint
URI, insert two leading forward slashes, //, to specify an absolute path,
as in ftp:admin@someserver//absolutePath/foo/bar?password=secret.
The FTP component now uses a 10 second default connect timeout (for all protocols)
and a 30 second data timeout (for the ftp and ftps protocols
only).
Since version 2.5, the following changes have been made to the FTP component:
FTP consumer endpoints now traverse the file structure in a different way. It is recommended that you test any applications with FTP consumer endpoints to ensure that they are not affected by this change.
Since Apache Camel 2.5, the timeout option on the Netty component has been
removed, because it did not work properly.
Since version 2.9.0.fuse (back-ported from Apache Camel 2.10), the corePoolSize
and maxPoolSize options can no longer be set on a Netty endpoint, because the
component relies on the default Netty thread pool implementation.
Since Apache Camel 2.5, if you are using the Quartz component with jobs persisted in a database, you should note that Apache Camel now resolves job names based on the endpoint URI without parameters. This makes it possible to change cron parameters on the same job (that is, to reschedule the job).
Since Apache Camel 2.6, the Quartz component enforces that the trigger group/trigger name combination is unique within a given component instance and throws an exception, if a name clash is detected. This does not apply to clustered quartz, however.
Since Apache Camel 2.6, the mediaSize option on the Printer component uses
exactly the same constants as the Java printer API; that is, underscores are used instead of
hyphens in the constants.
Since Apache Camel 2.6, when using the JPA component to store trace information generated by
the Apache Camel trace interceptor, the JpaTraceEventMessage class now attaches the
@Lob annotation to any fields that could contain a lot of data, such as a
message body. This ensures that these large data fields are persisted as CLOB/BLOB JDBC
fields (and thus avoids truncating the data).
Since Apache Camel 2.9, the JPA component has been upgraded from using the JPA1 specification to use JPA2 specification.
Since Apache Camel 2.7, the Servlet component does not automatically start up a Spring
context any more. Hence, if you define your routes using a Spring configuration file, you
must start up a Spring context explicitly. For example, if you are deploying a Apache Camel
application as a Web application (.war file), the standard approach to starting
a Spring context is to create a ContextLoaderListener instance in the
web.xml file, as follows:
<web-app ...>
<display-name>My Web Application</display-name>
<!-- location of spring xml files -->
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:camel-config.xml</param-value>
</context-param>
<!-- the listener that kick-starts Spring -->
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<!-- Camel servlet -->
...
</web-app>Where camel-config.xml is the Spring configuration file located on the
classpath. For full details of how to deploy such a servlet application, see the
examples/camel-example-servlet-tomcat demonstration.
Since Apache Camel 2.7, the JDBC aggregator component has been incorporated into the SQL component. See SQL Component in Apache Camel Documentation for details.
Since Apache Camel 2.8, the header names used by the cache component have changed, so that
they are now prefixed by CamelCache. The headers are now:
CamelCacheGet, CamelCacheCheck, CamelCacheAdd,
CamelCacheUpdate, CamelCacheDelete, and
CamelCacheDeleteAll.
The headers are now removed from the exchange, after the caching has been performed.
Since Apache Camel 2.8, the options for configuring HTTP Basic Authentication and HTTP Proxies have different names. See HTTP4 in Apache Camel Documentation for details.
The Log in Apache Camel Documentation component no longer shows
stream message bodies by default, but you can use the new showStreams option to
enable that behavior. Likewise the Log component does not automatically convert the payload
to the StreamCache type. For that you need to explicitly enable stream caching
on the route or on the Camel context.
Since Apache Camel 2.8, the CamelBeanMethodName header is removed after an
exchange passes through a Bean endpoint.
Since Apache Camel 2.9, the CSV component always returns the List<List >
type, even if only one row is returned, in order to be more consistent.
Since Apache Camel 2.9, the Validation component has been moved from
camel-spring to camel-core as it no longer depends on Spring
JARs.
Since Apache Camel 2.9, the XSLT component has been moved from camel-spring to
camel-core as it no longer depends on Spring JARs.
Since Apache Camel 2.9, the Mail component no longer depends on the Spring APIs. Any custom
JavaMailSender class must now implement
org.apache.camel.component.mail.JavaMailSender instead of the corresponding
Spring interface.
Since Apache Camel 2.9, the QuickFix component no longer depends on the Spring APIs. If you
want to use the XML DSL to set up QuickFix, you must now use the
QuickfixjConfiguration class in place of the
QuickfixjSettingsFactory class. For more details, see Quickfix in Apache Camel Documentation.
Table 3.1 provides an overview of the DSL commands that have been renamed in 2.0.
Table 3.1. Renamed DSL Commands
| Old Java DSL Name | Old Spring DSL Name | New DSL Name |
|---|---|---|
splitter | splitter | split |
resequencer | resequencer | resequence |
aggregator | aggregator | aggregate |
delayer | delayer | delay |
throttler | throttler | throttle |
expression | expression | language |
tryBlock | try | doTry |
handle | catch | doCatch |
finallyBlock | finally | doFinally |
intercept | intercept | interceptFrom |
thread | thread | threads |
|
(in | lookup | |
throwFault | Removed |
The following changes were made to the errorHandler DSL command in Apache Camel
version 2.1:
In the Java DSL the, errorHandler DSL command can now be configured
only on a route or a Camel context. In the case of routes, you must set it directly
after the from DSL command.
In Spring DSL, the errorHandlerRef attribute is now available only on
the camelContext and route elements.
Since Apache Camel version 2.3, the adviceWith() DSL command now takes
CamelContext as its first argument.
Since Apache Camel version 2.3, the Java DSL now requires onException (and
similar clauses) to appear at the start of the route, otherwise
Apache Camel will fail to start the route.
Since Apache Camel version 2.7, the ref attribute on the
redeliveryPolicy element has been removed. Use the
redeliveryPolicyRef attribute either on the onException element
or on the errorHandler element, instead.
Since Apache Camel version 2.7, the batch-config element or the
stream-config element, if present, must now appear as the
first child element of the resequence element (in
previous versions, they appeared as the last child element). For example, the
stream-config element must now appear as follows inside a route:
<camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
<route>
<from uri="direct:start"/>
<resequence>
<stream-config capacity="5000" timeout="4000"/>
<simple>in.header.seqnum</simple>
<to uri="mock:result" />
</resequence>
</route>
</camelContext>Since Apache Camel version 2.7, the sortBody() command has been removed from
the Java DSL. Use sort(body()) instead.
Since Apache Camel version 2.7, the expression in a Spring DSL sort element is
no longer enclosed inside an expression element. For example, to sort the
contents of the current message body, you must now specify the sort element as
follows in the Spring DSL:
<sort> <simple>body</simple> </sort>
Whereas the old sort syntax (prior to version 2.7) would have been:
<sort>
<expression>
<simple>body</simple>
</expression>
</sort>Since Apache Camel version 2.8, when using the send-new-message mode, you can now specify
headers directly in the Java DSL using the setExchangeHeader() clause. For
example:
from("direct:start")
.wireTap("direct:tap")
// create the new tap message body and headers
.newExchangeBody(constant("Bye World"))
.newExchangeHeader("id", constant(123))
.newExchangeHeader("date", simple("${date:now:yyyyMMdd}"))
.end()In the XML DSL, use the setHeader child element, as follows:
<route>
<from uri="direct:start"/>
<wireTap uri="direct:tap">
<!-- create the new tap message body and headers -->
<body><constant>Bye World</constant></body>
<setHeader headerName="id"><constant>123</constant></setHeader>
<setHeader headerName="date"><simple>${date:now:yyyyMMdd}</simple></setHeader>
</wireTap>
...
</route>Since Apache Camel version 2.8, in the XML DSL, the maximumRequestsPerPeriod
attribute of the throttle element has been removed. You now specify the maximum
requests per period using an expression that appears as a child of of the
throttle element. For example, to throttle the message rate to a maximum of
three messages every 10 seconds:
<route>
<from uri="seda:a"/>
<!-- throttle 3 messages per 10 sec -->
<throttle timePeriodMillis="10000">
<constant>3</constant>
<to uri="mock:result"/>
</throttle>
</route>The advantage of using an expression here is that it enables you to specify the rate dynamically at run time.
Since Apache Camel version 2.8, in the XML DSL, the bean, marshal,
and unmarshal elements are no longer permitted to have any child
elements.
Since Apache Camel version 2.8, the JDBC and JPA-based idempotent repositories now contain a
createdAt column.
Since Apache Camel version 2.8, the following DSL methods, which used an
ExpressionClause to build up an expression, have been removed:
aggregate(...).completionPredicate() catch(...).onWhen() idempotentConsumer(...).expression() onCompletion(...).onWhen() onException(...).onWhen() idempotentConsumer() split(...).expression() try(...).onWhen() expression() on WhenDefinition
Instead of building up the expression using an expression clause builder, you can use the form of DSL method that specifies the expression directly as an argument. For example:
aggregate(...).completionPredicate(body().isEqualTo("END"))...The following JAR dependencies have changed:
From Apache Camel 2.4 onwards, the OSGi integration code and the Spring integration code have been decoupled, so that there is no longer any need for the following artifacts:
camel-osgi
camel-spring-osgi
In fact, these artifacts are no longer provided with Apache Camel 2.4. If you want to
use the integration with Spring, you only need to install the camel-spring
artifact.
From Apache Camel 2.5 onwards, the following test artifacts have been deprecated and will be removed in a future release:
camel-core-tests
camel-spring-tests
In future, you should use only the camel-test artifact, if you want to
use the Apache Camel test kit.
From Apache Camel 2.9 onwards, the following dependencies have changed:
commons-management is no longer required as a dependency.
The Spring JARs are no longer needed for Apache Camel to enlist in JMX.
Apache Camel 2.9 has the following known issues:
The Tracer component produces incomplete output for certain kinds of processor. For
example, tracer output is incomplete for the onCompletion and
intercept DSL commands.
In the source distribution, the mvn site command does not build a
complete site. There are no plans to fix this, because Apache Camel does not use the Maven
site.
The source code cannot build fully with J2SE 1.7 (JDK 7).
Apache Camel 2.2 uses the new DefaultErrorHandler, instead of the
DeadLetterChannel (versions 1.x), as the default error handler. This new
DefaultErrorHandler implementation does not catch and
handle thrown exceptions, which means any exception thrown will be propagated back to the
caller.
Since Apache Camel 2.5, onException clauses defined at
RouteBuilder level must be defined before the routes,
otherwise Apache Camel throws an exception while starting the routes.
Since Apache Camel 2.8, exceptions thrown while handling other exceptions in
onException are now caught by a fallback error handler, which logs the second
exception and propagates the second exception in the Exchange. The Exchange will then cease
processing and fail immediately.
Stream caching is a feature that enables you to re-read a message body consisting of a stream type. The interaction between Apache ServiceMix and Apache Camel has now been modified in such a way that Apache Camel does not need to use stream caching. It is therefore disabled by default.
![]() | Note |
|---|---|
If necessary, you can re-enable caching by adding the |
The following changes have been made to the Java annotations:
The name attribute in @EndpointInject has been changed to
ref, in order to be consistent with the other annotations (where the
@EndpointInject annotation references an Endpoint that gets looked up in
the Registry).
Since 2.3, the spelling of the parallelProcessing attribute in
@RecipientList has been fixed.
Since 2.0, header look-up in org.apache.camel.Message is
case-insensitive. This means that if you look up a header using differently cased keys (such
as Foo and foo), you will obtain a reference to the
same header entry. This makes header look-up less error-prone when
used with protocols such as HTTP, where header names are inherently case insensitive.
The round robin load balancing behavior has changed in Apache Camel 2.2. In version 1.x, the round robin load balancer would fail over, if an endpoint failed to process the message. In version 2.2, the round robin load balancer does not fail over immediately, but tries to redeliver the message to the same endpoint, according to the error handling configuration.
![]() | Note |
|---|---|
Apache Camel 2.3 will introduce an option that allows you to specify which behavior you want the endpoint to exhibit. |
Since 2.3, if the exchange that enters the splitter has the
InOut message-exchange pattern (that is, a reply is expected), the
splitter returns a copy of the original input message as the reply message in the
Out message slot. To revert to the old (pre 2.3) behavior, configure
the splitter to use the UseLatestAggregationStrategy aggregation
strategy.
Since Apache Camel 2.3, the NodeList to String converter has been
improved to include XML tags and attributes. For example, the conversion can now produce
strings like <foo id="123">bar<year>2015</year></foo>.
This change will affect code that relied on the old string conversion. For example, if
you previously extracted strings from XML using @XPath annotations as in the
following method signature:
// Java
// Camel version 2.2 or earlier:
public void credit(
@XPath("/transaction/transfer/receiver") String name,
@XPath("/transaction/transfer/amount") String amount
)You must now explicitly specify the text() node, in order to avoid
including the element tags in the string, as follows:
// Java
// Camel version 2.3 or later
public void credit(
@XPath("/transaction/transfer/receiver/text()") String name,
@XPath("/transaction/transfer/amount/text()") String amount
)The character set used by converters can be set using the
org.apache.camel.default.charset Java system property. The default is
UTF-8.
Since Apache Camel 2.5, the following changes affect CamelContext:
Apache Camel fails to start up, if more than one CamelContext instance with
the same ID is registered in JMX.
If you do not specify an ID value for a camelContext element, Apache Camel
now assigns an automatically generated ID from the sequence, camel-1,
camel-2, and so on. In previous Apache Camel versions, the ID value defaulted
to the string, camelContext.
Since Apache Camel 2.5, Apache Camel supports the use of third party UUID generators. The
default UUID generator is based on the same implementation used in Apache ActiveMQ,
ActiveMQUuidGenerator. Some of the APIs required by this implementation (for
example, the Google app engine) might not be accessible in all deployment contexts, in which
case you should switch to another of the UUID generator implementations. The following
implementations are provided:
org.apache.camel.impl.JavaUuidGenerator.
org.apache.camel.impl.SimpleUuidGenerator.
org.apache.camel.impl.ActiveMQUuidGenerator.
You can set the UUID generator in either of the following ways:
In the Java DSL, call the CamelContext.setUuidGenerator() method as
follows:
// Java getContext().setUuidGenerator(new MyCustomUuidGenerator());
In the Spring DSL, simply instantiate a bean of the requisite type. For example, to
enable the JavaUuidGenerator:
<bean id="javaUuidGenerator"
class="org.apache.camel.impl.JavaUuidGenerator" />Since Apache Camel 2.5, if there is a problem with starting the JMX service, Apache Camel will
not start at all. In previous versions, if JMX failed, a warning was logged (at
WARN level) and Apache Camel continued to start up without the JMX service. The
problem with the old behavior is that it could lead to errors later on—for example,
some J2EE servers might throw a security exception, if you try to access a JMX MBean server
at run time when JMX has failed to start.
![]() | Note |
|---|---|
Programmers who want to exploit the fail safe mechanism for custom features now have
the option of raising the |
Since Apache Camel 2.5, by default, the aggregator pattern uses a synchronous invocation to processes completed aggregated exchanges. This ensures that no internal task queue is used, effectively throttling the incoming stream of messages. To switch to asynchronous operation, enable the parallel processing option.
Since Apache Camel 2.7, the camel-archetype-war Maven archetype is renamed to
camel-archetype-webconsole.
Since Apache Camel 2.8, the camel-spring-tests and the
camel-blueprint-tests Maven artifacts are no longer being released to the
Maven central repository.
Since Apache Camel 2.8, pollEnrich now sets an empty message body, if the Content Enricher could
not poll from the resource. Previously the old message body would be preserved.
Since Apache Camel 2.8, it is highly recommended that you modify the contents of the
META-INF/services/org/apache/camel/TypeConverter file to specify the
fully-qualified names of the type converter classes. This is much
more efficient, because it makes it unnecessary to scan all of the Java packages to find the
type converter classes at run time.
Since Apache Camel 2.9, debugger is now disabled by default in Camel Test. You would need to
override the isUseDebugger() method and return true to enable
it.
Since Apache Camel 2.9, the Simple language has an improved syntax parser. Simple is now
more strict and will report syntax errors for invalid input. For example, predicates now
require literal text to be enclosed in quotes. The range operator also requires
the range to be enclosed in quotes. For details, see The Simple Language in Routing Expression and Predicate Languages.
Since Apache Camel 2.7, the Apache Camel requires JDK 1.6 (the recommended version is JDK 1.6u21).
Since Apache Camel 2.9, you require Maven 3.0.x or later to build the source distribution of Apache Camel. Maven 2.x is now deprecated and support for it will be removed in the next release.
Since Apache Camel 2.7, Apache Camel has switched from Apache Commons Logging to the Simple Logging Facade for Java
(slf4j). If your application code uses log4j logging, you must now
include a dependency on the slf4j-log4j12 artifact. For example, if you use the
Maven build system, you would add the following Maven dependency to your POM file:
<project ...> <properties> <slf4j-version>1.6.1</slf4j-version> ... </properties> ... <dependencies> ... <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> <version>${slf4j-version}</version> </dependency> ... </dependencies> ... </project>
Where the slf4j version used by Apache Camel 2.8.0. is 1.6.1.
Since Apache Camel 2.7, some components have had their third party dependencies upgraded, as follows:
HTTP4—is upgraded to use Apache HttpClient 4.1.
Spring integration—is upgraded to use the Spring integration 2.0 API.
Web console—is upgraded to use Scalate 1.4.1.
Restlet—is upgraded to use Restlet 2.0.5.
In Apache Camel 2.8, some components have had their third party dependencies upgraded, as follows:
FTP—is upgraded to use Commons Net 2.2 (from 2.0).
Spring Web Services—is upgraded to release 2.0.2.
Cometd—is upgraded to 2.1.0 (from 1.0.1).
In Apache Camel 2.9, some components have had their third party dependencies upgraded, as follows:
Cometd—is upgraded to 2.3.1 (from 2.1.1).
EasyMock—is upgraded to 3.0 (from 2.5.2).
EHCache—is upgraded to 2.4.3 (from 2.3.0).
Jackrabbit—is upgraded to 2.2.4 (from 1.5.5).
JCR API—is upgraded to 2.0 (from 1.0).
OGNL—is upgraded to 3.0.2 (from 2.7.3).
XStream—is upgraded to 1.4.1 (from 1.3.1).
Since 2.7, the version of Spring that you can use with must be 3.0.5 (or later). Spring 2.5 is no longer supported.
If you explicitly specify the location of the Spring schema in your Spring configuration files, you must change the schema location to point at the 3.0 Spring schema. The Spring 3.0 is located at the following Web page:
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
For example, assuming your schema locations are specified in the root beans
element, you could specify the new Spring schema location as follows:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">It appears that the order in which beans are dependency injected has changed in Spring
3.0. This could potentially affect your existing Apache Camel applications when you upgrade. To
gain more control over the order of dependency injection, you could add the
depends-on attribute to some of your bean definitions.
For a summary of the new features in Spring 3.0, see New Features and Enhancements in Spring 3.0.
This section summarizes the issues you need to consider when migrating from Apache Camel 2.8 to Apache Camel 2.9.
In preparation for Apache Camel 3.0, a considerable amount of refactoring was undertaken for Apache Camel 2.9. Hence, a relatively large number of changes have been made to the API. You should also note the following important changes:
Building the source with Apache Maven 2.x is now deprecated and support for it will be removed in the next release. We recommend that you use Maven 3.0.x instead.
Apache Ant is no longer supported for building the examples.
The commons-management JAR is no longer required as a
dependency.
The Spring JARs are no longer needed for Apache Camel to enlist in JMX.
In Apache Camel 2.9, some components have had their third party dependencies upgraded, as follows:
AHC 1.6.4 to 1.6.5
AWS-Java-SDK 1.1.1 to 1.2.12
CometD Java Server 2.1.1 to 2.3.1
Commons-pool 1.5.4 to 1.5.6
CXF 2.4.1 to 2.5.1
Dozer 5.3.1 to 5.3.2
EasyMock 2.5.2 to 3.0
EHCache 2.3.0 to 2.4.3
Groovy 1.8.0 to 1.8.5
HAPI 0.5.1 to 1.2
HawtDB 1.5 to 1.6
Hazelcast 1.9.3 to 1.9.4.4
Http4 4.1.1 to 4.1.2
Jackson 1.8.4 to 1.9.2
Jackrabbit 1.5.5 to 2.2.4
JCR API 1.0 to 2.0
Jersey 1.8 to 1.10
JIBX 1.2.2 to 1.2.3
JRuby 1.5.6 to 1.6.5
MyBatis 3.0.4 to 3.0.6
Netty 3.2.4 to 3.2.6
OGNL 2.7.3 to 3.0.2
QPID 0.5 to 0.12
QuickFix 1.5.0 to 1.5.1
Restlet 2.0.9 to 2.0.10
Scala 2.9.0 to 2.9.1
Scalate 1.5.0 to 1.5.3
Smack 3.1.0 to 3.2.0
Spring Framework 3.0.5 to 3.0.6
Spring Security 3.0.6 to 3.0.7
Spring WebService 2.0.2 to 2.0.3
XStream 1.3.1 to 1.4.1
In 2.9, the following changes have been made to the Java API:
Since version 2.9, the
org.apache.camel.spi.ExecutorServiceStrategy is deprecated in favor of
the new ExecutorServiceManager class, which has a slightly reduced and
improved API. For more details, see Threading Model in Implementing Enterprise Integration Patterns.
Since version 2.9, the
org.apache.camel.component.ResourceBasedComponent class from
camel-spring is deprecated. Use
org.apache.camel.impl.DefaultComponent from camel-core
instead.
Since version 2.9, the
org.apache.camel.component.ResourceBasedEndpoint class from
camel-spring is deprecated in favor of the new
org.apache.camel.component.ResourceEndpoint in camel-core,
and its dependency on Spring JARs has been removed. Use the new APIs on
ResourceEndpoint to load resources.
Since version 2.9, the signature of the method, beforePoll,
from the org.apache.camel.PollingConsumerPollingStrategy class has
changed.
Since version 2.9, ServiceSupport does not handle child
services any more. The new class,
org.apache.camel.support.ChildServiceSupport, now handles this case.
Additionally the org.apache.camel.StatefulService interface has been
added, which provides access to ServiceSupport methods without knowing
the implementation.
Since version 2.9, DataFormatResolver does not support the
resolveDataFormatDefinition method anymore. The current implementations
for OSGi and Default were exactly the same, so this code was moved to
DefaultCamelContext.
Since version 2.9, all methods in CamelContext that
reference model elements are deprecated. The new interface,
org.apache.camel.model.ModelCamelContext, has been created to hold
these methods
Since version 2.9, renameFile from
org.apache.camel.util.FileUtil has a new
copyAndDeleteOnRenameFail boolean option and throws
IOException in case of an exception.
Since version 2.9, the context, template, and consumer fields in
orb.apache.camel.test.CamelTestSupport are no longer static.
Since version 2.9, the org.apache.camel.WrappedFile
interface has been introduced, as an abstraction of the GenericFile
class, for use outside the file component.
Since version 2.9, the org.apache.camel.spi.RoutePolicy
interface has the following new methods: onRemove, onStart,
onStop, onSuspend, and onResume.
Since version 2.9, all Spring-related methods in the
org.apache.camel.builder.script.ScriptBuilder class have been removed
(for example, methods taking org.springframework.core.io.Resource as an
argument).
Since version 2.9, the
org.apache.camel.builder.ErrorHandlerBuilder interface's
configure method takes a org.apache.camel.spi.RouteContext
argument.
Since version 2.9.0.fuse (back-ported from Apache Camel 2.10), the
org.apache.camel.spi.LifecycleStrategy interface has added the
onThreadPoolRemove method and the onErrorHandlerRemove
method.
Since version 2.9.0.fuse (back-ported from Apache Camel 2.10), the
convertTo methods defined on the
org.apache.camel.TypeConverter interface will throw a
TypeConversionException, if an exception occurs during type
conversion.
Since version 2.9.0.fuse (back-ported from Apache Camel 2.10), the
org.apache.camel.TypeConverter interface has added
tryConvertTo methods. The tryConvertTo methods are similar
to the convertTo methods, except that the invocation is wrapped in a try
block, so that it does not throw an exception.
The following classes have been renamed or moved:
Ordered has moved from org.apache.camel.util to
org.apache.camel.
BytesSource and StringSource have moved from
org.apache.camel.converter.jaxp to org.apache.camel.
TimeoutMap has moved from org.apache.camel.util to
org.apache.camel.
DefaultTimeoutMap has moved from org.apache.camel.util to
org.apache.camel.support.
Some management interfaces have moved from org.apache.camel.management
to org.apache.camel.spi.management.
DefaultChannel has moved from org.apache.camel.processor
to org.apache.camel.processor.interceptor.
ModelHelper has moved from org.apache.camel.util to
org.apache.camel.model.
ServiceSupport has moved from org.apache.camel.impl to
org.apache.camel.support (the old class is kept, but is
deprecated).
EventNotifierSupport has moved from
org.apache.came.management to org.apache.camel.support (the
old class is kept, but is deprecated).
In 2.9, you need to consider the following component updates:
JPA component—has been upgraded from using the JPA1 specification to use JPA2 specification.
CSV component—always returns the List<List
> type, even if only one row is returned, in order to be more
consistent.
Validation component—has been moved from
camel-spring to camel-core as it no longer depends on Spring
JARs.
XSLT component—has been moved from
camel-spring to camel-core as it no longer depends on Spring
JARs.
Mail component—no longer depends on the Spring APIs. Any
custom JavaMailSender class must now implement
org.apache.camel.component.mail.JavaMailSender instead of the
corresponding Spring interface.
QuickFix component—no longer depends on the Spring APIs.
If you want to use the XML DSL to set up QuickFix, you must now use the
QuickfixjConfiguration class in place of the
QuickfixjSettingsFactory class. For more details, see Quickfix in Apache Camel Documentation.
Netty component—the corePoolSize and
maxPoolSize options can no longer be set on a Netty endpoint, because the
component relies on the default Netty thread pool implementation.
Since Apache Camel 2.9, debugger is now disabled by default in Camel Test. You would need to
override the isUseDebugger() method and return true to enable
it.
Since Apache Camel 2.9, the Simple language has an improved syntax parser. Simple is now
more strict and will report syntax errors for invalid input. For example, predicates now
require literal text to be enclosed in quotes. The range operator also requires
the range to be enclosed in quotes. For details, see The Simple Language in Routing Expression and Predicate Languages.
Table of Contents
Fuse ESB Enterprise 7.0 does not support Apache ODE. The latest version of ODE is not compatible with Fuse ESB Enterprise.
Fuse ESB Enterprise 7.0 supports Apache ActiveMQ 5.5.1.fuse-70-097. For information on the migration issues involved with Apache ActiveMQ see Apache ActiveMQ Issues.
Fuse ESB Enterprise 7.0 supports Apache Camel 2.9.0.fuse-70-097. For information on the migration issues involved with Apache ActiveMQ see Apache Camel Issues.
Fuse ESB Enterprise 7.0 supports Apache CXF 2.5.0.fuse-70-097. For information on the migration issues involved with Apache ActiveMQ see Apache CXF Issues.
In Fuse ESB Enterprise 7.0, the kernel has been upgraded to Apache Karaf 2.2.5. As a result of this upgrade, the following dependencies have also been upgraded:
Jasypt is upgraded to version 1.8.
Jetty is upgraded to version 7.4.5.
Pax Web is upgraded to version 1.0.8.
Pax URL is upgraded to version 1.2.8.
Pax Runner is upgraded to version 1.6.2.
In Apache Karaf 2.2.5, omitting the name attribute from the features
element in a features repository file is now a deprecated syntax, which will result in a
warning. In a future version of Apache Karaf, the XML schema will be changed to make the
name attribute a required attribute.
Table of Contents
List of Tables
Apache ActiveMQ clients are compatible with later versions of the broker, as long as the client version and the broker version have the same major version number. For example, if you update an Apache ActiveMQ broker to version 5.5.1, it will be compatible with clients on version 5.4.2. This makes it possible to perform an upgrade in stages, starting with the broker hosts and then followed by the client hosts.
