camel-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r849328 - in /websites/production/camel/content: cache/main.pageCache camel-30-ideas.html
Date Mon, 04 Feb 2013 12:18:52 GMT
Author: buildbot
Date: Mon Feb  4 12:18:52 2013
New Revision: 849328

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 Mon Feb  4 12:18:52 2013
@@ -88,6 +88,18 @@
 <p>This is a mindmap of ideas for improving Camel 3.0. Fell free to discuss this on
the Camel <a shape="rect" href="mailing-lists.html" title="Mailing Lists">Mailing Lists</a>
if you have other ideas or feedback.</p>
 
 
+<h3><a shape="rect" name="Camel3.0-Ideas-JDKsupport"></a>JDK support</h3>
+
+<p>We should drop support for JDK6, and require JDK7 as minimim version. eg build and
compile the release with JDK7.<br clear="none">
+We should aim to be compatible with JDK8.</p>
+
+
+<h3><a shape="rect" name="Camel3.0-Ideas-JDK8JavaDSL"></a>JDK8 Java DSL</h3>
+
+<p>It would be good to have a camel-java8-dsl component that offers a JDK8 DSL which
uses all the nice new stuff from JDK8 with higher order functions, closures, et all.<br
clear="none">
+Though this may comes later in Camel 3.x when JDK8 is GA.</p>
+
+
 <h3><a shape="rect" name="Camel3.0-Ideas-ClearerArchitectureofCamelCore"></a>Clearer
Architecture of Camel Core</h3>
 
 <p>Goals:</p>
@@ -117,15 +129,27 @@
 
 <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-Moreflexibleroutesatruntime%28champion%3F%29"></a>More
flexible routes at runtime (<em>champion</em>?)</h4>
+<h4><a shape="rect" name="Camel3.0-Ideas-Moreflexibleroutesatruntime%28claus%29"></a>More
flexible routes at runtime (claus)</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>
 
-<h4><a shape="rect" name="Camel3.0-Ideas-Fixrouteswithmultipleinputs%28champion%3F%29"></a>Fix
routes with multiple inputs (<em>champion</em>?)</h4>
+<h4><a shape="rect" name="Camel3.0-Ideas-Fixrouteswithmultipleinputs%28claus%29"></a>Fix
routes with multiple inputs (claus)</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 actual solution will depend on the api refactoring.</p>
 
+<h4><a shape="rect" name="Camel3.0-Ideas-RouteinitializationlogicforJavaDSLandXMLDSLs%28claus%29"></a>Route
initialization logic for Java DSL and XML DSLs (claus)</h4>
+
+<p>The Java DSL does its route initialization slightly a bit different than the XML
DSLs, due the nature of it, and the fact the fluent builders can do additional logic, which
the JAXB model of XML DSLs does not. We should align the initialization logic so Java DSL
and XML DSLs does the same thing. They setup the pure model at first. So the configure method
in the RouteBuilder should setup the model as the XML DSL would do. Then the prepare route
logic which follows could be the same in all cases. This would also allow us to ensure when
people use multiple RouteBuilder classes in Java DSL, then context scoped onException, interceptors
is applied for all RouteBuilders.</p>
+
+<h4><a shape="rect" name="Camel3.0-Ideas-AddOnException%2CInterceptor%2Cetc.toJAXBmodelforaCamelContextDefinition%28claus%29"></a>Add
OnException, Interceptor, etc. to JAXB model for a CamelContextDefinition (claus)</h4>
+
+<p>Configuring context scoped onException, interceptors etc. is woven into the RouteDefinition
as part of the route initialization logic. When we have a dynamic routing engine (see above)
that can at runtime support this without the need for woven into the routes. Then we should
also ensure the context scoped onException, interceptors etc. is available in a CamelContextDefinition.
This ensures the models is always 100% kept as it was provided, and we can fully export the
model to XML and other languages (having a supported render).</p>
+
+<h4><a shape="rect" name="Camel3.0-Ideas-Tightenuproutedefinitions%28claus%29"></a>Tighten
up route definitions (claus)</h4>
+
+<p>Currently cross cutting concerns such as error handlers, interceptors, onCompletion
etc. can be define anywhere in the route. We should tighten this up and only allow this to
be configured in the start of the route. This also ensures when end users use code assistance
in their route development, the IDE will not popup a big list which includes these cross cutting
concerns. See also next note. (ProcessorDefinition will therefore be trimmed)</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">
@@ -137,18 +161,6 @@ Message Store implementations are alread
 <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>
-
-<p>The Java DSL does its route initialization slightly a bit different than the XML
DSLs, due the nature of it, and the fact the fluent builders can do additional logic, which
the JAXB model of XML DSLs does not. We should align the initialization logic so Java DSL
and XML DSLs does the same thing. They setup the pure model at first. So the configure method
in the RouteBuilder should setup the model as the XML DSL would do. Then the prepare route
logic which follows could be the same in all cases. This would also allow us to ensure when
people use multiple RouteBuilder classes in Java DSL, then context scoped onException, interceptors
is applied for all RouteBuilders.</p>
-
-<h4><a shape="rect" name="Camel3.0-Ideas-AddOnException%2CInterceptor%2Cetc.toJAXBmodelforaCamelContextDefinition"></a>Add
OnException, Interceptor, etc. to JAXB model for a CamelContextDefinition</h4>
-
-<p>Configuring context scoped onException, interceptors etc. is woven into the RouteDefinition
as part of the route initialization logic. When we have a dynamic routing engine (see above)
that can at runtime support this without the need for woven into the routes. Then we should
also ensure the context scoped onException, interceptors etc. is available in a CamelContextDefinition.
This ensures the models is always 100% kept as it was provided, and we can fully export the
model to XML and other languages (having a supported render).</p>
-
-<h4><a shape="rect" name="Camel3.0-Ideas-Tightenuproutedefinitions"></a>Tighten
up route definitions</h4>
-
-<p>Currently cross cutting concerns such as error handlers, interceptors, onCompletion
etc. can be define anywhere in the route. We should tighten this up and only allow this to
be configured in the start of the route. This also ensures when end users use code assistance
in their route development, the IDE will not popup a big list which includes these cross cutting
concerns. See also next note. (ProcessorDefinition will therefore be trimmed)</p>
-
 <h4><a shape="rect" name="Camel3.0-Ideas-Supportforasynchronoustransactions"></a>Support
for asynchronous transactions</h4>
 
 <p>When using the asynchronous routing engine it would be desirable of transactional
context could be propagated to the new threads.<br clear="none">
@@ -186,6 +198,8 @@ schedule().every(5).minute().pollFrom(<s
 
 <h4><a shape="rect" name="Camel3.0-Ideas-AdvancedScalasupport"></a>Advanced
Scala support</h4>
 
+<p>-1: claus</p>
+
 <p>A proposal for advanced Scala support is <a shape="rect" class="external-link"
href="https://github.com/krasserm/scalaz-camel/wiki" rel="nofollow">scalaz-camel</a>
which is an alternative to Camel's existing Scala DSL.</p>
 
 <h4><a shape="rect" name="Camel3.0-Ideas-MoreEIPsas@annotations"></a>More
EIPs as @annotations</h4>
@@ -195,6 +209,8 @@ And also maybe annotations for <tt>Aggre
 
 <h4><a shape="rect" name="Camel3.0-Ideas-Unifiedstatistics"></a>Unified
statistics</h4>
 
+<p>-1: claus. We keep the JMX API and ppl can use jolokia for REST over JMX etc.</p>
+
 <p>Currently the performance statistics is only avail when using JMX. We should allow
those stats to be enabled regardless if JMX is enabled or not. Then we can use those stats
from the web console. This also allows to expose those stats in the cloud where JMX is often
not possible to be used.</p>
 
 <p>In the <tt>camel-jpa</tt> component we could offer JPA annotated entities
with the performance status (just as we do for the tracer). Then end user can more easily
use that if they want the stats to be persisted in a database using <a shape="rect" href="jpa.html"
title="JPA">JPA</a>.</p>
@@ -228,10 +244,12 @@ And then we should use it in <tt>camel-i
 <p>Maybe expose some interface having commit / rollback methods to make it easier for
component developers to implement custom logic. Currently they may not know about <a shape="rect"
href="oncompletion.html" title="OnCompletion">OnCompletion</a> and how to use <tt>UnitOfWork</tt>
on Exchange to do this today.</p>
 
 <h4><a shape="rect" name="Camel3.0-Ideas-Unifyuri%2Fref"></a>Unify uri/ref</h4>
+<p>+1: claus</p>
 
 <p>Instead of having both uri and ref for endpoints, we should unify this and only
use uri. If people want to use ref, then they can do that using "ref:xx" as an uri. This would
simplify code as we dont have to check for either one.</p>
 
 <h4><a shape="rect" name="Camel3.0-Ideas-removethexxxRefoptions"></a>remove
the xxxRef options</h4>
+<p>+1: claus</p>
 
 <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>
 



Mime
View raw message