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>* -> api</li><li>end user config code -> builder</li><li>builder
-> 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 <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>
-
-<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">
