camel-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r849016 - in /websites/production/camel/content: cache/main.pageCache camel-30-ideas.html
Date Sat, 02 Feb 2013 01:19:10 GMT
Author: buildbot
Date: Sat Feb  2 01:19:10 2013
New Revision: 849016

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 Sat Feb  2 01:19:10 2013
@@ -96,21 +96,12 @@
 
 <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%28jwcarman%29"></a>Improve
the test api for testing components (jwcarman)</h4>
 
+<h4><a shape="rect" name="Camel3.0-Ideas-Splitcamelcoreintomultipleparts%28hadrian%29"></a>Split
camel-core into multiple parts (hadrian)</h4>
 
-<h5><a shape="rect" name="Camel3.0-Ideas-Endorsements"></a>Endorsements</h5>
+<p>(+1: cmueller, hadrian)</p>
 
-<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>
+<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>
 
 <ul><li>api</li><li>dsl/builder</li><li>impl</li><li>...</li></ul>
 
@@ -122,17 +113,29 @@
 <ul><li>* -&gt; api</li><li>end user config code -&gt; builder</li><li>builder
-&gt; impl</li></ul>
 
 
-<h4><a shape="rect" name="Camel3.0-Ideas-Definescopeandrulesforcamelcorepackages"></a>Define
scope and rules for camel-core packages</h4>
+<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>
 
-<h4><a shape="rect" name="Camel3.0-Ideas-Routingengineoptimization"></a>Routing
engine optimization</h4>
+<h4><a shape="rect" name="Camel3.0-Ideas-Moreflexibleroutesatruntime%28champion%3F%29"></a>More
flexible routes at runtime (<em>champion</em>?)</h4>
+<p>(+1: hadrian)</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>
 
-<p>The internal routing engine should be optimized. See more details at <a shape="rect"
href="camel-2x-speed-optimizations.html" title="Camel 2.x Speed optimizations">Camel 2.x
Speed optimizations</a>.</p>
+<h4><a shape="rect" name="Camel3.0-Ideas-Fixrouteswithmultipleinputs%28champion%3F%29"></a>Fix
routes with multiple inputs (<em>champion</em>?)</h4>
 
-<h3><a shape="rect" name="Camel3.0-Ideas-Moreflexibleroutesatruntime"></a>More
flexible routes at runtime</h3>
+<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 actual solution will depend on the api refactoring.</p>
+
+<h4><a shape="rect" name="Camel3.0-Ideas-MessageHistoryEIP%2FMessageStore%28ChristianOhr%3F%29"></a>Message
History EIP/Message Store (Christian Ohr?)</h4>
+
+<p>(+1: hadrian)<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>
 
-<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>
+
+<h3><a shape="rect" name="Camel3.0-Ideas-Oldideas"></a>Old ideas</h3>
+<p><em>To be better defined and moved to the section above or removed</em></p>
 
 <h4><a shape="rect" name="Camel3.0-Ideas-RouteinitializationlogicforJavaDSLandXMLDSLs"></a>Route
initialization logic for Java DSL and XML DSLs</h4>
 
@@ -153,10 +156,6 @@ This requires the TX manager supports su
 
 <p>With the <a shape="rect" href="asynchronous-routing-engine.html" title="Asynchronous
Routing Engine">Asynchronous Routing Engine</a> it would be great if we could support
asynchronous transaction as well. See <a shape="rect" class="external-link" href="https://issues.apache.org/activemq/browse/CAMEL-2729">CAMEL-2729</a>
and <a shape="rect" class="external-link" href="https://issues.apache.org/activemq/browse/CAMEL-2902">CAMEL-2902</a></p>
 
-<h4><a shape="rect" name="Camel3.0-Ideas-Remove@deprecated"></a>Remove
@deprecated</h4>
-
-<p>@deprecated features, methods, etc. is to be removed.</p>
-
 <h4><a shape="rect" name="Camel3.0-Ideas-Streamcaching"></a>Stream caching</h4>
 
 <p>We could add support for using <a shape="rect" href="hawtdb.html" title="HawtDB">HawtDB</a>
as the persistent store for streams which overflow to disk store.</p>
@@ -170,7 +169,8 @@ 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,10 +178,6 @@ This requires the TX manager supports su
 
 <p>The DSL should support both cron and non cron based, eg <a shape="rect" href="quartz.html"
title="Quartz">Quartz</a>, <a shape="rect" href="spring.html" title="Spring">Spring</a>
(spring 3 has cron) and regular JDK timers.</p>
 
-<h4><a shape="rect" name="Camel3.0-Ideas-Fixrouteswithmultipleinputs"></a>Fix
routes with multiple inputs</h4>
-
-<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>
@@ -272,7 +268,8 @@ However this requires API changes and th
 <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>
@@ -281,7 +278,8 @@ However this requires API changes and th
 
 <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>
@@ -296,18 +294,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 &lt;pipeline&gt;. 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 &lt;composite&gt;
... stuff goes here &lt;/composite&gt; 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>
-
-<h4><a shape="rect" name="Camel3.0-Ideas-MessageHistoryEIP%2FMessageStore"></a>Message
History EIP/Message Store</h4>
-
-<p>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-Lightweightwebconsole"></a>Light-weight
web console</h4>
-
-<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>
+</div>
         </td>
         <td valign="top">
           <div class="navigation">



Mime
View raw message