Since we're on a major migration process of this website, some component documents here are out of sync right now. In the meantime you may want to look at the asciidoc in the repository: https://github.com/apache/camel/blob/master/README.md https://github.com/apache/camel/blob/master/components/readme.adoc
Available as of Camel 2.19
Several Camel components can use HTTP as the underlying transport protocol. In general HTTP calls are stateless in nature, however some servers allow to maintain state via cookies. Cookies are often used to maintain a server session (e.g. via a session cookie called "JSESSIONID" with servers implementing the JEE Servlet specification).
If a Camel route intends to implement some kind of HTTP session handling the scope of this session should be considered.
Independently from the session scope the implementation must honor the domain of
It might be desirable to have a single session for a route or a CamelContext. This essentially means that all calls to a server issued from a route or CamelContext share a single HTTP session.
It is also possible to have a session on an Endpoint entity. This would mean that all invocations of an HTTP call issued by a single Endpoint share a session, whereas different Endpoints never share sessions, even if the call is sent to the same server.
The third option to define a session scope is on Exchange level. This is particularly useful for scenarios where the server session is really maintaining state.
In this case the route could e.g. first do a login call, then some update calls and finally a logout call. If the session handling would be defined on route or CamelContext scopes this would seem to run, however under load parallel invocations of the route would share a single session, which could cause issues. If the session is defined on exchange scope, each invocation of the route will get a separate session and the server can maintain a separate state for the different parallel invocations.
If you are a Camel user, you see that several Camel components support the cookieHandler parameter on endpoint level. All you need to do is to instantiate a cookie handler appropriate for your use case and reference it in the cookieHandler parameter for all endpoints that are supposed to participate in the HTTP session.
There are two pre-implemented cookie handlers:
The following three routes will each do two invocations of an echo REST service. In the first route (without a cookie handler) each invocation will get a new session. For the second route all invocations will share a session. For the third route the first and the second invocation within the route share a session, but different (even parallel) invocations of the route will not share a session.
If you want to develop a HTTP based component that is supposed to participate in a session you have to add the following parts to your code:
Some APIs provide more direct support for cookie handling. In this case it might be easier to get the underlying