Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of janstey@gmail.com designates
 209.85.218.214 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=vthrI5+rUA9PGdjeMmaiguKHVjRkub5tKEei7roIHuJDCgeODCaDbaiGZh7srP6fEX
         /erjzrZx+y1vt1Tx/F255mVgKuZXpe2vf39kAzSHnbMwerxxFHY7vpxwvNI+3XTcYF9a
         FgBWsnIkjwaImACrCjfKaAFQX01MkkMQINqFY=
MIME-Version: 1.0
In-Reply-To: <67a6ab030907080243s2ca67446pe393742d7fb49ed1@mail.gmail.com>
References: <1908239513.1235639520155.JavaMail.jira@brutus>
	 <5380c69c0907040306w409cc26bx2756c0619815249@mail.gmail.com>
	 <24368755.post@talk.nabble.com> <4A5316DD.4070508@gmail.com>
	 <24371507.post@talk.nabble.com>
	 <2748945d0907070637n3bb3e341p4f155bb1a601e875@mail.gmail.com>
	 <5380c69c0907070657k2c2a2c7drdbe0311da1c8d098@mail.gmail.com>
	 <2748945d0907070715j251da0b7ya7873e6a0363defd@mail.gmail.com>
	 <24384968.post@talk.nabble.com>
	 <67a6ab030907080243s2ca67446pe393742d7fb49ed1@mail.gmail.com>
Date: Wed, 8 Jul 2009 09:41:53 -0230
Message-ID: <2748945d0907080511w33d821abl4962a9686195a31d@mail.gmail.com>
Subject: Re: [jira] Commented: (CAMEL-1392) groovy renderer
From: Jon Anstey <janstey@gmail.com>
To: dev@camel.apache.org
Content-Type: multipart/alternative; boundary=001636c5ac0f119477046e30a5ce

--001636c5ac0f119477046e30a5ce
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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 of these predicates are anonymous classes we're going to
need some way of identifying each so the language renderer classes can
return an appropriate text. How about we add an identifier method to each?
Its probably a bit less crappy than making a named class out of each of the
PredicateBuilder methods...

On Wed, Jul 8, 2009 at 7:13 AM, Gert Vanthienen
<gert.vanthienen@gmail.com>wrote:

> 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, converting an xxxDefinition instance to a
> GroovyRenderer or something...
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> Open Source SOA: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
>
>
> 2009/7/8 alloyer <alloyer@gmail.com>:
> >
> > 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 toDslString()
> >> method or something is needed.
> >>
> >> On Tue, Jul 7, 2009 at 11:27 AM, Claus Ibsen <claus.ibsen@gmail.com>
> >> wrote:
> >>
> >>> On Tue, Jul 7, 2009 at 3:37 PM, Jon Anstey<janstey@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 <alloyer@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.ibsen@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<alloyer@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<alloyer@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 jira@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/
> >>
> >>
> >
> > --
> > View this message in context:
> http://www.nabble.com/-jira--Created%3A-%28CAMEL-1392%29-groovy-renderer-tp22220288p24384968.html
> > Sent from the Camel Development mailing list archive at Nabble.com.
> >
> >
>


-- 
Cheers,
Jon

http://janstey.blogspot.com/

--001636c5ac0f119477046e30a5ce--