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/01 22:19:01 UTC
svn commit: r848964 - in /websites/production/camel/content:
cache/main.pageCache camel-30-ideas.html
Author: buildbot
Date: Fri Feb 1 21:19:01 2013
New Revision: 848964
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 Fri Feb 1 21:19:01 2013
@@ -96,14 +96,20 @@
<p>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.</p>
-<h4><a shape="rect" name="Camel3.0-Ideas-Improvethetestapifortestingcomponents%28hadrian%29"></a>Improve the test api for testing components (hadrian)</h4>
+<h4><a shape="rect" name="Camel3.0-Ideas-Improvethetestapifortestingcomponents%28jwcarman%29"></a>Improve the test api for testing components (jwcarman)</h4>
+
+
<h5><a shape="rect" name="Camel3.0-Ideas-Endorsements"></a>Endorsements</h5>
+
<p>+1: cmueller</p>
<p>No matter what choices and changes we make in the core, many tests in components will start failing. That is because virtually all unit tests in components test much more than the component itself, by setting up routes, etc. A simple thing would be do create something like xyzTestSupport (where xyz in {"Component", "Configuration", "Endpoint", "Producer", "Consumer", "Language", etc... }), that test a respective area without setting up routes and possibly use a minimal CamelContext (w/o component discover and/or other features). Moving component unit tests to such a framework is not complicated, a bit tedious, but hopefully we'll benefit (yet again) from community contributions and gain new committers in the process. This is probably the first thing that should be done that will allow us to be more productive with the other improvements. It can also be done in 2.x and won't require any incompatible changes.</p>
<h4><a shape="rect" name="Camel3.0-Ideas-Splitcamelcoreintomultipleparts%28champion%3F%29"></a>Split camel-core into multiple parts (champion?)</h4>
+
+
<h5><a shape="rect" name="Camel3.0-Ideas-Endorsements"></a>Endorsements</h5>
+
<p>+1: cmueller</p>
<ul><li>api</li><li>dsl/builder</li><li>impl</li><li>...</li></ul>
@@ -126,7 +132,7 @@
<h3><a shape="rect" name="Camel3.0-Ideas-Moreflexibleroutesatruntime"></a>More flexible routes at runtime</h3>
-<p>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 <tt>Channel</tt> 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 <em>mold</em> the <tt>RouteDefinition</tt> given. See ticket <a shape="rect" class="external-link" href="https://issues.apache.org/activemq/browse/CAMEL-3024">CAMEL-3024</a> for some details. </p>
+<p>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 <tt>Channel</tt> 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 <em>mold</em> the <tt>RouteDefinition</tt> given. See ticket <a shape="rect" class="external-link" href="https://issues.apache.org/activemq/browse/CAMEL-3024">CAMEL-3024</a> for some details.</p>
<h4><a shape="rect" name="Camel3.0-Ideas-RouteinitializationlogicforJavaDSLandXMLDSLs"></a>Route initialization logic for Java DSL and XML DSLs</h4>
@@ -164,8 +170,7 @@ This requires the TX manager supports su
<p>We could consider adding DSL syntax sugar for scheduling routes. For example currently you have to use <a shape="rect" href="quartz.html" title="Quartz">Quartz</a> or a <tt>ScheduledPollingConsumer</tt> which has the <tt>delay</tt> option. We could add DSL which has something like:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-schedule().every(5).minute().pollFrom(<span class="code-quote">"xxx"</span>).to(<span class="code-quote">"yyyy"</span>)
+<pre class="code-java">schedule().every(5).minute().pollFrom(<span class="code-quote">"xxx"</span>).to(<span class="code-quote">"yyyy"</span>)
</pre>
</div></div>
@@ -178,6 +183,7 @@ schedule().every(5).minute().pollFrom(<s
<p>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 correct implementation is to only create one route but have multiple input consumers. This change will require a bit of change in current code as it relies on the <em>only 1 input consumer</em> on the route.</p>
<h3><a shape="rect" name="Camel3.0-Ideas-UptodateScalaDSL"></a>Up-to-date Scala DSL</h3>
+
<p><b>Done in Camel 2.11</b></p>
<p>The Scala DSL is slightly out of date as we have improved the DSL a bit here and there. We should check the gap and ensure the Scala is up-to-date.</p>
@@ -199,7 +205,7 @@ And also maybe annotations for <tt>Aggre
<h4><a shape="rect" name="Camel3.0-Ideas-SEDA%2FVMcomponentstoleverageasyncroutingengine"></a>SEDA/VM components to leverage async routing engine</h4>
-<p>This allows to use non blocking request-reply over <a shape="rect" href="seda.html" title="SEDA">SEDA</a> and <a shape="rect" href="vm.html" title="VM">VM</a>. The reason why we havent converted in 2.4 is it causes a bigger API breakage. </p>
+<p>This allows to use non blocking request-reply over <a shape="rect" href="seda.html" title="SEDA">SEDA</a> and <a shape="rect" href="vm.html" title="VM">VM</a>. The reason why we havent converted in 2.4 is it causes a bigger API breakage.</p>
<h4><a shape="rect" name="Camel3.0-Ideas-camelosgitest"></a>camel-osgi-test</h4>
@@ -207,14 +213,17 @@ And also maybe annotations for <tt>Aggre
And then we should use it in <tt>camel-itest-osgi</tt> of course. See <a shape="rect" class="external-link" href="https://issues.apache.org/jira/browse/CAMEL-3777">CAMEL-3777</a>.</p>
<h4><a shape="rect" name="Camel3.0-Ideas-REST"></a>REST</h4>
+
<p>We already have REST support with <a shape="rect" href="cxfrs.html" title="CXFRS">CXFRS</a> and <a shape="rect" href="restlet.html" title="Restlet">Restlet</a> but it can be better. We should make sure those components is dead easy to use and you can invoke REST services in one line of code etc. And we should make more examples and tidy up the <a shape="rect" href="cxfrs.html" title="CXFRS">CXFRS</a> documentation.</p>
<h4><a shape="rect" name="Camel3.0-Ideas-Moreloadtests%28cmueller%29"></a>More load tests (cmueller)</h4>
+
<p>More load tests for frequently used Camel components (jetty, jms ...) and camel-core. If we have an defined runtime environment which is in general accessable/available for all users (like a public image on Amazon EC2) and a data store for the performance numbers, than we could easily collect and share the numbers.</p>
<ul><li>Ensure correct behavior under load</li><li>Source for performance numbers (throughput etc).</li><li>Detection of memory leaks</li><li>Detection of performance decreases after refactorings</li><li>...</li></ul>
<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>
@@ -231,6 +240,7 @@ And then we should use it in <tt>camel-i
<p>In favor of the xxx option, we should remove the duplicated xxxRef options from our components. This make our code and documentation more lean. We should deprecate it as soon as possible and remove it in Camel 3.0.</p>
<h4><a shape="rect" name="Camel3.0-Ideas-LessSpringdependencies"></a>Less Spring dependencies</h4>
+
<p><b>DONE in Camel 2.9</b></p>
<p>In camel-core we use the Spring JMX annotations to more easily enlist our MBeans. We should move that logic to camel-spring. And introduce a Camel specific annotations to replace those. For example ActiveMQ does that. This allows us to use camel-core with JMX without any spring JARs at all. End users can still use the Spring JMX annotations in their custom code / components. They just need camel-spring on the classpath.</p>
@@ -240,6 +250,7 @@ And then we should use it in <tt>camel-i
<p>Then we are down to have Spring JAR dependency in: camel-jms and camel-mail.</p>
<h4><a shape="rect" name="Camel3.0-Ideas-IntroduceCamelJMXannotations"></a>Introduce Camel JMX annotations</h4>
+
<p><b>DONE in Camel 2.9</b></p>
<p>See above about less Spring dependency.</p>
@@ -254,15 +265,14 @@ However this requires API changes and th
<h4><a shape="rect" name="Camel3.0-Ideas-ImprovementstoThreadPoolProfileforthreadmanagement"></a>Improvements to ThreadPoolProfile for thread management</h4>
-<p>We could move <tt>ThreadPoolProfile</tt> from <tt>org.apache.camel.spi</tt> to <tt>org.apache.camel</tt> and have it in the root package. </p>
+<p>We could move <tt>ThreadPoolProfile</tt> from <tt>org.apache.camel.spi</tt> to <tt>org.apache.camel</tt> and have it in the root package.</p>
<h4><a shape="rect" name="Camel3.0-Ideas-TightenuponException"></a>Tighten up onException</h4>
<p>We should consider tighten up the onException DSL a bit, for example to make it more clear that if you have processing steps in there, they only occur after the message has been exhausted. So maybe we need to have a onExhausted to make this clear</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-onException(IOException.class).maximumRedeliveries(3)
+<pre class="code-java">onException(IOException.class).maximumRedeliveries(3)
.onExhausted().handled(<span class="code-keyword">true</span>).to(<span class="code-quote">"log:ignoreMe"</span>);
</pre>
</div></div>
@@ -271,8 +281,7 @@ onException(IOException.class).maximumRe
<p>Also currently you can do this:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-onException(IOException.class).maximumRedeliveries(3)
+<pre class="code-java">onException(IOException.class).maximumRedeliveries(3)
.handled(<span class="code-keyword">true</span>);
</pre>
</div></div>
@@ -282,7 +291,7 @@ We should in this case use a NoopProcess
However we have not changed this in Camel 2.x to keep backwards compatibility.</p>
<p>Likewise there has been ideas to move onRedeliverRef to <redeliveryPolicy> as currently its to be configured outside the policy.<br clear="none">
-It may make more sense to move onRedeliverRef to the policy to keep it together. </p>
+It may make more sense to move onRedeliverRef to the policy to keep it together.</p>
<h4><a shape="rect" name="Camel3.0-Ideas-AddcompositeEIPtocomposeanumberofEIPsintoasingleEIP"></a>Add composite EIP to compose a number of EIPs into a single EIP</h4>
@@ -298,8 +307,7 @@ Message Store implementations are alread
<p>A new lighter web-console that is using HTML5 technology instead of scalate or other heavier frameworks.<br clear="none">
And the console should support discovering all the Camel's in the JVM, so you don't have to co-bundle the web console with every Camel app.<br clear="none">
-This allows to install the web-console as a WAR or OSGi bundle in any container; having it find the Camel apps in the same JVM.</p>
-</div>
+This allows to install the web-console as a WAR or OSGi bundle in any container; having it find the Camel apps in the same JVM.</p></div>
</td>
<td valign="top">
<div class="navigation">