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: [2.0] simplifying annotations, DSL and XML to remove uri + ref?
Date Mon, 01 Dec 2008 20:08:26 GMT
On Mon, Dec 1, 2008 at 8:58 PM, James Strachan <james.strachan@gmail.com> wrote:
> 2008/12/1 Claus Ibsen <claus.ibsen@gmail.com>:
>> Hi James
>>
>> Maybe you dot get to much sleep at nights now ;)
>> But I had to do a 2nd pass to read and understand your mail.
>
> :)
>
>> Are you suggesting that we can merge the uri and ref @annotation
>> attribute and this imply a single attribute that supports both?
>
> Yes. With annotations, lots of them only take a URI; so we can use a
> default value parameter
>
> e.g.
>
> @Produce("jms:someQueue")
> @Consume("ref:someName");
Ah yeah that is actually nice.

I looked at the @Produce code, why is there a @see javadoc for @InOnly?


>
>> If so what should be the name of this attribute?
>
> if in doubt, uri - but with annotations which have no over values it
> can be value()
>
>
>> I currently like that the uri / ref style as you are in no doubt what
>> they do. But is there a tremendous difference in the code base to
>> support both?
>>
>> I was wondering if we should do a stratety as
>> - look in registry first, if match use it
>> - if no match create an endpoint with the provided text
>
> Thats what we do anyway given URIs AFAIK.
Yeah sometimes the fingers are faster than the mind. I realized that
some bit later. We do this always.

>
> I'm not 100% cerrtain about this btw - it was just a thought. Lots of
> the XML <to uri="someUri"/> or <to ref="someRef"/> support both. I
> just wondered if it'd be simpler if everything, including refs, were a
> URI
Yeah it would. I guess <to uri="ref:foo"/> is as readable as <to ref="foo"/>.

>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>

Mime
View raw message