You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by bu...@apache.org on 2013/02/07 11:18:17 UTC
svn commit: r849701 - in /websites/production/camel/content:
cache/main.pageCache camel-30-ideas.html
Author: buildbot
Date: Thu Feb 7 10:18:17 2013
New Revision: 849701
Log:
Production update by buildbot for camel
Modified:
websites/production/camel/content/cache/main.pageCache
websites/production/camel/content/camel-30-ideas.html
Modified: websites/production/camel/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.
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 Thu Feb 7 10:18:17 2013
@@ -90,6 +90,8 @@
<h3><a shape="rect" name="Camel3.0-Ideas-JDKsupport"></a>JDK support</h3>
+<p>(+1: claus)</p>
+
<p>We should drop support for JDK6, and require JDK7 as minimim version. eg build and compile the release with JDK7.<br clear="none">
We should aim to be compatible with JDK8.</p>
@@ -112,7 +114,9 @@ At least stuff like Predicate, Expressio
<h4><a shape="rect" name="Camel3.0-Ideas-Splitcamelcoreintomultipleparts%28hadrian%29"></a>Split camel-core into multiple parts (hadrian)</h4>
-<p>(+1: cmueller, hadrian)</p>
+<p>(+1: cmueller, hadrian, claus)</p>
+
+<p>Claus: Important to be 99+% backwards compatible with Camel 2.x.</p>
<p>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/Components written against the api could be deployed on any camel implementation (as long as all necessary features are supported).</p>
@@ -126,6 +130,13 @@ At least stuff like Predicate, Expressio
<ul><li>* -> api</li><li>end user config code -> builder</li><li>builder -> impl</li></ul>
+<h4><a shape="rect" name="Camel3.0-Ideas-Avoidshadinggoogleconcurrentlinkedmapincamelcore"></a>Avoid shading google concurrent linked map in camel-core</h4>
+
+<p>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 benefits to the table. This can help slim down the size of the camel-core JAR.</p>
+
+<p>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.</p>
+
+
<h4><a shape="rect" name="Camel3.0-Ideas-Definescopeandrulesforcamelcorepackages%28champion%3F%29"></a>Define scope and rules for camel-core packages (<em>champion</em>?)</h4>
<p>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.</p>
@@ -153,12 +164,20 @@ At least stuff like Predicate, Expressio
<h4><a shape="rect" name="Camel3.0-Ideas-MessageHistoryEIP%2FMessageStore%28ChristianOhr%29"></a>Message History EIP/Message Store (Christian Ohr)</h4>
-<p>(+1: hadrian)<br clear="none">
+<p>(+1: hadrian, claus)<br clear="none">
We should make this EIP easier to use for end users, but offering a better public API. And also have a pluggable message store, with filters that can filter what should be stored. As well pluggable marshallers so people can marshal data from Exchange into a format the message store can store (BLOB, XML, JSon etc.).<br clear="none">
A Message Store could provide transparent persistence to various EIP patterns (or used directly). Implementations would handle the mapping to the underlying database or file system or NoSQL or memory or whatever.<br clear="none">
Message Store implementations are already there in various places, using different approaches, like in Stream Caching (only file system), AggregationRepository or IdempotentRepository. A Message Store is requested for in other places like Reliable stream resequencing (CAMEL-949) or Persistent Dead Letter Queue (CAMEL-4575). And there might be other areas (seda, bam) that might benefit as well.</p>
+<h4><a shape="rect" name="Camel3.0-Ideas-DependencyUpgrades"></a>Dependency Upgrades</h4>
+
+<p>We should upgrade Jetty to 8.x as minimum. And if possible support Jetty 9.x which is in the works.<br clear="none">
+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.<br clear="none">
+AMQ is also using older Jetty, but that is easier to upgrade as well.</p>
+
+
+
<h4><a shape="rect" name="Camel3.0-Ideas-Removenotusedcomponents"></a>Remove not used components</h4>
<p>We should consider removing</p>
@@ -242,7 +261,8 @@ And then we should use it in <tt>camel-i
<h4><a shape="rect" name="Camel3.0-Ideas-OSGienhancements"></a>OSGi enhancements</h4>
-<ul><li>create a single type converter registry available as OSGi service to all bundles serving as a single registry to lookup converters or to add/remove converters from custom bundles</li></ul>
+<ul><li>create a single type converter registry available as OSGi service to all bundles serving as a single registry to lookup converters or to add/remove converters from custom bundles.</li></ul>
+
<h4><a shape="rect" name="Camel3.0-Ideas-Easiercommit%2Frollbackforcomponentdevelopers"></a>Easier commit/rollback for component developers</h4>
@@ -301,8 +321,7 @@ It may make more sense to move onRedeliv
<h4><a shape="rect" name="Camel3.0-Ideas-AddcompositeEIPtocomposeanumberofEIPsintoasingleEIP"></a>Add composite EIP to compose a number of EIPs into a single EIP</h4>
-<p>It would be nice if we have a DSL to compose a number of child EIPs into a single EIP itself. eg a bit like <pipeline>. This would allow people to make it easier to group together a number of EIPs into a single "unit". This allows for example the error handler to redeliver to the composite EIP instead of at the point of failure within the group. There are use-cases where people want to do that. And today the solution is to split this into a new route, which you then disable error handler by setting it to no error handler. And then call the route using the direct endpoint. So instead if you could do <composite> ... stuff goes here </composite> then that would be neater, as you dont have to split into multiple routes. I think there is an old JIRA ticket created about this a long time ago.</p>
-</div>
+<p>It would be nice if we have a DSL to compose a number of child EIPs into a single EIP itself. eg a bit like <pipeline>. This would allow people to make it easier to group together a number of EIPs into a single "unit". This allows for example the error handler to redeliver to the composite EIP instead of at the point of failure within the group. There are use-cases where people want to do that. And today the solution is to split this into a new route, which you then disable error handler by setting it to no error handler. And then call the route using the direct endpoint. So instead if you could do <composite> ... stuff goes here </composite> then that would be neater, as you dont have to split into multiple routes. I think there is an old JIRA ticket created about this a long time ago.</p></div>
</td>
<td valign="top">
<div class="navigation">