[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=54034#action_54034
]
Jonathan Anstey commented on CAMEL-1392:
Thanks Xueqiang, I've just committed your la
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=54000#action_54000
]
Jonathan Anstey commented on CAMEL-1392:
Xueqiang,
Just took a look at your latest p
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53995#action_53995
]
Xueqiang Mi commented on CAMEL-1392:
I read the unit tests and will fix some of them asap
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53964#action_53964
]
Willem Jiang commented on CAMEL-1392:
-
@ Xueqiang
Can you take a look the unit tests in
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53698#action_53698
]
Jonathan Anstey commented on CAMEL-1392:
Committed your latest patch in http://svn.ap
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53663#action_53663
]
Jonathan Anstey commented on CAMEL-1392:
Committed camel-20090818.patch in rev
http:
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=53640#action_53640
]
Claus Ibsen commented on CAMEL-1392:
Xuegiang
Could you build with checkstyle and make s
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53635#action_53635
]
Xueqiang Mi commented on CAMEL-1392:
Oh, I will check it again and re-submit it some late
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53634#action_53634
]
Jonathan Anstey commented on CAMEL-1392:
Ah, I see there was some checkstyle fixes ma
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53633#action_53633
]
Jonathan Anstey commented on CAMEL-1392:
Hi Xueqiang,
I just tried to apply camel-20
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53585#action_53585
]
Jonathan Anstey commented on CAMEL-1392:
Xueqiang,
I just committed your latest patc
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=52897#action_52897
]
Jonathan Anstey commented on CAMEL-1392:
Looks great Xueqiang. Keep up the good work.
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=52878#action_52878
]
Jonathan Anstey commented on CAMEL-1392:
Xueqiang,
I just committed your latest patc
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=52868#action_52868
]
Claus Ibsen commented on CAMEL-1392:
Jonathan I assume you got it covered to get the patc
On Tue, Jul 14, 2009 at 12:51 PM, xueqiang.mi wrote:
>
> 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}
>
> {code}
Is it only for certain processors that this is happening?
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}
{code}
Another question, if the user didn't change the route but click the save
button, the route will also be rebuild, is there some s
Yeah, that could be done pretty easily. The ability to convert Groovy text
into RouteDefintions and vice versa is in Xueqiangs latest patch. Would just
need a new interface and some refactoring, etc.
Still on the issue of predicates needing language specific names, I think my
suggestion before wou
2009/7/8 Gert Vanthienen :
> 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)
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
On Wed, Jul 8, 2009 at 2:11 PM, Jon Anstey 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 stuff we're di
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 all
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 this,
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 toD
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 wrote:
> On Tue, Jul 7, 2009 at 3:37 PM, Jon Anstey wrote:
> > So yeah, rend
On Tue, Jul 7, 2009 at 3:37 PM, Jon Anstey 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 to create them
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")
retur
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.
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 xxxDefin
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 ge
On Tue, Jul 7, 2009 at 9:57 AM, alloyer 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 much easier. I
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 Mon, Jul 6, 2009 at 9:37 AM, Claus Ibsen wrote:
> On Mon, Jul 6, 2009 at 1:20 PM, alloyer 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("moc
On Mon, Jul 6, 2009 at 1:20 PM, alloyer 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 possible
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
Yeah. This method to invoke "getLoadBalancer()" may be the only valid now.
Thanks
Claus Ibsen-2 wrote:
>
> 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
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.
http://svn.apache.org/viewvc/camel/trunk/camel-core/src/test/java/org/apache
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
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-
On Sat, Jul 4, 2009 at 8:16 AM, alloyer wrote:
>
> 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.
>
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:
>
>
> [
> https://issues
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:
>
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=52687#action_52687
]
Jonathan Anstey commented on CAMEL-1392:
Also, instead of duplicating the dataformat
[
https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=52559#action_52559
]
Jonathan Anstey commented on CAMEL-1392:
Nice work Xueqiang. A few comments before I
45 matches
Mail list logo
