camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Anstey <jans...@gmail.com>
Subject Re: [jira] Commented: (CAMEL-1392) groovy renderer
Date Wed, 08 Jul 2009 12:50:03 GMT
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 adding a language neutral indentifier to each would be the easy way to
go. We could even just reuse the getOperationText already on many of them.

Grabbing another coffee now too :)

On Wed, Jul 8, 2009 at 9:49 AM, Claus Ibsen <claus.ibsen@gmail.com> wrote:

> On Wed, Jul 8, 2009 at 2:11 PM, Jon Anstey<janstey@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 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...
>
> Just a quick thought as believe it or not I am only on my first mug of
> coffee now.
>
> What if we had a Expression registry that could have meta data about
> the expression.
> And the builder methods uses this registry to lookup their expression of
> choice.
>
> Then if you got hold of the Expression instance you could look itself
> up in the registry and get metadata.
>
> Might be a bit overkill.
>
> End users can also create their own expressions on the fly.
>
> Expression foo = new Expression() {
>  ...
> }
>
> Hmm more coffee is needed.
>
>
> >
> > 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/
> >
>
>
>
> --
> 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/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message