[2.0] simplifying annotations, DSL and XML to remove uri + ref?

[James.Strachan]

Many places in Camel take a uri or a ref. e.g.

@EndpointInject(uri="foo") or @EndpointInject(ref="bar")

I wonder if given we've a ref component so we can use a uri of
"ref:bar" for a reference; should we do away with the difference
between them in the annotations/DSL/APIs for 2.0?

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/

[Claus Ibsen-2]

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?
If so what should be the name of this attribute?

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

eg:

@EndpointInject(uri="foo")
@EndpointInject(uri="jms:queue:bar")

So if there is a foo in the registry it is used.
As there is no bean in the regsitry with jms:queue:bar an endpoint
will be created

Yeah you can do: uri="ref:foo" but I doubt that many end users know this.


But I haven't played so much with the annotations as you have, so I am
sure you are on to something.



/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/



On Mon, Dec 1, 2008 at 5:50 PM, James Strachan <james.strachan@...> wrote:

> Many places in Camel take a uri or a ref. e.g.
>
> @EndpointInject(uri="foo") or @EndpointInject(ref="bar")
>
> I wonder if given we've a ref component so we can use a uri of
> "ref:bar" for a reference; should we do away with the difference
> between them in the annotations/DSL/APIs for 2.0?
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>

[James.Strachan]

2008/12/1 Claus Ibsen <claus.ibsen@...>:
> 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");

> 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.

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

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/

[Claus Ibsen-2]

Hi James

Now that you have opened the discussion of simplifying stuff for 2.0 -
that is great as we now have the luxury of being able to craft the API
as we like.

I have had this idea for a while and created a ticket for it: CAMEL-895

The issue fired on me again last week with the work on the file
consumer. I introduced new options that can be configured as
- setter
- URI option
This is trivial for simple types as they can be specified directly as
URI parameters, but for real objects this is a pain with URI. That is
why we have a few xxxxRef options to refer to a bean in the Registry.
However this xxxRef code has to be manually code for each and single
one supported. So I figured why do we not support a "convention over
configuration" or what it's called.

So the idea is to:
- support automatic registry lookup for all URI options ending with Ref - xxxRef

/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/



On Mon, Dec 1, 2008 at 8:53 PM, Claus Ibsen <claus.ibsen@...> wrote:

> 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?
> If so what should be the name of this attribute?
>
> 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
>
> eg:
>
> @EndpointInject(uri="foo")
> @EndpointInject(uri="jms:queue:bar")
>
> So if there is a foo in the registry it is used.
> As there is no bean in the regsitry with jms:queue:bar an endpoint
> will be created
>
> Yeah you can do: uri="ref:foo" but I doubt that many end users know this.
>
>
> But I haven't played so much with the annotations as you have, so I am
> sure you are on to something.
>
>
>
> /Claus Ibsen
> Apache Camel Committer
> Blog: http://davsclaus.blogspot.com/
>
>
>
> On Mon, Dec 1, 2008 at 5:50 PM, James Strachan <james.strachan@...> wrote:
>> Many places in Camel take a uri or a ref. e.g.
>>
>> @EndpointInject(uri="foo") or @EndpointInject(ref="bar")
>>
>> I wonder if given we've a ref component so we can use a uri of
>> "ref:bar" for a reference; should we do away with the difference
>> between them in the annotations/DSL/APIs for 2.0?
>>
>> --
>> James
>> -------
>> http://macstrac.blogspot.com/
>>
>> Open Source Integration
>> http://fusesource.com/
>>
>

[James.Strachan]

2008/12/1 Claus Ibsen <claus.ibsen@...>:

> Hi James
>
> Now that you have opened the discussion of simplifying stuff for 2.0 -
> that is great as we now have the luxury of being able to craft the API
> as we like.
>
> I have had this idea for a while and created a ticket for it: CAMEL-895
>
> The issue fired on me again last week with the work on the file
> consumer. I introduced new options that can be configured as
> - setter
> - URI option
> This is trivial for simple types as they can be specified directly as
> URI parameters, but for real objects this is a pain with URI. That is
> why we have a few xxxxRef options to refer to a bean in the Registry.
> However this xxxRef code has to be manually code for each and single
> one supported. So I figured why do we not support a "convention over
> configuration" or what it's called.
>
> So the idea is to:
> - support automatic registry lookup for all URI options ending with Ref - xxxRef

Am not so sure about that - but let me try sleep on it :)

I'd like to encourage folks to use regular Java code (either plain
Java code or Guice or Spring Java Config) to customise components or
endpoints which are complex. That way the IDE completion would be much
more powerful.

FooEndpoint endpoint = new FooEndpoint("someUri");
endpoint.setSomethingComplex(cheese);
camelContext.registerEndpoint(endpoint);


--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/

[Claus Ibsen-2]

On Mon, Dec 1, 2008 at 8:58 PM, James Strachan <james.strachan@...> wrote:

> 2008/12/1 Claus Ibsen <claus.ibsen@...>:
>> 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/
>

[James.Strachan]

2008/12/1 Claus Ibsen <claus.ibsen@...>:

> On Mon, Dec 1, 2008 at 8:58 PM, James Strachan <james.strachan@...> wrote:
>> 2008/12/1 Claus Ibsen <claus.ibsen@...>:
>>> 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?

Probably a cut and paste error for the Pattern annotations :)



>> 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"/>.

Yeah. Still not 100% sure I think this is a good idea - it just
removes one less moving part (remembering if its a uri or a ref)

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/