From commits-return-64924-archive-asf-public=cust-asf.ponee.io@camel.apache.org Fri Sep 7 09:31:33 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id A0983180672 for ; Fri, 7 Sep 2018 09:31:30 +0200 (CEST) Received: (qmail 92994 invoked by uid 500); 7 Sep 2018 07:31:29 -0000 Mailing-List: contact commits-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@camel.apache.org Delivered-To: mailing list commits@camel.apache.org Received: (qmail 92984 invoked by uid 99); 7 Sep 2018 07:31:29 -0000 Received: from Unknown (HELO svn01-us-west.apache.org) (209.188.14.144) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Sep 2018 07:31:29 +0000 Received: from svn01-us-west.apache.org (localhost [127.0.0.1]) by svn01-us-west.apache.org (ASF Mail Server at svn01-us-west.apache.org) with ESMTP id 90F4C3A008F for ; Fri, 7 Sep 2018 07:31:28 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: svn commit: r1034810 [1/3] - in /websites/production/camel/content: ./ 2015/10/14/ 2018/09/ 2018/09/07/ cache/ Date: Fri, 07 Sep 2018 07:31:27 -0000 To: commits@camel.apache.org From: buildbot@apache.org X-Mailer: svnmailer-1.0.9 Message-Id: <20180907073128.90F4C3A008F@svn01-us-west.apache.org> Author: buildbot Date: Fri Sep 7 07:31:26 2018 New Revision: 1034810 Log: Production update by buildbot for camel Added: websites/production/camel/content/2018/09/ websites/production/camel/content/2018/09/07/ websites/production/camel/content/2018/09/07/apache-camel-2221-released.html websites/production/camel/content/cache/main.pageCache (with props) Modified: websites/production/camel/content/2015/10/14/welcome-jean-baptiste-onofr-as-camel-pmc-member.html websites/production/camel/content/book-in-one-page.html websites/production/camel/content/book-tutorials.html websites/production/camel/content/camel-30-ideas.html websites/production/camel/content/download-archives.html websites/production/camel/content/how-can-i-get-the-source-code.html websites/production/camel/content/how-can-i-stop-a-route-from-a-route.html websites/production/camel/content/how-do-i-retrieve-the-thrown-exception-during-processing-an-exchange.html websites/production/camel/content/index.html websites/production/camel/content/news.html websites/production/camel/content/processorfactory.html websites/production/camel/content/security-advisories.html websites/production/camel/content/siteindex.html websites/production/camel/content/sitemap.html websites/production/camel/content/source.html websites/production/camel/content/spark-rest.html websites/production/camel/content/tutorial-osgi-camel-part1.html websites/production/camel/content/tutorial-osgi-camel-part2.html websites/production/camel/content/tutorial-osgi-camel-part2a.html websites/production/camel/content/tutorial-osgi-camel-part2b.html websites/production/camel/content/tutorial-osgi-camel-part2c.html Modified: websites/production/camel/content/2015/10/14/welcome-jean-baptiste-onofr-as-camel-pmc-member.html ============================================================================== --- websites/production/camel/content/2015/10/14/welcome-jean-baptiste-onofr-as-camel-pmc-member.html (original) +++ websites/production/camel/content/2015/10/14/welcome-jean-baptiste-onofr-as-camel-pmc-member.html Fri Sep 7 07:31:26 2018 @@ -38,7 +38,7 @@ - Apache Camel: Welcome Jean-Baptiste Onofré as Camel PMC member + Apache Camel: Welcome Jean-Baptiste Onofr? as Camel PMC member @@ -64,7 +64,7 @@
Added: websites/production/camel/content/2018/09/07/apache-camel-2221-released.html ============================================================================== --- websites/production/camel/content/2018/09/07/apache-camel-2221-released.html (added) +++ websites/production/camel/content/2018/09/07/apache-camel-2221-released.html Fri Sep 7 07:31:26 2018 @@ -0,0 +1,150 @@ + + + + + + + + + + + + + + + + + + + Apache Camel: Apache Camel 2.22.1 Released + + + +
+
+
+
+
+
+
+
+
+
+
+ + + +
+ + + + +
+ +
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
+ + + + + + + +
+

