You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by "Claus Ibsen (JIRA)" <ji...@apache.org> on 2008/11/25 13:53:05 UTC
[jira] Created: (CAMEL-1117) improve Java DSL to reduce methods in
ProcessorType
improve Java DSL to reduce methods in ProcessorType
---------------------------------------------------
Key: CAMEL-1117
URL: https://issues.apache.org/activemq/browse/CAMEL-1117
Project: Apache Camel
Issue Type: Improvement
Components: camel-core
Reporter: Claus Ibsen
Assignee: Claus Ibsen
Fix For: 2.0.0
Hi
Most of the Java DSL is defined in
org.apache.camel.model.ProcessorType so when you hit ctrl+space when
creating routes in Java DSL you get a list of 159 methods.
I have noticed during improving the javadoc that we overload the
methods to often, instead of having a few sensible defaults that
tailing 95% useage and then delegate the special customization to it's
own type where the fluent builder can offer the special methods.
For instance the splitter EIP has 12 methods to offer all kind of
combination of parameters. I think we should refactor this to allow
1-3 methods that should cater most usage and then add fluent builder
methods on the SplitterType so end user can do the special
customization there, where we can use good fluent builder methods
names (eg to enable something instead of true, it's parallel() then
it's much more readable
Before:
{code}
from("xxx").splitter(body().tokenize(","), true, myPool).to("yyy");
{code}
After:
{code}
from("xxx").splitter(body().tokenize(",")).parrallel().threadPool(myPool).to("yyy");
{code}
See nabble:
http://www.nabble.com/-PROPOSAL----Camel-2.0---improve-Java-DSL-to-reduce-methods-in-ProcessorType-tt20676775s22882.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1117) improve Java DSL to reduce methods
in ProcessorType
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=47616#action_47616 ]
Claus Ibsen commented on CAMEL-1117:
------------------------------------
{code}
bean(String beanRef)
bean(String beanRef, String method)
{code}
is needed on BuilderSupport to allow end users to use bean expressions in Java DSL without needed to import static or other stuff, it should be easy to use.
Maybe bean(Class bean) is needed as well as it's kind nice for quick prototyping
> improve Java DSL to reduce methods in ProcessorType
> ---------------------------------------------------
>
> Key: CAMEL-1117
> URL: https://issues.apache.org/activemq/browse/CAMEL-1117
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-core
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Fix For: 2.0.0
>
>
> Hi
> Most of the Java DSL is defined in
> org.apache.camel.model.ProcessorType so when you hit ctrl+space when
> creating routes in Java DSL you get a list of 159 methods.
> I have noticed during improving the javadoc that we overload the
> methods to often, instead of having a few sensible defaults that
> tailing 95% useage and then delegate the special customization to it's
> own type where the fluent builder can offer the special methods.
> For instance the splitter EIP has 12 methods to offer all kind of
> combination of parameters. I think we should refactor this to allow
> 1-3 methods that should cater most usage and then add fluent builder
> methods on the SplitterType so end user can do the special
> customization there, where we can use good fluent builder methods
> names (eg to enable something instead of true, it's parallel() then
> it's much more readable
> Before:
> {code}
> from("xxx").splitter(body().tokenize(","), true, myPool).to("yyy");
> {code}
> After:
> {code}
> from("xxx").splitter(body().tokenize(",")).parrallel().threadPool(myPool).to("yyy");
> {code}
> See nabble:
> http://www.nabble.com/-PROPOSAL----Camel-2.0---improve-Java-DSL-to-reduce-methods-in-ProcessorType-tt20676775s22882.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1117) improve Java DSL to reduce methods
in ProcessorType
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=47604#action_47604 ]
Claus Ibsen commented on CAMEL-1117:
------------------------------------
The types (SplitterType etc.) must extend ProcessorType to allow end user to continue the routing using fluent builders. Otherwise he might not be able to use .to("yyy")
> improve Java DSL to reduce methods in ProcessorType
> ---------------------------------------------------
>
> Key: CAMEL-1117
> URL: https://issues.apache.org/activemq/browse/CAMEL-1117
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-core
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Fix For: 2.0.0
>
>
> Hi
> Most of the Java DSL is defined in
> org.apache.camel.model.ProcessorType so when you hit ctrl+space when
> creating routes in Java DSL you get a list of 159 methods.
> I have noticed during improving the javadoc that we overload the
> methods to often, instead of having a few sensible defaults that
> tailing 95% useage and then delegate the special customization to it's
> own type where the fluent builder can offer the special methods.
> For instance the splitter EIP has 12 methods to offer all kind of
> combination of parameters. I think we should refactor this to allow
> 1-3 methods that should cater most usage and then add fluent builder
> methods on the SplitterType so end user can do the special
> customization there, where we can use good fluent builder methods
> names (eg to enable something instead of true, it's parallel() then
> it's much more readable
> Before:
> {code}
> from("xxx").splitter(body().tokenize(","), true, myPool).to("yyy");
> {code}
> After:
> {code}
> from("xxx").splitter(body().tokenize(",")).parrallel().threadPool(myPool).to("yyy");
> {code}
> See nabble:
> http://www.nabble.com/-PROPOSAL----Camel-2.0---improve-Java-DSL-to-reduce-methods-in-ProcessorType-tt20676775s22882.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1117) improve Java DSL to reduce methods
in ProcessorType
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=48277#action_48277 ]
Claus Ibsen commented on CAMEL-1117:
------------------------------------
@Willem
I have committed a little fix for parallel() not using true
And polished the javadoc a bit, and the splitter unit test
Great work
I am still wondering if we could reduce the ProcessorType to contain the 80-95% used methods and force end users to configure the rest using the special types.
But it's much better now.
> improve Java DSL to reduce methods in ProcessorType
> ---------------------------------------------------
>
> Key: CAMEL-1117
> URL: https://issues.apache.org/activemq/browse/CAMEL-1117
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-core
> Reporter: Claus Ibsen
> Assignee: Willem Jiang
> Fix For: 2.0.0
>
>
> Hi
> Most of the Java DSL is defined in
> org.apache.camel.model.ProcessorType so when you hit ctrl+space when
> creating routes in Java DSL you get a list of 159 methods.
> I have noticed during improving the javadoc that we overload the
> methods to often, instead of having a few sensible defaults that
> tailing 95% useage and then delegate the special customization to it's
> own type where the fluent builder can offer the special methods.
> For instance the splitter EIP has 12 methods to offer all kind of
> combination of parameters. I think we should refactor this to allow
> 1-3 methods that should cater most usage and then add fluent builder
> methods on the SplitterType so end user can do the special
> customization there, where we can use good fluent builder methods
> names (eg to enable something instead of true, it's parallel() then
> it's much more readable
> Before:
> {code}
> from("xxx").splitter(body().tokenize(","), true, myPool).to("yyy");
> {code}
> After:
> {code}
> from("xxx").splitter(body().tokenize(",")).parrallel().threadPool(myPool).to("yyy");
> {code}
> See nabble:
> http://www.nabble.com/-PROPOSAL----Camel-2.0---improve-Java-DSL-to-reduce-methods-in-ProcessorType-tt20676775s22882.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1117) improve Java DSL to reduce methods
in ProcessorType
Posted by "Willem Jiang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=48276#action_48276 ]
Willem Jiang commented on CAMEL-1117:
-------------------------------------
1) Added some fluent API in the sub classes of ProcessorType for setting the options.
2) Added an expression() method to set the ExpressionClause on the sub class of ExpressionNode.
3) deprecated lots of split() methods in the ProcessorType.
Clause please review the changes, and feel free to add what I am missing.
> improve Java DSL to reduce methods in ProcessorType
> ---------------------------------------------------
>
> Key: CAMEL-1117
> URL: https://issues.apache.org/activemq/browse/CAMEL-1117
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-core
> Reporter: Claus Ibsen
> Assignee: Willem Jiang
> Fix For: 2.0.0
>
>
> Hi
> Most of the Java DSL is defined in
> org.apache.camel.model.ProcessorType so when you hit ctrl+space when
> creating routes in Java DSL you get a list of 159 methods.
> I have noticed during improving the javadoc that we overload the
> methods to often, instead of having a few sensible defaults that
> tailing 95% useage and then delegate the special customization to it's
> own type where the fluent builder can offer the special methods.
> For instance the splitter EIP has 12 methods to offer all kind of
> combination of parameters. I think we should refactor this to allow
> 1-3 methods that should cater most usage and then add fluent builder
> methods on the SplitterType so end user can do the special
> customization there, where we can use good fluent builder methods
> names (eg to enable something instead of true, it's parallel() then
> it's much more readable
> Before:
> {code}
> from("xxx").splitter(body().tokenize(","), true, myPool).to("yyy");
> {code}
> After:
> {code}
> from("xxx").splitter(body().tokenize(",")).parrallel().threadPool(myPool).to("yyy");
> {code}
> See nabble:
> http://www.nabble.com/-PROPOSAL----Camel-2.0---improve-Java-DSL-to-reduce-methods-in-ProcessorType-tt20676775s22882.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CAMEL-1117) improve Java DSL to reduce methods in
ProcessorType
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen reassigned CAMEL-1117:
----------------------------------
Assignee: (was: Claus Ibsen)
I have my hands full with the refactor of the ftp component.
So if anyone has the time and energy to do this one it would be great. Basically reduce the fluent builders we have overloaded in the ProcessType and move/add new fluent builders on the concrete xxxType instead
For instance the aggregator has 12 methods I think.
> improve Java DSL to reduce methods in ProcessorType
> ---------------------------------------------------
>
> Key: CAMEL-1117
> URL: https://issues.apache.org/activemq/browse/CAMEL-1117
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-core
> Reporter: Claus Ibsen
> Fix For: 2.0.0
>
>
> Hi
> Most of the Java DSL is defined in
> org.apache.camel.model.ProcessorType so when you hit ctrl+space when
> creating routes in Java DSL you get a list of 159 methods.
> I have noticed during improving the javadoc that we overload the
> methods to often, instead of having a few sensible defaults that
> tailing 95% useage and then delegate the special customization to it's
> own type where the fluent builder can offer the special methods.
> For instance the splitter EIP has 12 methods to offer all kind of
> combination of parameters. I think we should refactor this to allow
> 1-3 methods that should cater most usage and then add fluent builder
> methods on the SplitterType so end user can do the special
> customization there, where we can use good fluent builder methods
> names (eg to enable something instead of true, it's parallel() then
> it's much more readable
> Before:
> {code}
> from("xxx").splitter(body().tokenize(","), true, myPool).to("yyy");
> {code}
> After:
> {code}
> from("xxx").splitter(body().tokenize(",")).parrallel().threadPool(myPool).to("yyy");
> {code}
> See nabble:
> http://www.nabble.com/-PROPOSAL----Camel-2.0---improve-Java-DSL-to-reduce-methods-in-ProcessorType-tt20676775s22882.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CAMEL-1117) improve Java DSL to reduce methods in
ProcessorType
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen reassigned CAMEL-1117:
----------------------------------
Assignee: Willem Jiang
Willem do you mind take a look at this? You have done some of the work already today?
Basically reduce overloaded methods on ProcessorType and move options to the xxxType as fluent builders. Keep on the most common methods in ProcessorType and leave the advanced options as fluent builders on the xxxType.
We gotta get the 120-150 methods listed in the code completion list from the java editor when end users use the Java DSL. It's to overwhelming with all these methods.
> improve Java DSL to reduce methods in ProcessorType
> ---------------------------------------------------
>
> Key: CAMEL-1117
> URL: https://issues.apache.org/activemq/browse/CAMEL-1117
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-core
> Reporter: Claus Ibsen
> Assignee: Willem Jiang
> Fix For: 2.0.0
>
>
> Hi
> Most of the Java DSL is defined in
> org.apache.camel.model.ProcessorType so when you hit ctrl+space when
> creating routes in Java DSL you get a list of 159 methods.
> I have noticed during improving the javadoc that we overload the
> methods to often, instead of having a few sensible defaults that
> tailing 95% useage and then delegate the special customization to it's
> own type where the fluent builder can offer the special methods.
> For instance the splitter EIP has 12 methods to offer all kind of
> combination of parameters. I think we should refactor this to allow
> 1-3 methods that should cater most usage and then add fluent builder
> methods on the SplitterType so end user can do the special
> customization there, where we can use good fluent builder methods
> names (eg to enable something instead of true, it's parallel() then
> it's much more readable
> Before:
> {code}
> from("xxx").splitter(body().tokenize(","), true, myPool).to("yyy");
> {code}
> After:
> {code}
> from("xxx").splitter(body().tokenize(",")).parrallel().threadPool(myPool).to("yyy");
> {code}
> See nabble:
> http://www.nabble.com/-PROPOSAL----Camel-2.0---improve-Java-DSL-to-reduce-methods-in-ProcessorType-tt20676775s22882.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-1117) improve Java DSL to reduce methods in
ProcessorType
Posted by "Willem Jiang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Willem Jiang resolved CAMEL-1117.
---------------------------------
Resolution: Fixed
@Claus
Thanks for polishing the codes.
I think we can close it now.
If we want to keep on cleaning the ProcessorType DSL methods , we could fill a new JIRA for it.
> improve Java DSL to reduce methods in ProcessorType
> ---------------------------------------------------
>
> Key: CAMEL-1117
> URL: https://issues.apache.org/activemq/browse/CAMEL-1117
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-core
> Reporter: Claus Ibsen
> Assignee: Willem Jiang
> Fix For: 2.0.0
>
>
> Hi
> Most of the Java DSL is defined in
> org.apache.camel.model.ProcessorType so when you hit ctrl+space when
> creating routes in Java DSL you get a list of 159 methods.
> I have noticed during improving the javadoc that we overload the
> methods to often, instead of having a few sensible defaults that
> tailing 95% useage and then delegate the special customization to it's
> own type where the fluent builder can offer the special methods.
> For instance the splitter EIP has 12 methods to offer all kind of
> combination of parameters. I think we should refactor this to allow
> 1-3 methods that should cater most usage and then add fluent builder
> methods on the SplitterType so end user can do the special
> customization there, where we can use good fluent builder methods
> names (eg to enable something instead of true, it's parallel() then
> it's much more readable
> Before:
> {code}
> from("xxx").splitter(body().tokenize(","), true, myPool).to("yyy");
> {code}
> After:
> {code}
> from("xxx").splitter(body().tokenize(",")).parrallel().threadPool(myPool).to("yyy");
> {code}
> See nabble:
> http://www.nabble.com/-PROPOSAL----Camel-2.0---improve-Java-DSL-to-reduce-methods-in-ProcessorType-tt20676775s22882.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1117) improve Java DSL to reduce methods
in ProcessorType
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=47622#action_47622 ]
Claus Ibsen commented on CAMEL-1117:
------------------------------------
We have a MethodCallExpression that we should consider renaming to BeanExpression. We mostly have bean() in the DSL but then we have this one that uses method / methodCall. I think we should consider aligning this so it's plain bean everywhere.
> improve Java DSL to reduce methods in ProcessorType
> ---------------------------------------------------
>
> Key: CAMEL-1117
> URL: https://issues.apache.org/activemq/browse/CAMEL-1117
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-core
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Fix For: 2.0.0
>
>
> Hi
> Most of the Java DSL is defined in
> org.apache.camel.model.ProcessorType so when you hit ctrl+space when
> creating routes in Java DSL you get a list of 159 methods.
> I have noticed during improving the javadoc that we overload the
> methods to often, instead of having a few sensible defaults that
> tailing 95% useage and then delegate the special customization to it's
> own type where the fluent builder can offer the special methods.
> For instance the splitter EIP has 12 methods to offer all kind of
> combination of parameters. I think we should refactor this to allow
> 1-3 methods that should cater most usage and then add fluent builder
> methods on the SplitterType so end user can do the special
> customization there, where we can use good fluent builder methods
> names (eg to enable something instead of true, it's parallel() then
> it's much more readable
> Before:
> {code}
> from("xxx").splitter(body().tokenize(","), true, myPool).to("yyy");
> {code}
> After:
> {code}
> from("xxx").splitter(body().tokenize(",")).parrallel().threadPool(myPool).to("yyy");
> {code}
> See nabble:
> http://www.nabble.com/-PROPOSAL----Camel-2.0---improve-Java-DSL-to-reduce-methods-in-ProcessorType-tt20676775s22882.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1117) improve Java DSL to reduce methods
in ProcessorType
Posted by "Willem Jiang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=48260#action_48260 ]
Willem Jiang commented on CAMEL-1117:
-------------------------------------
Yes, we could reduce the Splitter and Aggregator relates DSL in ProcessorType, by add the detail optional DSL in the sub type class of PorcessorType.
It may take a while to finish this task, lots for method need to be went through :)
> improve Java DSL to reduce methods in ProcessorType
> ---------------------------------------------------
>
> Key: CAMEL-1117
> URL: https://issues.apache.org/activemq/browse/CAMEL-1117
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-core
> Reporter: Claus Ibsen
> Assignee: Willem Jiang
> Fix For: 2.0.0
>
>
> Hi
> Most of the Java DSL is defined in
> org.apache.camel.model.ProcessorType so when you hit ctrl+space when
> creating routes in Java DSL you get a list of 159 methods.
> I have noticed during improving the javadoc that we overload the
> methods to often, instead of having a few sensible defaults that
> tailing 95% useage and then delegate the special customization to it's
> own type where the fluent builder can offer the special methods.
> For instance the splitter EIP has 12 methods to offer all kind of
> combination of parameters. I think we should refactor this to allow
> 1-3 methods that should cater most usage and then add fluent builder
> methods on the SplitterType so end user can do the special
> customization there, where we can use good fluent builder methods
> names (eg to enable something instead of true, it's parallel() then
> it's much more readable
> Before:
> {code}
> from("xxx").splitter(body().tokenize(","), true, myPool).to("yyy");
> {code}
> After:
> {code}
> from("xxx").splitter(body().tokenize(",")).parrallel().threadPool(myPool).to("yyy");
> {code}
> See nabble:
> http://www.nabble.com/-PROPOSAL----Camel-2.0---improve-Java-DSL-to-reduce-methods-in-ProcessorType-tt20676775s22882.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.