[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=54034#action_54034
]
Jonathan Anstey commented on CAMEL-1392:
Thanks Xueqiang, I've just committed your
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=53995#action_53995
]
Xueqiang Mi commented on CAMEL-1392:
I read the unit tests and will fix some of them
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=54000#action_54000
]
Jonathan Anstey commented on CAMEL-1392:
Xueqiang,
Just took a look at your latest
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=53698#action_53698
]
Jonathan Anstey commented on CAMEL-1392:
Committed your latest patch in
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=53646#action_53646
]
Jonathan Anstey commented on CAMEL-1392:
I think the method is just too long. Factor
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=53633#action_53633
]
Jonathan Anstey commented on CAMEL-1392:
Hi Xueqiang,
I just tried to apply
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=53634#action_53634
]
Jonathan Anstey commented on CAMEL-1392:
Ah, I see there was some checkstyle fixes
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=53635#action_53635
]
Xueqiang Mi commented on CAMEL-1392:
Oh, I will check it again and re-submit it some
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=53640#action_53640
]
Claus Ibsen commented on CAMEL-1392:
Xuegiang
Could you build with checkstyle and make
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=53585#action_53585
]
Jonathan Anstey commented on CAMEL-1392:
Xueqiang,
I just committed your latest
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=52878#action_52878
]
Jonathan Anstey commented on CAMEL-1392:
Xueqiang,
I just committed your latest
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=52868#action_52868
]
Claus Ibsen commented on CAMEL-1392:
Jonathan I assume you got it covered to get the
Although I force the edited route to reserve the original route id, but some
inner processor id can't be set as original, such as the to id in XML.
{code:xml}
to uri=mock:results id=to2/
{code}
Another question, if the user didn't change the route but click the save
button, the route will also
L.S.,
I wonder if we should not make this a bit more pluggable. It might
make sense to be able to represent the same xxxDefinition in Groovy
DSL, Java DSL, XML, Scala, ... so people can see the same route
definition in multiple languages. Perhaps we can (ab)use the type
converter thing for
That does make a lot of sense :) Though, just to be clear, all
Groovy-specific work done up until now has been in separate classes and not
part of the core. So its not affecting any future Scala renderer. The
predicate builder stuff we're discussing here will so yeah, we need to fix
it... since
On Wed, Jul 8, 2009 at 2:11 PM, Jon Ansteyjans...@gmail.com wrote:
That does make a lot of sense :) Though, just to be clear, all
Groovy-specific work done up until now has been in separate classes and not
part of the core. So its not affecting any future Scala renderer. The
predicate builder
Neato idea but probably a bit overkill? Also, when adding say Groovy
specific predicate text to the metadata, we would still need an identifier
for the anonymous class to look up in the registry (otherwise we'd have to
add the Groovy specific metadata in camel-core at creation time). I still
think
2009/7/8 Gert Vanthienen gert.vanthie...@gmail.com:
L.S.,
I wonder if we should not make this a bit more pluggable. It might
make sense to be able to represent the same xxxDefinition in Groovy
DSL, Java DSL, XML, Scala, ... so people can see the same route
definition in multiple languages.
groovyRenderer now need a lot of work on string processing and can't deal
with some complicated expressions. If the xxxDefinition classes provide a
toString() method which presents a DSL-style string, the rendering work will
be much easier. If it is determined, I will do this work.
Claus Ibsen-2
On Tue, Jul 7, 2009 at 9:57 AM, alloyerallo...@gmail.com wrote:
groovyRenderer now need a lot of work on string processing and can't deal
with some complicated expressions. If the xxxDefinition classes provide a
toString() method which presents a DSL-style string, the rendering work will
be
yep, a sample is as follows:
when rendering such a DSL:
from(direct:start).filter(header(foo).isEqualTo(bar)).to(mock:result)
the from and to are easy to handle, but the filter definition
maintains a {header(foo) == bar} predicate for
(header(foo).isEqualTo(bar)).
So I have to generate the
Hi,
xxxDefinition classes has the toString() method, which is useful for
tracing the message.
I don't know if it can help your Groovy rendering.
Willem
alloyer wrote:
groovyRenderer now need a lot of work on string processing and can't deal
with some complicated expressions. If the
yeah, I am now using the toString() method to render the route on some
xxxDefinitions, but I am still not sure whether the renderer can deal with
a sufficient complicated expression through this method. I am a little
worried
about the renderer's handling with some incidental interminable DSL.
So yeah, rendering languages that we input as a String (i.e. XPath, EL,
etc.) is easy since we have the language text available. The toString
operations on PredicateBuilders on the other hand don't return exactly what
was used to create them. Like you mentioned, header(foo).isEqualTo(bar)
returns
On Tue, Jul 7, 2009 at 3:37 PM, Jon Ansteyjans...@gmail.com wrote:
So yeah, rendering languages that we input as a String (i.e. XPath, EL,
etc.) is easy since we have the language text available. The toString
operations on PredicateBuilders on the other hand don't return exactly what
was used
Yeah, thats probably the better option here and wouldn't be too hard to
implement. Xueqiang, does this sound good to you? Maybe a toDslString()
method or something is needed.
On Tue, Jul 7, 2009 at 11:27 AM, Claus Ibsen claus.ib...@gmail.com wrote:
On Tue, Jul 7, 2009 at 3:37 PM, Jon
yeah, this additional method may bring improvement for my work as current
groovy renderer does some hard code to deal with the expressions.
janstey wrote:
Yeah, thats probably the better option here and wouldn't be too hard to
implement. Xueqiang, does this sound good to you? Maybe a
There are one problem to define the assertions in test cases since sometimes
we are not sure of an input sentence. For example:
1)to(mock:a,mock:b) and to(mock:a).to(mock:b) have the same route
definition
2) Sometimes we can't use a .end() for the choice sentence. But when
renderring, the
On Mon, Jul 6, 2009 at 1:20 PM, alloyerallo...@gmail.com wrote:
There are one problem to define the assertions in test cases since sometimes
we are not sure of an input sentence. For example:
1)to(mock:a,mock:b) and to(mock:a).to(mock:b) have the same route
definition
Yeah this is not
On Mon, Jul 6, 2009 at 9:37 AM, Claus Ibsen claus.ib...@gmail.com wrote:
On Mon, Jul 6, 2009 at 1:20 PM, alloyerallo...@gmail.com wrote:
There are one problem to define the assertions in test cases since
sometimes
we are not sure of an input sentence. For example:
1)to(mock:a,mock:b)
Grabbing name from dataFormat type works fine.
But when I use it on loadBalancer type, it throws a null pointer exception.
loadBalanceDefinition.getLoadBalancerType().getClass().getAnnotation(XmlRootElement.class)
throws the exception.
JIRA j...@apache.org wrote:
[
The getLoadBalancerType don't return null but the getAnnotation().
The getLoadBalancerType return a LoadBalancerDefinition instance, which I
think should be a
RandomLoadBalancerdefinition one.
The dsl is: from(direct:start).loadBalance().random().to(mock:x,
mock:y, mock:z)
Claus Ibsen-2
Hi
I loaded the RandomLoadBalanceTest unit test from camel-core and put a
break point at
assertMockEndpointsSatisfied();
And then inspected the CameContext and its getRouteDefinitions().
See attached picture from the debugger, shows the object graph and the
types it has a runtime.
Maybe
Hi
I have created a basic unit test that navigates the unit test and
emits the route in Java DSL.
Its very basic but demonstrates how its possible.
You can take a look and see how I can determine the load balancer type.
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=52686#action_52686
]
Jonathan Anstey commented on CAMEL-1392:
Quickly trying this new code drop out before
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=52687#action_52687
]
Jonathan Anstey commented on CAMEL-1392:
Also, instead of duplicating the dataformat
oho, I didn't find such a bug unexpectedly. It is caused I uses the same
camel context for every test, and just get the first route definition every
time without clean up the previous route definitions. As a result, we always
get the route for the first test case.
JIRA j...@apache.org wrote:
37 matches
Mail list logo
