On Wed, Aug 26, 2009 at 5:13 PM, Gert-Jan van de
Streek<[email protected]> wrote:
>
> Is there some design restriction why this compiles:
> from("").streamCaching()
> .to("")
> .to("")
> .split(new XPathExpression("//object/photos/photo"))
> .to("")
> ;
> while this does not compile:
> from("").streamCaching()
> .to("")
> .to("")
> .split().xpath("//object/photos/photo")
> .to("")
> ;
>
> The compile error is: "The method to(EndPoint) is undefined for the type
> object"
> Camel version is 2.0.0
Yeah its the limitation in the Java Language itself.
When you use the fluent builder as you do and enter .xpath() after the
.split() then the "context" is now expression based and its not
possible
to switch back to the parent to be able to define .to() again.
If you pass in the xpath as a parameter as you did in the first
example you do not have this issue as the "context" is the "parent"
all the time.
There is a static builder for the xpath so example 1 can be written as
.split(xpath("//object/photos/photo"))
Better languages such as Scala, Groovy is much better capable for DSL etc.
> Kind regards,
> Gert-Jan van de Streek
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
