camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: [DISCUSS] - Dynamic to endpoint
Date Fri, 29 Jul 2011 13:55:34 GMT
On Thu, Jul 28, 2011 at 4:22 PM, Daniel Kulp <dkulp@apache.org> wrote:
>> Ah seems like I finally got it. By specifying all the possible
>> expressions we should support.
>
> But doesn't that then require the camel-core to know about all the possible
> sub-expressions?   Not exactly extensible.
>
> I personally think it would be better to use an <xsd:any> of some sort there
> and then allow plugging in (or auto detecting) the possibilities from the
> components themselves.
>

You are talking about extending the DSL with custom sub DSLs from 3rd
party components.
Hadrian have raised that issue years ago.

I would like to keep this discussion focused on what we support now at hands.

We have a DSL in camel-core which is the model classes. For the XML we
generate a XSD based on the model classes.
And as such that DSL is fixed to what we provide in the model classes.

So this discussion is about a common use case with Camel, to route a
message to an endpoint.
But the uri of the endpoint is a bit dynamic.

The EIP solution for that is to use the recipient list pattern.
But it has many options, and it may seems a bit overkill to use it for
that common use case.
And some end users dont know that they should use the recipient list pattern.
Instead they look for the To endpoint to be dynamic.



> Dan
>
>
>
>
>
> On Thursday, July 28, 2011 3:37:45 PM Claus Ibsen wrote:
>> Hi
>>
>
>> We can make JAXB generate an optional choice
>>
>>     @XmlElements({
>>     @XmlElement(required = false, name = "simple", type =
>> SimpleExpression.class),
>>     @XmlElement(required = false, name = "groovy", type =
>> GroovyExpression.class)}
>>     )
>>     private ExpressionDefinition expression;
>>
>>
>> And the XSD
>>
>>   <xs:complexType name="sendDefinition" abstract="true">
>>     <xs:complexContent>
>>       <xs:extension base="tns:noOutputDefinition">
>>         <xs:sequence>
>>           <xs:choice minOccurs="0">
>>             <xs:element ref="tns:simple"/>
>>             <xs:element ref="tns:groovy"/>
>>           </xs:choice>
>>         </xs:sequence>
>>         <xs:attribute name="uri" type="xs:string"/>
>>         <xs:attribute name="ref" type="xs:string"/>
>>         <xs:anyAttribute namespace="##other" processContents="skip"/>
>>       </xs:extension>
>>     </xs:complexContent>
>>   </xs:complexType>
>>
>>
>> So that means we can do
>>
>>     <route>
>>       <from uri="direct:start"/>
>>       <convertBodyTo type="java.lang.Integer"/>
>>       <to>
>>         <simple>seda:${header.foo}</simple>
>>       </to>
>>     </route>
>>
>> Which is our dynamic to in XML DSLs. To support his in Java DSL and
>> Scala DSL is possible as well, but requires some methods to be added.
>>
>> On Thu, Jul 28, 2011 at 3:20 PM, Claus Ibsen <claus.ibsen@gmail.com> wrote:
>> > Hi
>> >
>> > I just had a peek once again.
>> > JAXB is still limited in how much you can customize it.
>> >
>> > The only way so far I have found for optional expressions is to add to
>> > SendDefinition:
>> >
>> >    @XmlElementRef
>> >    private List<ExpressionDefinition> expression;
>> >
>> > I have to use a List as JAXB will generate a XSD (see below)
>> > So there is a choice with a minOccurs="0". The problem is that
>> > maxOccurs is unbounded.
>> > And I cannot set a limitation, to 1 or any other value.
>> >
>> > In the XML DSL I can now do
>> >
>> >    <route>
>> >      <from uri="direct:start"/>
>> >      <convertBodyTo type="java.lang.Integer"/>
>> >      <to uri="mock:result"/>
>> >      <to>
>> >        <simple>seda:${header.foo}</simple>
>> >      </to>
>> >    </route>
>> >
>> >
>> >
>> >
>> >  <xs:complexType name="sendDefinition" abstract="true">
>> >    <xs:complexContent>
>> >      <xs:extension base="tns:noOutputDefinition">
>> >        <xs:sequence>
>> >          <xs:choice minOccurs="0" maxOccurs="unbounded">
>> >            <xs:element ref="tns:expressionDefinition"/>
>> >            <xs:element ref="tns:constant"/>
>> >            <xs:element ref="tns:el"/>
>> >            <xs:element ref="tns:groovy"/>
>> >            <xs:element ref="tns:header"/>
>> >            <xs:element ref="tns:jxpath"/>
>> >            <xs:element ref="tns:javaScript"/>
>> >            <xs:element ref="tns:language"/>
>> >            <xs:element ref="tns:method"/>
>> >            <xs:element ref="tns:mvel"/>
>> >            <xs:element ref="tns:ognl"/>
>> >            <xs:element ref="tns:php"/>
>> >            <xs:element ref="tns:property"/>
>> >            <xs:element ref="tns:python"/>
>> >            <xs:element ref="tns:ref"/>
>> >            <xs:element ref="tns:ruby"/>
>> >            <xs:element ref="tns:simple"/>
>> >            <xs:element ref="tns:spel"/>
>> >            <xs:element ref="tns:sql"/>
>> >            <xs:element ref="tns:tokenize"/>
>> >            <xs:element ref="tns:xpath"/>
>> >            <xs:element ref="tns:xquery"/>
>> >          </xs:choice>
>> >        </xs:sequence>
>> >        <xs:attribute name="uri" type="xs:string"/>
>> >        <xs:attribute name="ref" type="xs:string"/>
>> >        <xs:anyAttribute namespace="##other" processContents="skip"/>
>> >      </xs:extension>
>> >    </xs:complexContent>
>> >  </xs:complexType>
>> >
>> > On Thu, Jul 28, 2011 at 2:12 PM, Claus Ibsen <claus.ibsen@gmail.com>
> wrote:
>> >> Hi
>> >>
>> >> Its fairly common for end users of Camel to send a message to an
>> >> endpoint by which the uri is dynamic.
>> >>
>> >> We have a FAQ for that.
>> >> http://camel.apache.org/how-do-i-use-dynamic-uri-in-to.html
>> >>
>> >> However you would need to use the recipient list EIP to support that.
>> >>
>> >> Ben O'Day recently created a ticket to improved this, and on the @user
>> >> a person is asking for this as well.
>> >> https://issues.apache.org/jira/browse/CAMEL-4226
>> >>
>> >> We may want to try to take a stab at improving this. The problem would
>> >> be to keep being backwards compatible. And at the same time support
>> >> passing in expressions for a to in the DSL. Likewise the DSL may get
>> >> big as we would need to add more methods to the model so you can use
>> >> the expressions.
>> >>
>> >> The bigger problem is JAXB being a bit of an *** in terms of
>> >> flexibility of the generated schema. I remember looking at this years
>> >> ago and it wasn't easy to have JAXB generate a XSD where the
>> >> expression would be optional. There was no good way of specifying this
>> >> in the JAXB annotation in the model class.
>> >>
>> >> But since this could be a good improvement we may want to tamper with
>> >> a special support on ToDefinition to force JAXB to see the expression
>> >> as being optional.
>> >>
>> >>
>> >> With this you could write
>> >>
>> >> from X
>> >>   to (simple("xxxx:${header.bar}"))
>> >>
>> >>
>> >> And in XML
>> >>
>> >> <from uri="X"/>
>> >> <to><simple>xxx:${header.bar}</simple></to>
>> >>
>> >> Simple is just one of the many expressions you can use.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Claus Ibsen
>> >> -----------------
>> >> FuseSource
>> >> Email: cibsen@fusesource.com
>> >> Web: http://fusesource.com
>> >> Twitter: davsclaus, fusenews
>> >> Blog: http://davsclaus.blogspot.com/
>> >> Author of Camel in Action: http://www.manning.com/ibsen/
>> >
>> > --
>> > Claus Ibsen
>> > -----------------
>> > FuseSource
>> > Email: cibsen@fusesource.com
>> > Web: http://fusesource.com
>> > Twitter: davsclaus, fusenews
>> > Blog: http://davsclaus.blogspot.com/
>> > Author of Camel in Action: http://www.manning.com/ibsen/
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Mime
View raw message