|
»
»
[jira] Created: (CAMEL-1392) groovy renderer
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 - 4 - 5 - 6 | Next > |
 |
Re: [jira] Commented: (CAMEL-1392) groovy renderer
by Claus Ibsen-2
::
Rate this Message:
On Tue, Jul 7, 2009 at 3:37 PM, Jon Anstey<janstey@...> 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@...> 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@...> >> >>> 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@...> 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@...> 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@... 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 |
|
|
Re: [jira] Commented: (CAMEL-1392) groovy renderer
by janstey
::
Rate this Message:
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@...> wrote: > On Tue, Jul 7, 2009 at 3:37 PM, Jon Anstey<janstey@...> 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@...> 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@...> > >> >>> 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@...> 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@...> > 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@... 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/ |
|
|
Re: [jira] Commented: (CAMEL-1392) groovy renderer
by xueqiang.mi
::
Rate this Message:
yeah, this additional method may bring improvement for my work as current
groovy renderer does some hard code to deal with the expressions.
|
|
|
Re: [jira] Commented: (CAMEL-1392) groovy renderer
by Gert Vanthienen
::
Rate this Message:
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@...>: > > 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@...> >> wrote: >> >>> On Tue, Jul 7, 2009 at 3:37 PM, Jon Anstey<janstey@...> 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@...> 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@...> >>> >> >>> 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@...> >>> 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@...> >>> 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@... 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. > > |
|
|
Re: [jira] Commented: (CAMEL-1392) groovy renderer
by janstey
::
Rate this Message:
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@...>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@...>: > > > > 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@...> > >> wrote: > >> > >>> On Tue, Jul 7, 2009 at 3:37 PM, Jon Anstey<janstey@...> 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@...> 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@...> > >>> >> >>> 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@...> > >>> 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@...> > >>> 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@... 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/ |
|
|
Re: [jira] Commented: (CAMEL-1392) groovy renderer
by Claus Ibsen-2
::
Rate this Message:
On Wed, Jul 8, 2009 at 2:11 PM, Jon Anstey<janstey@...> 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@...>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@...>: >> > >> > 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@...> >> >> wrote: >> >> >> >>> On Tue, Jul 7, 2009 at 3:37 PM, Jon Anstey<janstey@...> 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@...> 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@...> >> >>> >> >>> 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@...> >> >>> 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@...> >> >>> 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@... 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 |
|
|
Re: [jira] Commented: (CAMEL-1392) groovy renderer
by janstey
::
Rate this Message:
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@...> wrote: > On Wed, Jul 8, 2009 at 2:11 PM, Jon Anstey<janstey@...> 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@...>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@...>: > >> > > >> > 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@...> > >> >> wrote: > >> >> > >> >>> On Tue, Jul 7, 2009 at 3:37 PM, Jon Anstey<janstey@...> > 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@...> > 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@...> > >> >>> >> >>> 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@...> > >> >>> 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@... > > > >> >>> 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@... 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/ |
|
|
Re: [jira] Commented: (CAMEL-1392) groovy renderer
by James.Strachan
::
Rate this Message:
2009/7/8 Gert Vanthienen <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)use the type > converter thing for this, converting an xxxDefinition instance to a > GroovyRenderer or something... Yeah; maybe we should have a pluggable RouteMarshaller which (rather like Language/Expression & most other things) we can have multiple implementations (XML, Java, Scala, Groovy etc) and folks can switch between them at runtime. something vaguely like interface RouteMarshaller { marshal(RoutesDefinition routes, OutputStream out); RoutesDefinition unmarshal(InputStream in); } Then we can just create concrete implementations for the various DSLs. (The Java one BTW could maybe just reuse something like BeanShell maybe?). The XML one is kinda trivial, its just JAXB stuff -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ |
|
|
[jira] Updated: (CAMEL-1392) groovy renderer
by JIRA jira@apache.org
::
Rate this Message:
[ https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xueqiang Mi updated CAMEL-1392: ------------------------------- Attachment: camel-web-20090708.patch Add a bundle of test cases to demonstrate which DSL have been supported by groovy renderer. Tomorrow will start the user guide of it. > 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, camel-web-20090705.patch, camel-web-20090708.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. |
|
|
Re: [jira] Commented: (CAMEL-1392) groovy renderer
by janstey
::
Rate this Message:
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 would be suitable. Also btw if you are wondering, some of these interfaces/features will appear in camel-core eventually so all can extend from them. I figured it would be best to keep most of this stuff in camel-web while its cooking. On Wed, Jul 8, 2009 at 10:28 AM, James Strachan <james.strachan@...>wrote: > 2009/7/8 Gert Vanthienen <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)use the type > > converter thing for this, converting an xxxDefinition instance to a > > GroovyRenderer or something... > > Yeah; maybe we should have a pluggable RouteMarshaller which (rather > like Language/Expression & most other things) we can have multiple > implementations (XML, Java, Scala, Groovy etc) and folks can switch > between them at runtime. > > something vaguely like > > interface RouteMarshaller { > marshal(RoutesDefinition routes, OutputStream out); > RoutesDefinition unmarshal(InputStream in); > } > > Then we can just create concrete implementations for the various DSLs. > (The Java one BTW could maybe just reuse something like BeanShell > maybe?). The XML one is kinda trivial, its just JAXB stuff > > -- > James > ------- > http://macstrac.blogspot.com/ > > Open Source Integration > http://fusesource.com/ > -- Cheers, Jon http://janstey.blogspot.com/ |
|
|
Re: [jira] Created: (CAMEL-1392) groovy renderer
by xueqiang.mi
::
Rate this Message:
Have the endpoint URIs been changed to "direct://start" from "direct:start" ?
I haven't updated my camel-core source for several days. Maybe I have to update it now.
|
|
|
Re: [jira] Created: (CAMEL-1392) groovy renderer
by Claus Ibsen-2
::
Rate this Message:
On Thu, Jul 9, 2009 at 7:47 AM, alloyer<alloyer@...> wrote:
> > Have the endpoint URIs been changed to "direct://start" from "direct:start" ? > I haven't updated my camel-core source for several days. Maybe I have to > update it now. Yes the endpoint registry in Camel will enforce a // after the scheme. This allows end users to input endpoints that Camel can identify direct:foo direct://foo will thus be the same endpoint. Prior to this enforcement they where not the same and that would be confusing. > > > JIRA jira@... wrote: >> >> groovy renderer >> --------------- >> >> Key: CAMEL-1392 >> URL: https://issues.apache.org/activemq/browse/CAMEL-1392 >> Project: Apache Camel >> Issue Type: Sub-task >> Reporter: James Strachan >> >> >> >> >> -- >> 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-tp22220288p24404372.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 |
|
|
Re: [jira] Created: (CAMEL-1392) groovy renderer
by xueqiang.mi
::
Rate this Message:
all right. I saw the deadLetter DSL have used "direct://start". Will this enforcemnt be applied before long?
|
|
|
Re: [jira] Created: (CAMEL-1392) groovy renderer
by Claus Ibsen-2
::
Rate this Message:
On Thu, Jul 9, 2009 at 8:43 AM, alloyer<alloyer@...> wrote:
> > > all right. I saw the deadLetter DSL have used "direct://start". > Will this enforcemnt be applied before long? Its in there now. So yes it will be standard in Camel 2.0. This is the ticket about it http://issues.apache.org/activemq/browse/CAMEL-1756 > > > Claus Ibsen-2 wrote: >> >> On Thu, Jul 9, 2009 at 7:47 AM, alloyer<alloyer@...> wrote: >>> >>> Have the endpoint URIs been changed to "direct://start" from >>> "direct:start" ? >>> I haven't updated my camel-core source for several days. Maybe I have to >>> update it now. >> Yes the endpoint registry in Camel will enforce a // after the scheme. >> This allows end users to input endpoints that Camel can identify >> >> direct:foo >> direct://foo >> >> will thus be the same endpoint. Prior to this enforcement they where >> not the same and that would be confusing. >> >> >> >>> >>> >>> JIRA jira@... wrote: >>>> >>>> groovy renderer >>>> --------------- >>>> >>>> Key: CAMEL-1392 >>>> URL: >>>> https://issues.apache.org/activemq/browse/CAMEL-1392 >>>> Project: Apache Camel >>>> Issue Type: Sub-task >>>> Reporter: James Strachan >>>> >>>> >>>> >>>> >>>> -- >>>> 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-tp22220288p24404372.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-tp22220288p24404925.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 |
|
|
Re: [jira] Created: (CAMEL-1392) groovy renderer
by willem.jiang
::
Rate this Message:
Hi,
You'd better run svn update at lest once a day. Since we are using SVN, you need to get use to the bunch of small changes everyday :) Willem alloyer wrote: > Have the endpoint URIs been changed to "direct://start" from "direct:start" ? > I haven't updated my camel-core source for several days. Maybe I have to > update it now. > > > JIRA jira@... wrote: >> groovy renderer >> --------------- >> >> Key: CAMEL-1392 >> URL: https://issues.apache.org/activemq/browse/CAMEL-1392 >> Project: Apache Camel >> Issue Type: Sub-task >> Reporter: James Strachan >> >> >> >> >> -- >> This message is automatically generated by JIRA. >> - >> You can reply to this email to add a comment to the issue online. >> >> >> > |
|
|
Re: [jira] Commented: (CAMEL-1392) groovy renderer
by xueqiang.mi
::
Rate this Message:
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 be rebuild, is there some suggestion to avoid this rebuild action by determining whether it is changed?
|
|
|
Re: [jira] Commented: (CAMEL-1392) groovy renderer
by janstey
::
Rate this Message:
On Tue, Jul 14, 2009 at 12:51 PM, xueqiang.mi <alloyer@...> 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} > <to uri="mock:results" id="to2"/> > {code} Is it only for certain processors that this is happening? > > > Another question, if the user didn't change the route but click the save > button, the route will also be rebuild, is there some suggestion to avoid > this rebuild action by determining whether it is changed? You could probably just do this check in javascript on the client side? Like maybe set some flag in the textarea's onchange event, which you then send back with the form POST. In the RouteResource, you can use this flag to determine whether or not to rebuild. > > > JIRA jira@... wrote: > > > > > > [ > > > 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 will commit this to trunk: > > > > - Each time the route is edited, we get a new route id (route1, route2, > > route3, etc...). The original route id should be preserved. > > - We probably won't be able to support rendering closure expressions > > nicely unfortunately... a closure could be arbitrary Groovy code, which > > makes things very difficult. You may want to move on with the project and > > keep CAMEL-1769 as a known bug for now. Of course, you are MORE than > > welcome to give it a bit more thought/come up with a solution :) > > - Just as an FYI we'll eventually want to move the text renderer API to > > camel-core and the Groovy renderer to camel-groovy - its fine for now > > since this is still experimental. Maybe when the project is closer to > > completion later this summer you can do this work. > > - You should start adding in some unit tests for the renderer so we can > > keep track of what we know is rendering correctly. > > > > > >> 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 > >> > >> > > > > > > -- > > 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-tp22220288p24481768.html > Sent from the Camel Development mailing list archive at Nabble.com. > > -- Cheers, Jon http://janstey.blogspot.com/ |
|
|
[jira] Updated: (CAMEL-1392) groovy renderer
by JIRA jira@apache.org
::
Rate this Message:
[ https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xueqiang Mi updated CAMEL-1392: ------------------------------- Attachment: camel-web-20090716.patch Improve some code in groovy renderer. > 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, camel-web-20090705.patch, camel-web-20090708.patch, camel-web-20090716.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. |
|
|
[jira] Updated: (CAMEL-1392) groovy renderer
by JIRA jira@apache.org
::
Rate this Message:
[ https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xueqiang Mi updated CAMEL-1392: ------------------------------- Attachment: camel-web-20090717.patch > 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, camel-web-20090705.patch, camel-web-20090708.patch, camel-web-20090716.patch, camel-web-20090717.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. |
|
|
[jira] Updated: (CAMEL-1392) groovy renderer
by JIRA jira@apache.org
::
Rate this Message:
[ https://issues.apache.org/activemq/browse/CAMEL-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xueqiang Mi updated CAMEL-1392: ------------------------------- Attachment: camel-web-20090718.patch add setHeader, setProperty, removeHeader, removeProperty DSLs support. > 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, camel-web-20090705.patch, camel-web-20090708.patch, camel-web-20090716.patch, camel-web-20090717.patch, camel-web-20090718.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. |
| < Prev | 1 - 2 - 3 - 4 - 5 - 6 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
