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 Anstey<jans...@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 to create them. Like you mentioned,
> header("foo").isEqualTo("bar")
> > returns header(foo) == bar, which is not very helpful to you.
> >
> > So, you could provide a patch to the toString methods for the
> > PredicateBuilders so that they return something like
> > header("foo").isEqualTo("bar") instead of header(foo) == bar. Though this
> is
> > not as nice looking for the tracing feature IMO. What do others think of
> > this change?
>
> Maybe a new method is needed that can output it more DSL like.
>
> The toString as they are are nice as they are more standard math like
> and easy to understand.
>
>
> >
> > On Tue, Jul 7, 2009 at 8:52 AM, alloyer <allo...@gmail.com> wrote:
> >
> >>
> >> 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.
> >>
> >>
> >> willem.jiang wrote:
> >> >
> >> > 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 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 wrote:
> >> >>>
> >> >>> I do wonder if we should by default change the toString() in the
> >> >>> xxxDefinition to be more Java DSL like so its easier to read the
> >> >>> route.
> >> >>>
> >> >>>
> >> >>> On Sat, Jul 4, 2009 at 11:32 AM, Claus Ibsen<claus.ib...@gmail.com>
> >> >>> wrote:
> >> >>>> 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 you need a getLoadBalancer() without a parameter. But try
> with
> >> >>>> getLoadBalancer(null) in the class LoadBalancerDefinition as it
> should
> >> >>>> have been created. Notice its the load balancer definition with R
> that
> >> >>>> can return the specific type.
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> On Sat, Jul 4, 2009 at 11:07 AM, alloyer<allo...@gmail.com> 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 wrote:
> >> >>>>>> On Sat, Jul 4, 2009 at 8:16 AM, alloyer<allo...@gmail.com>
> 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.
> >> >>>>>>>
> >> >>>>>> I think its because you use ref to lookup the definition in the
> >> >>>>>> registry.
> >> >>>>>> Then when Camel builds the runtime route it will lookup the real
> >> load
> >> >>>>>> balancer and use it.
> >> >>>>>>
> >> >>>>>> So if getLoadBalancerType returns null then try checking getRef
> and
> >> >>>>>> see if you can lookup this bean in the registry
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> What does the route DSL looks like?
> >> >>>>>>
> >> >>>>>>> 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 types (and
> >> loadbalancer
> >> >>>>>>>> types
> >> >>>>>>>> too), you should be able to grab the short names through the
> JAXB
> >> >>>>>>>> metadata. Like so
> >> >>>>>>>>
> >> >>>>>>>> {code}
> >> >>>>>>>>
> dataFormat.getClass().getAnnotation(XmlRootElement.class).name()
> >> >>>>>>>> {code}
> >> >>>>>>>>
> >> >>>>>>>>> groovy renderer
> >> >>>>>>>>> ---------------
> >> >>>>>>>>>
> >> >>>>>>>>>                 Key: CAMEL-1392
> >> >>>>>>>>>                 URL:
> >> >>>>>>>>> https://issues.apache.org/activemq/browse/CAMEL-1392
> >> >>>>>>>>>             Project: Apache Camel
> >> >>>>>>>>>          Issue Type: Sub-task
> >> >>>>>>>>>            Reporter: James Strachan
> >> >>>>>>>>>            Assignee: Xueqiang Mi
> >> >>>>>>>>>         Attachments: camel-web-20090629.patch,
> >> >>>>>>>>> camel-web-20090703.patch
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>> --
> >> >>>>>>>> This message is automatically generated by JIRA.
> >> >>>>>>>> -
> >> >>>>>>>> You can reply to this email to add a comment to the issue
> online.
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>> --
> >> >>>>>>> View this message in context:
> >> >>>>>>>
> >>
> http://www.nabble.com/-jira--Created%3A-%28CAMEL-1392%29-groovy-renderer-tp22220288p24331647.html
> >> >>>>>>> Sent from the Camel Development mailing list archive at
> Nabble.com.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> --
> >> >>>>>> Claus Ibsen
> >> >>>>>> Apache Camel Committer
> >> >>>>>>
> >> >>>>>> Open Source Integration: http://fusesource.com
> >> >>>>>> Blog: http://davsclaus.blogspot.com/
> >> >>>>>> Twitter: http://twitter.com/davsclaus
> >> >>>>>>
> >> >>>>>>
> >> >>>>> --
> >> >>>>> View this message in context:
> >> >>>>>
> >>
> http://www.nabble.com/-jira--Created%3A-%28CAMEL-1392%29-groovy-renderer-tp22220288p24332317.html
> >> >>>>> Sent from the Camel Development mailing list archive at
> Nabble.com.
> >> >>>>>
> >> >>>>>
> >> >>>>
> >> >>>>
> >> >>>> --
> >> >>>> Claus Ibsen
> >> >>>> Apache Camel Committer
> >> >>>>
> >> >>>> Open Source Integration: http://fusesource.com
> >> >>>> Blog: http://davsclaus.blogspot.com/
> >> >>>> Twitter: http://twitter.com/davsclaus
> >> >>>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> Claus Ibsen
> >> >>> Apache Camel Committer
> >> >>>
> >> >>> Open Source Integration: http://fusesource.com
> >> >>> Blog: http://davsclaus.blogspot.com/
> >> >>> Twitter: http://twitter.com/davsclaus
> >> >>>
> >> >>>
> >> >>
> >> >
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/-jira--Created%3A-%28CAMEL-1392%29-groovy-renderer-tp22220288p24371507.html
> >> Sent from the Camel Development mailing list archive at Nabble.com.
> >>
> >>
> >
> >
> > --
> > Cheers,
> > Jon
> >
> > http://janstey.blogspot.com/
> >
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>



-- 
Cheers,
Jon

http://janstey.blogspot.com/

Reply via email to