The Camel community announces the immediate availability of the new patch release Camel 2.22.1. This release contains 47 fixes applied in the past few weeks by the community on the Camel 2.22.x maintenance branch.

The artifacts are published and ready for you to download either from the Apache mirrors or from the Central Maven repository. For more details please take a look at the release notes.
Many thanks to all who made this release possible.

On behalf of the Camel PMC,
Gregor Zurowski

+
+ +
+ + +
+
+
+
+
+
+ +
+
+
+© 2004-2015 The Apache Software Foundation. +
+Apache Camel, Camel, Apache, the Apache feather logo, and the Apache Camel project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners. +
+Graphic Design By Hiram +
+ + + + + + + + Modified: websites/production/camel/content/book-in-one-page.html ============================================================================== --- websites/production/camel/content/book-in-one-page.html (original) +++ websites/production/camel/content/book-in-one-page.html Fri Sep 7 07:31:26 2018 @@ -4407,11 +4407,11 @@ So we completed the last piece in the pi

This example has been removed from Camel 2.9 onwards. Apache Axis 1.4 is a very old and unsupported framework. We encourage users to use CXF instead of Axis.

+/*]]>*/
+/*]]>*/
  • Tutorial using Axis 1.4 with Apache Camel
    • Prerequisites
    • Distribution
    • Introduction
    • Setting up the project to run Axis Added: websites/production/camel/content/cache/main.pageCache ============================================================================== Binary file - no diff available. Propchange: websites/production/camel/content/cache/main.pageCache ------------------------------------------------------------------------------ svn:mime-type = application/octet-stream Modified: websites/production/camel/content/camel-30-ideas.html ============================================================================== --- websites/production/camel/content/camel-30-ideas.html (original) +++ websites/production/camel/content/camel-30-ideas.html Fri Sep 7 07:31:26 2018 @@ -87,7 +87,7 @@ -

      Camel 3.0 Ideas

      WIP

       

      Camel is now almost 6 years old and its second revision camel-2.x is more than 4.5 years old already. Camel is extremely mature, used in production by a large number of organizations from small to large and even governments. We feel like we really hit the initial target of simplifying integration. Camel's middleware abstraction api and the eip based routing brought a lot of positive feedback from users.

      There is however more that could be done to simplify the work of integration developers who need new components (not shipped with camel for licensin g - copyleft of commercial - or other reasons) or new integration patterns or algorithms or even new tools. We learned a lot in the past years and benefited from a strong and continuously growing community. It's time to put what we learned to good use and re-engineer your favourite integration framework yet again.

      The middleware abstractions look pretty solid, and aside from some possible reshuffling we don't expect major changes. As a consequence, most of the components will retain the same general feel. The core will however be rearchitected to become even more pluggable and modular. We will however spare no effort to make a new Camel 3 be as backward compatible as possible and when not possible at least provide a painless migration path.

      This is a mindmap of ideas for improving Camel 3.0. Fell free to discuss this on the Camel Mailing Lists if you have other ideas or feedback.

      Tab le of contents

      +

      Camel 3.0 Ideas

      WIP

       

      Camel is now almost 6 years old and its second revision camel-2.x is more than 4.5 years old already. Camel is extremely mature, used in production by a large number of organizations from small to large and even governments. We feel like we really hit the initial target of simplifying integration. Camel's middleware abstraction api and the eip based routing brought a lot of positive feedback from users.

      There is however more that could be done to simplify the work of integration developers who need new components (not shipped with camel for licensin g - copyleft of commercial - or other reasons) or new integration patterns or algorithms or even new tools. We learned a lot in the past years and benefited from a strong and continuously growing community. It's time to put what we learned to good use and re-engineer your favourite integration framework yet again.

      The middleware abstractions look pretty solid, and aside from some possible reshuffling we don't expect major changes. As a consequence, most of the components will retain the same general feel. The core will however be rearchitected to become even more pluggable and modular. We will however spare no effort to make a new Camel 3 be as backward compatible as possible and when not possible at least provide a painless migration path.

      This is a mindmap of ideas for improving Camel 3.0. Fell free to discuss this on the Camel Mailing Lists if you have other ideas or feedback.

      Tab le of contents

      JDK support

      (+1: claus, cmueller, mattrpav)
      (-1: hadrian)

      We should drop support for JDK6, and require JDK7 as minimim version. eg build and compile the release with JDK7.
      We should aim to be compatible with JDK8.
      (hz) Why? Isn't OpenJDK 6 still supported by RedHat and very much in use? Even Oracle's Java 6 is still in use. Maybe some bundles would require JDK7+, buy why not keep things like the api for instance still supported with Java 6? A strong argument may sway my opinion, but for now, I fail to see the reason.

      (mattrpav) Consider JDK8 as the base. By the time Camel 3 is stable and ready for wide-spread use, the transitive deps will have caught up. A number of suggestions below target JDK8 features, and all would require an "add-on" approach to maintain JDK7 backward compat. 

      JDK8 Java DSL

      < p>It would be good to have a camel-java8-dsl component that offers a JDK8 DSL which uses all the nice new stuff from JDK8 with higher order functions, closures, et all.
      Though this may comes later in Camel 3.x when JDK8 is GA.
      At least stuff like Predicate, Expression, AggregationStrategy etc. are "functional interfaces" (containing only one method) and Java 8 applications can implement them using lambdas. That's only a start, but it doesn't require a specific DSL.

      Routing Core Re-engineering (raulk)

      The routing core of Camel 2.x is heavily based on a recursive call pattern, where Processors are responsible for calling the next one along the chain. This results in lengthy and meaningless stacktraces (difficult to make sense out of and debug for newcomers) and higher memory usage due to retention of local variables for a longer time than strictly needed.

      Moreover, Camel weaves a large number of "plumbing" processors along the way which should not really be processors because they form part of the very essence of the routing core, e.g. error handlers, stream caching interceptors, trace interceptors, async processor helpers, MDC, etc.

      The proposal is to shift towards an iterative model, by redesigning the logic of Camel routing. The suggested model is defined by these pillars:

      • A single class, or a limited set of them, contain the routing logic of Camel. Package name: org.apache.camel.core.routing. Central (abstract) class: RoutingCore. Concrete realisations could be: PipeliningRoutingCore, MulticastRoutingCore, depending on the fundamental routing pattern.
      • The RoutingCore iteratively calls the routing steps, one after another. The routing steps return their result to the RoutingCore, who is in charge of calling the next element subsequently. OUT and IN are bridged if necessary (PipeliningRoutingCore).
      • The Processor interface is crumbled up into its many specialisations, each of which represents a distinct concept of the Camel framework: RoutingDecider (EIPs should only take decisions about the routing, but not perform the routing itself, e.g. choice, filter, loop, throttle, etc.; see examples in subsection below.), Actions, ErrorHandler (already exists), Interceptor, etc.
      • The RoutingCore is responsible of all the "magic" now disseminated across a number of processors. Assisted by Helper classes.

      The goal of this idea isn't to zap off recursion altogether, just to consolidate the routing logic into a handful of cornerstone classes.

      Camel is no longer a baby and the framework concepts are well mature, thus they should be transferred to the API and avoid making everything a raw Processor.

      Converting some EIPs fr om "performers" to mere "deciders"

      • choice() => evaluates the predicates and returns the List of Processors or Endpoints to invoke.
      • filter() => same as choice(), but returning null if the filter doesn't match, to continue to the next routing step.
      • loop() => evaluates whether the looping control predicate still stands. If yes, it returns the processors to invoke, where the last is itself (to trigger the looping logic again); else, it returns null to continue to the next routing step.
      • throttle() => pauses accordingly and then returns the endpoint/processors to invoke.
      • ...

      Clearer Architecture of Camel Core

      Goals:

      • The camel components should know as little as possible about camel core
      • The classes needed to setup camel should be separate from the things needed at run time
      • Camel Core should be tiny as possible and only contain what really is core

      So why should this be important? Currently components depend on camel-core as a whole and there are no further rules which classes the components should use and which classes should be private to core. Even classes from the impl package are needed. So this means that any refactoring we do in camel core could affect all components. As camel is growing steadily this can become quite problematic.

      Split camel-core into multiple parts (hadrian)

      (+1: cmueller, hadrian, claus)

      Claus: Important to be 99+% backwards compatible with Camel 2.x.

      There are multiple benefits and less constraints. A separate api jar would allow the definition of a 'route container' which is currently one of the roles of the CamelContext. This allows primarily alternative implementations of camel for constrained environments (such as real time systems, for instance). Processors/Routes/Comp onents written against the api could be deployed on any camel implementation (as long as all necessary features are supported).

      • api
      • dsl/builder
      • impl
      • ...

      These should be structured in a way that these big building blocks do not have cyclic dependencies. Any other cycles can be ignored in this step.

      Allowed depdencies ( "->" means may use, may depend on):

      • * -> api
      • end user config code -> builder
      • builder -> impl

      Avoid shading google concurrent linked map in camel-core

      The shaded Google concurrent map should IMHO be pluggable, so people can run without this as default. And then people can install that google JAR on their classpath and Camel can pickup and use that. This JAR only helps in SMX/Karaf installations when having concurrent startup of many Camel apps. For regular users this does not bring any benef its to the table. This can help slim down the size of the camel-core JAR.

      We can either auto detect the google class, as people did in the past with JDK1.3/1.4 and the apache commons collection. eg using commons collection on JDK1.3 and not in JDK1.4 as it had that out of the box.

      Define scope and rules for camel-core packages (champion?)

      In extension to the previous paragraph each camel package should have a clear scope that defines what to put in the package and what not. There should be rules that define what dependencies are allowed for classes in a package. The minimum goal is to guarantee that by following the rules dependency cycles can not happen. Additionally the rules should minimize dependencies between packages to achieve loose coupling between packages and high coherence inside a package.

      More flexible routes at runtime (claus)

      (+1: hadrian)

      When routes is added in Camel 2.x architecture, global cross cutting concerns such as error handlers, interceptors, onCompletion etc. is applied when the route is added. We need to separate this and have those applied during routing. The Channel needs to do this and therefore it must be more dynamic than its currently is. And we need to enlist the various global cross cutting concerns by their xxxDefintions in the CamelContext, so we can access them at any time. This allows end users also much more easily to add/remove interceptors, error handlers and whatnot at runtime. And it makes it much easier to add routes generated from JAXB or other sources, as we don't need to prepare or anyhow mold the RouteDefinition given. See ticket CAMEL-3024 for some details.

      Fix routes with multiple inputs (claus)

      The current implementation of routes with multiple inputs is to clone the route, which means you essentially got 2+ routes if a route has multiple inputs. However routes with multiple inputs is seldom used. The actual solution will depend on the api refactoring.

      Route initialization logic for Java DSL and XML DSLs (claus)

      The Java DSL does its route initialization slightly a bit different than the XML DSLs, due the nature of it, and the fact the fluent builders can do additional logic, which the JAXB model of XML DSLs does not. We should align the initialization logic so Java DSL and XML DSLs does the same thing. They setup the pure model at first. So the configure method in the RouteBuilder should setup the model as the XML DSL would do. Then the prepare route logic which follows could be the same in all cases. This would also allow us to ensure when people use multiple RouteBuilder classes in Java DSL, then context scoped onException, interceptors is applied for all RouteBuilders.

      Add OnException, Interceptor, etc. to JAXB model for a CamelContextDefinition (claus)

      Configuring context scoped onException, interceptors etc. is woven into the RouteDefinition as part of the route initialization logic. When we have a dynamic routing engine (see above) that can at runtime support this without the need for woven into the routes. Then we should also ensure the context scoped onException, interceptors etc. is available in a CamelContextDefinition. This ensures the models is always 100% kept as it was provided, and we can fully export the model to XML and other languages (having a supported render).

      Tighten up route definitions (claus)

      Currently cr oss cutting concerns such as error handlers, interceptors, onCompletion etc. can be define anywhere in the route. We should tighten this up and only allow this to be configured in the start of the route. This also ensures when end users use code assistance in their route development, the IDE will not popup a big list which includes these cross cutting concerns. See also next note. (ProcessorDefinition will therefore be trimmed)

      Message History EIP/Message Store (Christian Ohr)

      This has been moved to its own Wiki page.

      Dependency Upgrades

      We should upgrade Jetty to 8.x as minimum. And if possible support Jetty 9.x which is in the works.
      Currently we are stuck on 7.x due CXF / Karaf etc uses that old version, and thus we have been good citizen to align and use same version.
      AMQ is also using older Jetty, but that is easier to upgrade as well.

      JMX naming

      (+1: cgeer)

      We should avoid using the hostname in the JMX MBeans as its better to have a consistent naming that tooling and other parties can rely on. Having the hostname in there just add complexity to the mix. Also Camel may quote the MBean name for the CamelContextMBean and use " " in the mbean name, as the only mbean in there. (will need to double check exactly which mbean it was).

      We should consider improve on this.

      Remove not used components

      We should consider removing

      • camel-bam
      • camel-msv
      • org.apache.camel.view from came-core
      • dot maven generator
      • ... (there could be other stuff to remove)

      The BAM has not changed in 5 years, and very seldom used by end users. And neither has the functionality you need. There is much better solutions outside ASF Camel for a BAM solution.
      The DOT generator is not up to date and maintained. Also it requires binary generator to generate a route diagram; we never managed to find a good java library for that.

      The MSV component is never/rarely used, and is causing some issues for cutting releases, due some weird maven issues / download of JARs etc. And the codebase has basically been left unchanged for 5+ years now.

      Split camel-cxf into WS and REST

      The camel-cxf component has grown too fat and has too many dependencies. People would like to use a light-weight RS. We have already talked on Camel @dev about splitting camel-cxf into a WS and RS modules. As well refactor the code-base as there is potential overlap with CXF itself and stuff to be removed/trimmed/optimized etc.

      We can have a camel-cfx-core where we can have shared logic if th at makes sense.

      Old ideas

      To be better defined and moved to the section above or removed

      Support for asynchronous transactions

      When using the asynchronous routing engine it would be desirable of transactional context could be propagated to the new threads.
      This requires the TX manager supports suspend/resume on the TX. G.Nodet have worked a bit on this. See CAMEL-2902. Also see CAMEL-2729.

      With the Asynchronous Routing Engine it would be great if we could support asynchronous transaction as well. See CAMEL-2729 and CAMEL-2902

      Stream caching

      We could add support for using HawtDB as the persistent store for streams which overflow to disk store.
      This might be implemented with the message store when it is used for stream caching.

      EIP

      The Resequencer EIP currently doesn't support persistence, we could introduce this and let it leverage HawtDB such as we did with the Aggregator2 EIP.
      This might be implemented with the message store when it is used for temporarily saving exchanes until they are in order.

      Schedule in DSL

      We could consider a dding DSL syntax sugar for scheduling routes. For example currently you have to use Quartz or a ScheduledPollingConsumer which has the delay option. We could add DSL which has something like:

      schedule().every(5).minute().pollFrom("xxx").to("yyyy")
      
      Modified: websites/production/camel/content/download-archives.html
      ==============================================================================
      --- websites/production/camel/content/download-archives.html (original)
      +++ websites/production/camel/content/download-archives.html Fri Sep  7 07:31:26 2018
      @@ -78,7 +78,7 @@
       	
               
               
      -

      Download archives

      You can use the Apache Archives to download all the Camel releases.

      Downloading

      The links below contains the release notes for all the Camel release. However if you want to download the release, you must use the download archives, which is the two links above.

      All time Apache Camel releases notes:

      +

      Download archives

      You can use the Apache Archives to download all the Camel releases.

      Downloading

      The links below contains the release notes for all the Camel release. However if you want to download the release, you must use the download archives, which is the two links above.

      All time Apache Camel releases notes: