[
https://issues.apache.org/jira/browse/CAMEL-12608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16531062#comment-16531062
]
Zoran Regvart commented on CAMEL-12608:
---------------------------------------
[~rhuss] yeah I don't think it's an issue now. It might be one in the future if
we implement this -- then it locks us in into a lifecycle that says: you can
use route Java DSL from object initialization code, not just in {{configure}}
method. One use case where this might be an issue is with some external
serialized form of the {{Routes}} subclass, the route Java DLS methods will get
invoked during deserialization.
If we put the contract at route Java DSL can be used at the point when
{{configure}} method is invoked then we have lifecycle that we can manage, i.e.
control the point when Java DSL will be invoked.
Not that this is a bad approach, seems nice from a syntactical standpoint, this
is only one side effect that I can think of...
> Add default no-op implementation of RouteBuilder
> ------------------------------------------------
>
> Key: CAMEL-12608
> URL: https://issues.apache.org/jira/browse/CAMEL-12608
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
> Reporter: Roland Huss
> Priority: Major
>
> Inspired by JMockit which use object initializers for introducing their Java
> DSL, I think it would be a good idea to add a no-op default implementation of
> RouteBuilder, with a short name like 'Routes'.
> {code:java}
> ctx.add(new Routes {{
> from("file:data/inbox?noop=true")
> .to("file:data/outbox");
> }});
> {code}
> That way one can avoid the creation of anonymous inner classes, which is not
> only shorted and less boilerplate but also creates less classes and saves
> non-heap memory.
>
> A simple POC as submitted as PR at
> [https://github.com/apache/camel/pull/2401] which could be extended to
> include better unit testing and documentation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
