-
Language:
English
-
Language:
English
Red Hat Training
A Red Hat training course is available for Red Hat Fuse
Migration Guide
Red Hat JBoss Fuse
Migrating to Red Hat JBoss Fuse 6.3
Red Hat
Version 6.3
Copyright © 2011-2020 Red Hat, Inc. and/or its affiliates.
27 Oct 2020
Abstract
Use this guide to help you when when upgrading to the latest version of Red Hat JBoss Fuse.
Chapter 1. What's New
Abstract
This section describes the main features and changes in version 6.3.
1.1. New Features
The main new features in version 6.3 are:
- JBoss Fuse tooling is available in Red Hat JBoss Developer Studio starting with Developer Studio 11.0. Previously, Fuse tooling was available in Red Hat JBoss Developer Studio Integration Stack.
- The look and feel of the Fuse tooling Camel route editor has been revised.
- The Camel CDI component has been rewritten to provide better integration with the JSR 299: Contexts and Dependency Injection (CDI) programming model. See chapter "Camel CDI" in "Deploying into Apache Karaf" for more details.
- New Camel Braintree component (
camel-braintree
) provides integration with various payment systems, including PayPal. See chapter "Braintree" in "Apache Camel Component Reference" for more details. - New Camel ServiceNow component (
camel-servicenow
) provides integration with the ServiceNow REST API. See chapter "ServiceNow" in "Apache Camel Component Reference" for more details. - RH-SSO adapter for JBoss Fuse is now supported in combination with the 6.3.0 Roll Up 2 patch version of JBoss Fuse. See the section JBoss Fuse Adapter from the RH-SSO 7.1 Securing Applications and Services Guide for more details.NoteJBoss Fuse 6.3.0 Roll Up 1 is the minimum required version, but 6.3.0 Roll Up 2 is recommended.
1.2. Important Notes
Oracle JDK 1.7 is incompatible with Maven central repository
Due to recent changes in the security requirements for connecting to the Maven central repository, Oracle JDK 1.7 is no longer compatible with Maven central and is unable to download Maven artifacts. We recommend that you upgrade to Oracle JDK 1.8 to avoid this issue. See section "List of Known Issues" in "Release Notes" for more details.
New Maven repository
Since JBoss Fuse 6.3, the JBoss Fuse Maven artifacts are available only from the following Maven repositories:
Hence for JBoss Fuse 6.3, you need to edit your Maven
settings.xml
file, replacing the old repo.fusesource.com
repository URLs (at https://repo.fusesource.com/nexus/content/repositories/releases and https://repo.fusesource.com/nexus/content/groups/ea) with the new Maven repository URLs.
Note
Older versions of JBoss Fuse (prior to 6.3) continue to use the old Maven repositories.
ActiveMQ runtime can now be wired to JMS 2.0 API bundle in OSGi
In JBoss Fuse 6.3, the ActiveMQ runtime has been modified so that it is compatible with and can be wired to the JMS 2.0 API bundle. This does not imply that ActiveMQ supports JMS 2.0. In fact, ActiveMQ still supports JMS 1.1 only. This change does mean, however, that it is now possible to deploy an ActiveMQ broker (which is a JMS 1.1 application) alongside a JMS 2.0 compliant application in the same OSGi container. This can be useful, for example, if you want to deploy two different messaging products in the same Apache Karaf container.
Upgraded Jetty from 8.1.x to 9
In the Apache Karaf container, Jetty (which provides the default HTTP servlet container for Karaf) has been upgraded from Jetty 8.1.x to Jetty 9. This has a significant impact on the Jetty container configuration, affecting settings in the
etc/org.ops4j.pax.web.cfg
file, in the etc/jetty.xml
file, and in the Camel Jetty endpoint. For more details, see chapter "Securing the Jetty HTTP Server" in "Security Guide" and chapter "Securing the Camel Jetty Component" in "Security Guide".
Apache Karaf package name changed from jboss-fuse-full to jboss-fuse-karaf
The package name for the Apache Karaf distribution of JBoss Fuse has changed from
jboss-fuse-full-ProductVersion.zip
to jboss-fuse-karaf-ProductVersion.zip
in this release.
CXF security changes
Note the following important changes to CXF security in this release:
- The STS (Security Token Service) now issues tokens using the RSA-SHA256 signature algorithm by default (previously RSA-SHA1), and the SHA-256 digest algorithm (previously SHA-1).
- The SAML/XACML functionality previously available in the
cxf-rt-security
module is now in thecxf-rt-security-saml
module.
New interceptor required for transactional RFC SAP endpoints
A new interceptor object is provided in JBoss Fuse 6.3, which is needed to configure transactional RFC destinations properly for the Camel SAP component. For details, see section "Interceptor for tRFC and qRFC destinations" in "Apache Camel Component Reference".
Make Quickstart Examples Available
In previous releases, profiles for quickstart example were available by default. The new default behavior is that profiles for quickstart examples are not available in a new fabric. To create a fabric in which you can run the quickstart examples, edit the
$FUSE_HOME/fabric/io.fabric8.import.profiles.properties
file by uncommenting the line that starts with the following:
# importProfileURLs =
If you create a fabric without doing this and you want to run the quickstart examples, follow these steps to make them available:
- Edit the
$FUSE_HOME/quickstarts/pom.xml
file to add a fabric I/O plugin, for example:<plugin> <groupId>io.fabric8</groupId> <artifactId>fabric8-maven-plugin</artifactId> <version>1.2.0.redhat-630187</version> </plugin>
- In the
$FUSE_HOME/quickstarts
directory, change to the directory for the quickstart example you want to run, for example:cd beginner
- In that directory, execute the following command:
mvn fabric8:deploy
You would need to run this command in each directory that contains a quickstart example that you want to run.
Chapter 2. Deprecated and Removed Features
Abstract
After recent planning activities for JBoss Fuse 7.0, additional features have been deprecated for 7.0, as listed under Section 2.2, “April 2017 6.3 Addendum”.
If you need any assistance or have any questions about the upcoming changes in Fuse 7, please contact support@redhat.com.
2.1. Cumulative List of Deprecated 6.x Features
A complete list of the features that are deprecated from the JBoss Fuse 6.x family of products (including those from previous minor releases) is given in the knowledge base article, JBoss Fuse 6.x Deprecated and Removed Features.
2.2. April 2017 6.3 Addendum
Features that were deprecated in the context of planning for the next major release, 7.0, of JBoss Fuse.
Embedded ActiveMQ broker will be removed in 7.0
In JBoss Fuse 7.0, JBoss Fuse on Karaf will no longer provide an embedded ActiveMQ Broker. Customers should connect to a supported remote broker directly. For more information on our supported brokers please refer to the messaging lifecycle.
Geronimo transaction manager will be replaced in 7.0
In JBoss Fuse 7.0, the Geronimo transaction manager in the Karaf container will be replaced by Narayana.
JBoss Fuse integration pack will be removed in 7.0
In JBoss Fuse 7.0, support for running rules and processes will be provided by components shipped with Red Hat JBoss BPM Suite and Red Hat JBoss BRMS.
Jetty container will be replaced in 7.0
In JBoss Fuse 7.0, the Jetty container will be replaced by Undertow. Initially, this change applies only to internal use of the Jetty container (for example, in the Karaf container). Other Jetty components will be removed in a future release
Karaf console commands for child container administration will be removed in 7.0
In JBoss Fuse 7.0, the Karaf console commands for child container administration (commands prefixed by
admin:
, such as admin:create
, admin:list
, and so on) will be removed.
SwitchYard will be removed in 7.0
In JBoss Fuse 7.0, SwitchYard will be removed, and you should use Apache Camel directly instead. For more detailed information, see the knowledge base article, SwitchYard Support Plan After Releasing JBoss Fuse 7.
2.3. October 2016 GA
Features that were deprecated or removed at the time of the JBoss Fuse release in October 2016.
Support for Fabric8 1.x will be removed in the next major release of JBoss Fuse
In the next major release of JBoss Fuse (planned as JBoss Fuse 7.0), Fabric8 v1 will be replaced by Fuse Integration Services (FIS), which includes components of Fabric8 v2 technology. FIS provides a set of tools and Docker-formatted images that enable development, deployment, and management of integration microservices within OpenShift.
Although FIS has a different architecture, it fulfills the same provisioning, automation, central configuration and management requirements that Fabric8 v1 provides. For more information, please see Red Hat JBoss Fuse Integration Services 2.0 for OpenShift.
Please contact Fuse Support with any questions or concerns.
bin/deletefabric8 script has been removed
The
bin/deletefabric8
script has been removed in this release.
Camel components for Google App Engine are deprecated
The GAE components for Apache Camel are deprecated in JBoss Fuse 6.3 and will be removed from a future release of JBoss Fuse.
Camel Netty component is deprecated
The Camel Netty component and the SwitchYard Camel Netty component are both deprecated in JBoss Fuse 6.3 and will be removed in a future release of JBoss Fuse. It is recommended that you use the Camel Netty4 component instead.
Camel jBPM component is deprecated
The Camel jBPM component (
camel-jbpm
) is deprecated in JBoss Fuse 6.3 and will be removed in a future release of JBoss Fuse.
Camel LevelDB component is deprecated on all operating systems except for Linux
Since JBoss Fuse 6.3, the Camel LevelDB (
camel-leveldb
) component is deprecated on all operating systems except for Red Hat Enterprise Linux. In future, the Camel LevelDB component will be supported only on Red Hat Enterprise Linux.
Tanuki based wrapper for installing JBoss Fuse as a service is deprecated
The Tanuki based wrapper scripts—generated using the
wrapper:install
Karaf console command—for installing JBoss Fuse as a service are deprecated since JBoss Fuse 6.3 and will be removed in a future release of JBoss Fuse. To install the Apache Karaf container as a service, it is recommended that you use the new karaf-service-*.sh
scripts from the bin/contrib
directory instead.
Smooks is deprecated
Since JBoss Fuse 6.3, the Smooks component for SwitchYard is deprecated and will be removed in a future release of JBoss Fuse.
BPEL is deprecated
BPEL (based on the Riftsaw project) is no longer being actively developed and will be removed from a future release of JBoss Fuse. If you are currently using BPEL, it is recommended that you consider migrating to the Red Hat JBoss BPM Suite (which is supported through the JBoss Fuse Integration Package).
Design Time Governance is deprecated
The Design Time Governance component is deprecated since 6.2.1 and not included with the product.
Runtime Governance is deprecated.
Since JBoss Fuse 6.3, the Runtime Governance (RTGov) component is deprecated and will be removed in a future release of JBoss Fuse.
S-RAMP is deprecated
The SOA Repository Artifact Model and Protocol (S-RAMP) component is deprecated since 6.2.1 and will be removed from a future release.
bin/patch script is deprecated
The
bin/patch
script (bin\patch.bat
on Windows O/S) is deprecated and will be removed in a future release.
Spring Dynamic Modules (Spring-DM) is deprecated
Spring-DM (which integrates Spring XML with the OSGi service layer) is deprecated since 6.2.1 and you should use the Blueprint framework instead. Using Blueprint does not prevent you from using the Java libraries from the Spring framework: the latest version of Spring is compatible with Blueprint.
Apache OpenJPA is deprecated
The Apache OpenJPA implementation of the Java Persistence API (JPA) is deprecated since 6.2.1. It is recommended that you use the Hibernate implementation instead.
Chapter 3. Migration Paths for JBoss Fuse 6.3
Migration Path for JBoss Fuse 6.3 on Karaf
There is no automated migration path for JBoss Fuse 6.3. A new installation must be performed, with configuration and other modified files copied across manually.
Migration Path for JBoss Fuse 6.3 on EAP
There is no automated migration path to JBoss Fuse 6.3 on EAP from previous version of JBoss Fuse on EAP. To migrate to JBoss Fuse 6.3 you will need to make a new installation of JBoss Fuse 6.3 on JBoss EAP. After a successful installation, any existing deployments will need to be re-deployed to the new system. For installation information please see Installation on JBoss EAP and for deployment information see Deployment in the Management Console.
Chapter 4. Migrate Fabric
Introduction
Migrating Fabric from JBoss Fuse 6.2 to JBoss Fuse 6.3 is a manual process.
Multiple Fabrics on a host
As part of migrating to a new JBoss Fuse release, you might want to set up multiple fabrics on the same host. This is useful when you cannot (or are not ready to) directly upgrade an existing fabric.
If you are going to have multiple fabrics on the same host then you must ensure that there are no port clashes and that the two fabrics are completely separate. To do this, specify the following options when you create a new fabric on a host where a fabric already exists:
fabric:create --min-port startPortRange --max-port endPortRange --zookeeper-server-port zookeeperServerPort
Ensure that the port range for the new fabric is outside the port range used by the existing fabric. You must also ensure that the port range for the new fabric does not include any default ports used by other installed applications.
After migration is complete, shut down the older fabric environment. The recommendation is to run one fabric environment on a host except when more than one is required for migration.
Migrate the Fabric configuration from JBoss Fuse 6.2 to JBoss Fuse 6.3
To migrate a Fabric configuration, extract the configuration files from the source instance, then add them to the destination instance. The profile files in both instances are held in a git repository at
FUSE_HOME/data/git/local/fabric
and the following rules apply:
- Each profile version is a git branch
- Each profile is a directory in the git working copy of particular version.
Use the git commands shown below to migrate the Fabric configuration data from JBoss Fuse 6.2 to JBoss Fuse 6.3.
- Ensure that both JBoss Fuse 6.2 and JBoss Fuse 6.3 are stopped.
- Clone both git repositories:
git clone FUSE62_HOME/data/git/local/fabric/.git fuse62-repo
which will result in a directory calledfuse62-repo
git clone FUSE63_HOME/data/git/local/fabric/.git fuse63-repo
which will result in a directory calledfuse63-repo
- Checkout a working branch in each repository:
cd fuse62-repo
git checkout fuse62-working-branch-name
cd fuse63-repo
git checkout fuse63-working-branch-name
- Compare the contents of the directory structures. You can use whatever method you choose to compare the structures and merge or copy files from the JBoss Fuse 6.2 file structure to the equivalent place in the JBoss Fuse 6.3 git repository.
- When the files have been added to the JBoss Fuse 6.3 git repository, check in the working branch to apply your changes.
cd fuse63-repo
git add .
git commit -m 'Migrating profiles from 6.2'
git push origin fuse63-working-branch-name
.
- Restart JBoss Fuse 6.2 and JBoss Fuse 6.3.
Chapter 5. Migrate Maven Projects
Overview
JBoss Fuse has a JBoss Fuse BOM (Bill of Materials), which defines the versions of all the JBoss Fuse Maven artifacts. You can use the BOM to simplify migration of your Maven POM files. Instead of updating the
version
elements on each Maven dependency, all you need to do is to import the latest JBoss Fuse BOM, which defines default versions for all of the dependencies provided by JBoss Fuse.
JBoss Fuse BOM
The JBoss Fuse BOM is a parent POM that defines the versions for all of the Maven artifacts provided by JBoss Fuse. The JBoss Fuse BOM exploits Maven's dependency management mechanism to specify default versions for the Maven artifacts, so that it is no longer necessary to specify the artifact versions explicitly in your POM.
Current version of the JBoss Fuse BOM
The easiest way to discover the current version of the JBoss Fuse BOM is to examine one of the sample
pom.xml
files from the quickstarts
examples. For example, in the InstallDir/quickstarts/eip/pom.xml
file, you can find a line that defines the JBoss Fuse BOM version, as follows:
<project ...> ... <properties> ... <!-- the version of the JBoss Fuse BOM, defining all the dependency versions --> <jboss.fuse.bom.version>6.3.0.redhat-xxx</jboss.fuse.bom.version> </properties> ... </project>
How to migrate Maven dependencies using the JBoss Fuse BOM
To migrate Maven dependencies using the JBoss Fuse BOM, open the Maven
pom.xml
file for your project and edit it as follows:
- Define the JBoss Fuse BOM version as a property in your
pom.xml
file, using the current BOM version. For example:<project ...> ... <properties> ... <jboss.fuse.bom.version>6.3.0.redhat-xxx</jboss.fuse.bom.version> </properties> ... </project>
- Reference the JBoss Fuse BOM parent POM in a
dependencyManagement
element, so that it defines default versions for the artifacts provided by JBoss Fuse. Add the followingdependencyManagement
element to yourpom.xml
file:<project ...> ... <dependencyManagement> <dependencies> <dependency> <groupId>org.jboss.fuse.bom</groupId> <artifactId>jboss-fuse-parent</artifactId> <version>${jboss.fuse.bom.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> ... </project>
- Now delete all of the
version
elements in your JBoss Fuse dependencies. All of the versions defined in the JBoss Fuse BOM will be applied automatically to your dependencies (through the Maven dependency management mechanism). For example, if you already had some Apache Camel dependencies, as follows:<dependencies> <dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-core</artifactId> <version>2.17.0.redhat-630xxx</version> </dependency> <dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-blueprint</artifactId> <version>2.17.0.redhat-630xxx</version> </dependency> <dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-jetty</artifactId> <version>2.17.0.redhat-630xxx</version> </dependency> ... </dependencies>
You would delete the version elements, so that the dependencies are specified as follows:<dependencies> <dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-core</artifactId> </dependency> <dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-blueprint</artifactId> </dependency> <dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-jetty</artifactId> </dependency> ... </dependencies>
- In future, when you migrate to a later version of JBoss Fuse, all that you need to do to upgrade your
pom.xml
file is to edit thejboss.fuse.bom.version
property, so that it references the new version of the JBoss Fuse BOM.
Chapter 6. Migrate Data Store
Overview
JBoss Fuse on Apache Karaf uses a KahaDB data store. There is an automatic migration facility that enables the KahaDB data store to be migrated to the new JBoss Fuse version.
The Aries transaction module must be installed and enabled before it can be used. See Fuse Transaction Guide for more details. Ignore the Aries transaction files instructions below if you do not have Aries installed.
Migrate the KahaDB Data Store
Note
When migrating or patching JBoss Fuse, always back up the KahaDB files and Aries transaction files.
- Backup the KhahaDB files and Aries transaction files from the old container. The files can be found at:
- KahaDB files -
InstallDir/data/amq/kahadb/*.*
- Aries transaction files -
InstallDir/data/txlog/*.*
- Manually copy all of the KahaDB files from the old container to the same location in the new container.
- Manually copy all Aries transaction log files from the same location in the sold container to the new container.
Auto-migration will take place when the new container is started.
Chapter 7. Camel Migration Issues
Camel 2.17 Migration Issues for JBoss Fuse 6.3
JBoss Fuse 6.3 uses Camel 2.17. There are a number of changes in Camel 2.17 that have to be considered before upgrading to JBoss Fuse 6.3.
As part of the Camel CDI component refactoring:
- The
@ContextName
qualifier no longer has a default empty value. - The
CdiPropertiesComponent
class has been removed, the standardPropertiesComponent
can be used instead
There are changes to Camel 2.17 that must be considered before upgrading:
- Removed camel-hbase as Karaf feature as it did not work well in OSGi
- The Kafka component has been migrated to use the Java Kafka client instead of Scala. A consequence of this is that there may be migration efforts or code changes required when upgrading.
- Fixed using statement.xxx options on the JDBC consumer would only be used in first poll.
- Fixed HTTP and HTTP4 to keep trailing slash if provided in uri when calling remote HTTP service.
- Fixed
OnCompletion
to keep any caught exception stored as property on the Exchange which allows to access that information to know if there was an exception during routing. - Fixed an issue with Bean component or Simple language with OGNL method call, would pick method with java.lang.Object type over a better suited method, when the method is overloaded.
- When installing the camel feature in Apache Karaf, camel-spring is no longer installed by default. You need to install the camel-spring feature if you are using spring-dm on Karaf.
- Removed camel-docker from karaf features as it does not work in OSGi
- Some changes have been made in Rest DSL to adjust naming and types to the Swagger Spec 2.0
- Any custom component that supports suspension in doSuspend/doResume should implement the new
Suspendable
marker interface, so Camel knows there is custom logic for suspension in the component. - Exchange and Message only output id in their toString method to avoid outputting any message details such as sensitive details from message bodies.
- Upgraded camel-hbase to Hadoop 2.x and HBase 1.1.x
- camel-mustache requires Java 8.
- camel-jetty8 is deprecated and being removed in next release.
- Moved some Camel tooling related dependencies (such as maven/plexus) from the Camel Parent BOM to the tooling BOM (to have them separated).
- camel-amqp does not support 0.9 anymore.
- camel-spring-integration feature has been removed from the Camel karaf.
- The Mail component now requires to configure to, cc, and bcc using lower case keys, eg to=foo@bar.com, instead of To=foo@bar.com as previously.
- The File consumer no longer probe the file content by default. See the option probeContentType for more details.
- If using Bean or Class component and specifying additional parameters in the endpoint uri to configure on the bean, then these options should now be prefixed with bean., eg foo=123 is now bean.foo=123.
- The Twitter delay option is changed from seconds to milli seconds by default, eg 10 should be 10000 to indicate 10 seconds. This is aligned how other components with delay option behaves.
- The options
attributeNames
andmessageAttributeNames
on AWS-SQS is changed to a string type where you can separate multiple values using comma. Before the type was a Collection which was much harder to configure in the Camel uris. - Rest DSL is exposing the REST services using all local IP address (eg 0.0.0.0) by default, instead of the local IP address of the host.
- The hbase component now require row mapping from the endpoint uri to be prefixed with row. as prefix.Before:
family=info&qualifier=firstName&family2=birthdate&qualifier2=year.
After:row.family=info&row.qualifier=firstName&row.family2=birthdate&row.qualifier2=year.
- As part of the Camel CDI component refactoring,
DeltaSpike
is not used anymore for the sourcing of the configuration properties. This new version of the component is agnostic to any configuration sourcing mechanism and delegates that concern the application so that it can declare a customPropertiesComponent
bean whose sourcing is tailored to its need.DeltaSpike
can still be used by the application by declaring aPropertiesComponent
bean configured with aPropertiesParser
relying on DeltaSpike. See the camel-example-cdi-properties example for more details. - The Kafka component has been migrated to use the Java Kafka client instead of Scala. As such there may be migration efforts or code changes that can affect users upgrading.
- Improved Rest DSL when CORS enabled to process and return the configured CORS headers in the rest-dsl in all the supported Rest DSL components.
- The options verb in the Rest DSL has been deprecated and are not in use if CORS is enabled.
- You can set XStream's type permissions to automatically allow or deny the instantiation of certain types. The default type permissions setting used by Camel only allows types from java.lang and java.util packages. This setting can be changed by setting System property org.apache.camel.xstream.permissions. Its value is a string of comma-separated types. Allowed types are prefixed with '+', which is the default and can be omitted. Denied types are prefixed with '-'. Each type in the list may contain a wildcard character, '*'.For example,
"-*,java.lang.*,java.util.*"
indicates that all types except for java.lang.* and java.util.* classes are denied. If you set this value to an empty string,""
, control is reverted to XStream's default type permissions handling.The type permissions setting can be extended at an individual XStream DataFormat instance by setting its type permissions property.<dataFormats> <xstream id="xstream-default" permissions="org.apache.camel.samples.xstream.*"/> ...
- camel-gae is deprecated and will be removed from Camel 2.18 onwards.
A known issue is that
camel-guice
cannot install in Apache Karaf.
Camel 2.16 Migration Issues for JBoss Fuse 6.3
There are also a number of updates to Camel 2.16 that may have an impact on upgrading to JBoss Fuse 6.3.
- The
dumpRoutesAsXml
operation now preserves the property placeholder used in the route models. setFaultBody
andsetFaultHeader
behave similarly tosetBody
orsetHeader
respectively, by preserving existing headers/attachments by setting on existing IN or OUT message.- If using concurrent consumer on JMS endpoints for request/reply over JMS then you must use the new
replyToConcurrentConsumers
,replyToMaxConcurrentConsumers
options to configure the values. - When the Aggregator2 is force completed the exchange property
Exchange.AGGREGATED_COMPLETED_BY
value has been changed fromforceCompletion
toforce
so its named like the other completion triggers. - Removed unsupported modules
camel-web
andcamel-web-standalone
. - Removed unsupported
camel:dot
functionality fromcamel:run
plugin. - Removed unsupported
camel-archetype-scala-component
from maven archetypes. - The Maven coordinate for linkedin and olingo2 components has been changed to have
groupId
as just org.apache.camel. - If using MongoDB component, the option
invokeGetLastError
has been removed. If this funcitonality is needed, use an acknowledged WriteConcern when executing the write operation and then verify the correctness of the operation with the methodwasAcknowledged()
of WriteResult. - The Jing component now uses
jing
as schema name in uris, instead ofrng
orrnc
.rng
orrnc
have been removed. - Swagger module now supports getting api-docs from multiple camel contexts in the JVM. The entry point at
/api-docs
now lists the contexts detected, and you need to append the context id in the path, eg/api-docs/myCamel
- If using <contextScan> with Spring or Blueprint to filter RouteBuilder classes, then Camel will now by default only look for singleton beans. You can turn on the old behavior to include prototype scoped with the new option
includeNonSingletons
. - camel-vertx has been upgraded to vertx 3.0 which requires Java 8 at runtime.
- camel-cdi is now using CDI 1.1 api - support for 1.0 has been dropped.
- Content Enricher with enrich and pollEnrich now supports dynamic endpoint uris. Dynamic endpoint uris are computed using an expression that allows the use of values from the current Exchange. The Java DSL stays backwards compatible.
- WireTap now supports dynamic endpoint uris. Dynamic endpoint uris are computed using an expression that allows the use of values from the current Exchange. The Java DSL stays backwards compatible. The Java DSL stays backwards compatible.
- If you have explicitly configured the JMX statistics level to
All
then that option is now calledDefault
. - The HTTP based consumers no longer include Camel headers in the responses by default.
- Bindy is requires to be configured using class names instead of package names, as it now supports having multiple model classes in the same java packages.
- Using CamelProxy now binds the method parameters to the message body/header using Camel annotations to define the binding rules. If no annotations are defined, the parameter is assumed to be the message body. You can turn this off to have the old behavior.
- SJMS component has been aligned to bind between Camel Messages and JMS Messages in the same way as the JMS component does. This has caused some APIs and behavior to change.
DefaultExchangeHolder
now only keeps primitive/String type headers/exchange properties (like JMS component) and filter out other types such as java instances (caught exception on exchange property is kept as well).- The Scala based Swagger (camel-swagger) is deprecated in favor of the new
camel-swagger-java
component. - The Camel Proxy (
camel-proxy
) component enables parameter binding by default from Camel 2.16 onwards. Existing code must either be changed to use parameter binding, or else you can explicitly disable parameter binding by callingbinding(false)
on theProxyBuilder
. For example:MyAuditService service = new ProxyBuilder(context).endpoint("jms:queue:foo").binding(false).build(MyAuditService.class); service.auditMessage("1234", "Hello World");
Apache Camel 2.16 API Breaking Changes
org.apache.camel.mode.LoadBalancerDefinition
no longer implementsorg.apache.camel.processor.loadbalancer.LoadBalancer
which is the runtime processor (this was never intended).- The ref attribute on <loadBalance> has been removed, as it has been deprecated for a long time.You should use a <customLoadBalancer> to refer to a custom load balancer.
- The copy method on
StreamCache
now takes an Exchange as parameter. - Various APIs in camel-jms has been adjusted to support including the JMS session parameter -
javax.jms.Session
. These API changes are mostly internal facing and are not expected to affect end users. - The
resourceUri
andresourceRef
attributes on<enrich>
and<pollEnrich>
have been removed as they now support a dynamic URIs computed from an Expression. - Various APIs from
camel-http
in the packageorg.apache.camel.component.http
have been moved to thecamel-http-common
module in the packageorg.apache.camel.http.common
, which means that you may need to change the imports. - Renamed All
enum
onorg.apache.camel.ManagementStatisticsLevel
toDefault
. - Added new boolean parameter to method on
org.apache.camel.spi.ShutdownPrepared
- Added
configure
method to allow configuring CamelContext onorg.apache.camel.main.MainListener
. - Renamed
org.apache.camel.component.sjms.jms.KeyFormatStrategy
toorg.apache.camel.component.sjms.jms.JmsKeyFormatStrategy
Chapter 8. Apache CXF Issues
8.1. Apache CXF 3.1 Migration
Overview
JBoss Fuse 6.3 uses Apache CXF 3.1. This introduces some issues that you sould be aware of before migrating.
Main Changes
- CXF 3.1 no longer supports Java 6. You must use Java 7 or Java 8.
- The JAX-WS/Simple frontend
ServerFactoryBean
will automatically callreset()
at the end of thecreate()
call. This allows resources to be cleaned up and garbage collected sooner. However, it also prevents multiple calls tocreate()
from sharing the sameServerInfo
/EndpointInfo
objects, as they would in older versions. That sharing has caused many problems in the past due to sharing of properties, such as token caches, that are stored on those objects. The new behavior is more correct, but it is different from previous versions so care must be taken when upgrading. - The Karaf
features.xml
file for CXF 3.1 no longer installs spring or spring-dm when installing thecxf
feature. If you require spring/spring-dm, you must install those features prior to installing the CXF feature. - Starting with CXF 3.1.2, the default
JSONProvider
class provided bycxf-rt-rs-extension-providers
has preference over registered JSON provider classes. This changes the sorting order for selecting the JSON provider class and can cause an incorrect JSON provider class to be used. To suppress the new default provider, set theskip.default.json.provider.registration
property totrue
on the CXF bus.Before CXF 3.1.2, if acustomMessageBodyReader
orMessageBodyWriter
object matches the read or write selection criteria for a registered JSON provider then default providers were not checked. For example, default providers were not checked if aMessageBodyWriter
object'sConsumes
field matched the content type andMessageBodyWriter.isReadable()
method returned true.With CXF 3.1.2, custom providers are selected only if no higher priority matching default provider is available. CXF 3.1.2 sorts thecustomMessageBodyReader
,MessageBodyWriter
andExceptionMapper
providers together with default providers. For example, consider a customStringReader
object that is not typed byString
but byObject
. The CXF 3.1.2 default provider, which is typed byString
, has a higher precedence. To ensure that a customString
provider has precedence, you would have to type theStringReader
byString
.To prevent registration of default JSON providers and to ensure correct selection of a JSON provider, set theskip.default.json.provider.registration property
totrue
, for example:<core:bus bus="myBus"> <core:properties> <entry key="skip.default.json.provider.registration" value="true"/> </core:properties> </core:bus> <cxf:rsServer id="myId" address="${address}"/> <serviceClass="com.redhat.VehicleDetailsLookupService" bus="CxfBus"> <cxf:providers> <bean id="jacksonJaxbJsonProvider" class="com.fasterxml.jackson.jaxrs.json.JacksonJaxbJsonProvider"/> </cxf:providers> </cxf:rsServer>
Security changes
- The STS (Security Token Service) now issues tokens using the RSA-SHA256 signature algorithm by default, and the SHA-256 digest algorithm . Previously it used RSA-SHA1 and SHA-1 respectively.
- Some security configuration tags have been renamed from
ws-security.*
tosecurity.*
, as they are now shared with some of the JAX-RS stack. The old tags will continue to work as before however without any change. See the Security Configuration page for more information. - The SAML/XACML functionality previously available in the
cxf-rt-security
module is now in thecxf-rt-security-saml
module. - If you are explicitly specifying the SAML version in a SAML
CallbackHandler
, then this is changed in CXF 3.1 due to the migration to use OpenSAML 3.1. The version is now set on theSAMLCallback
using anorg.apache.wss4j.common.saml.bean.Version
class. Previously there was a dependency on OpenSAML'sSAMLVersion
class. - It is now possible to plug in custom
WS-SecurityPolicy
validators if you want to change the default validation logic for a particular policy.
New Features
- The CXF JAX-WS code generator has a new option,
seiSuper
, that can be used to specify additional super interfaces for the SEI. This makes the code nonportable to other JAX-WS containers. The primary use would be to addAutoCloseable
to the interface to allow use of the clients in Java7 try with resource blocks. - New metrics feature for collecting metrics about a CXF services. Codahale/DropWizard based collector included.
- New throttling feature for easily throttling CXF services. Sample included that uses the metrics component to help make the throttling decisions.
- New logging feature for more advanced logging than the logging available in
cxf-core
. - New metadata service for SAML SSO to allow you to publish SAML SSO metadata for your service provider.
- The
cxf
frontend to the JAX-WS code generator,-fe cxf
now generates code that is more Java7-friendly as the return type of thegetPort(...)
calls is a sub-interface of the SEI that also implementsAutoCloseable
,BindingProvider
, andClient
. Code that used to look like:(AddNumbersPortType port = service.getAddNumbersPort(); ((BindingProvider)port).getRequestContext() .put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, address); port.addNumbers3(-1, 2); ((Closeable)port).close();
can be replaced with:try (AddNumbersPortTypeProxy port = service.getAddNumbersPort()) { port.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, address); port.addNumbers3(-1, 2); }
Major Dependency Changes
- The Jetty based HTTP transport has been updated to support Jetty 9 as well as Jetty 8. However, support for Jetty 7 has been dropped.
- Due to the Jetty upgrade, support for running Jetty based endpoints in Karaf 2.3.x has been dropped.
- Support for using JAX-WS 2.1 based API jars has been removed. Java 7 (now required) includes JAX-WS 2.2 so this should not be an issue.
- WSS4J 2.1 is included, which in turn includes OpenSAML 3.0.
Legal Notice
Trademark Disclaimer
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Apache, ServiceMix, Camel, CXF, and ActiveMQ are trademarks of Apache Software Foundation. Any other names contained herein may be trademarks of their respective owners.