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">
