camel-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r848964 - in /websites/production/camel/content: cache/main.pageCache camel-30-ideas.html
Date Fri, 01 Feb 2013 21:19:01 GMT
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 &lt;redeliveryPolicy&gt;
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">



Mime
View raw message