You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Claus Ibsen <cl...@gmail.com> on 2010/12/17 19:15:13 UTC
Johan, it happens for all committers
That you commit something which you shouldn't have done.
Today it was Johan's Ed. first time he did that. Welcome to the club.
I am the president, I must have committed the most bad commits to
Camel :)
Your little change in the route model (FromDefinition) really got me
puzzled today.
http://svn.apache.org/viewvc?rev=1050112&view=rev
I have been working on a bigger improvement and have changed files in
core, core-xml, spring. And suddenly I got unit test failures in
camel-spring.
I wondered why because the commits today have been simple and not in
that area. And the CI servers have been busy with other projects and
haven't got around testing the latest commits from trunk. So I
couldn't see the test failures there.
Anyway I digged into it, and almost had me wished I have switched to
git, so I can do a stach. Yeah I will switch later. Writing a book
took all my time.
Then I remembered your commit. The problem is that the route model
must be stateless and agnostic, eg not tied to a runtime CamelContext.
You can use the route model to create runtime routes, and thus it can
act as a skeleton.
So in your change you introduced state as it remembered the endpoint
you would lookup at runtime. But the problem is that you could have it
lookup endpoints from CamelContext A and then use the route model to
create a new runtime route in another camel context or whatever. Then
that endpoint is no looked up in CamelContext B, but it will just use
the existing it previous looked up from CamelContext A.
For example using the routeContext in XML.
http://camel.apache.org/configuring-camel.html
You may consider buying a beer when we meet. My wife got a bit cranky
because I was occupied digging into this issue,
than talking with her when she came home from work.
Anyway welcome to the club.
I actually wrote this as a reminder to us all about the route model
must be stateless. The mistake here could be done by any of us, so
there are no hard feelings. Just that it took me for a little ride,
which doesn't happend that often anymore with Camel. (Well except
crappy and mysterious issues with osgi, but that's another story for
all of us).
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Johan, it happens for all committers
Posted by Claus Ibsen <cl...@gmail.com>.
Hi Johan
Yeah I will improve the javadoc on the getEndpoint method to explain
why it may return null.
In your use-case you provide an uri in the from definition:
route.from("datasource://" + staging + " ...
So that means the FromDefinition contains an uri, and not an Endpoint instance.
And thus why you need to use the getUri to obtain the uri of the
endpoint, and resolve the endpoint instance yourself.
On Sat, Dec 18, 2010 at 5:23 PM, Johan Edstrom <se...@gmail.com> wrote:
> Claus,
>
> None taken - here is the original use-case that once upon a time started out as
> modeled from the StartStop routes test, basically to dynamically and programatically
> invoke route from a BundleActivator from an osgi service.
>
> The below code is from a loop where we wire up several "datasourcepollers"
>
> RouteDefinition route = new RouteDefinition();
>
> String staging = ds.getConfig().getStagingDirectory();
> String fileExtension = ds.getConfig().getInputDataFileExtension();
>
> NcarLogger.development.info("Starting a route from : " + ds.getConfig().getStagingDirectory());
> NcarLogger.development.info("Number of coverage offered is " + ds.getConfig().getOfferedCoverages().size());
>
> // The file polling camel route.
> route.from("datasource://" + staging + "?exclude=.*tmp&recursive=true&idempotent=true&initialDelay=5000&delay=" + delayNextPoll
> + "&useFixedDelay=" + useFixedDelay + "&move=${in.header.FileDestination}" + "&idempotentStore=#idempotentRepository");
>
> TransformationMultiplexer mp = new TransformationMultiplexer();
> mp.setDatasetIdentifiers(ds.getConfig().getOfferedCoverages());
> List destinations = Arrays.asList(transformerInformationService.getTransformers().values().toArray());
> mp.setTransformerDestinations(destinations);
> route.to("log:datasourcepoller");
> route.onCompletion().bean(mp);
>
> route.id("Coverage route from " + ds.getConfig().getStagingDirectory());
>
> routesToStart.add(route);
>
> camelContext.startRoute(route);
> FromDefinition from = route.getInputs().get(0);
>
> //NPE
> //DatasourcePollerEndpoint ep = (DatasourcePollerEndpoint) from.getEndpoint();
>
> DatasourcePollerEndpoint ep = (DatasourcePollerEndpoint) camelContext.getEndpoint(from.getUri());
>
> This behavior was working up until Revision #954840 Committed by ningjiang 6/15/10 5:44 AM CAMEL-2811 the routeContext should be independent on CamelContext,
> I'm guessing since we "should" resolve it i.e keep the model context agnostic - perhaps we should do away / Deperecate that call completely?
> Since it is very easy to resolve, it just through me for a loop.
>
>
> Cheers!
>
> On Dec 17, 2010, at 11:44 PM, Claus Ibsen wrote:
>
>> On Fri, Dec 17, 2010 at 7:20 PM, Johan Edstrom <se...@gmail.com> wrote:
>>> Claus,
>>>
>>> Yes, beer is on me.
>>> The explanation makes sense but I'll ping you on usage of the model.
>>>
>>
>> Btw I wrote this mail in a good spirit, using a bit of scandinavian
>> humor. Don't take this wrong - Its just for a smile.
>>
>>> I made the change after hunting an NPE when upgrading code from an
>>> older Camel release.
>>>
>>
>> Ah nice maybe you can can provide more details and we can either add a
>> note in a release note or get the NPE fixed it ifs a valid bug.
>>
>>
>>>
>>>
>>> On Dec 17, 2010, at 11:15 AM, Claus Ibsen wrote:
>>>
>>>> That you commit something which you shouldn't have done.
>>>>
>>>> Today it was Johan's Ed. first time he did that. Welcome to the club.
>>>> I am the president, I must have committed the most bad commits to
>>>> Camel :)
>>>>
>>>> Your little change in the route model (FromDefinition) really got me
>>>> puzzled today.
>>>> http://svn.apache.org/viewvc?rev=1050112&view=rev
>>>>
>>>> I have been working on a bigger improvement and have changed files in
>>>> core, core-xml, spring. And suddenly I got unit test failures in
>>>> camel-spring.
>>>> I wondered why because the commits today have been simple and not in
>>>> that area. And the CI servers have been busy with other projects and
>>>> haven't got around testing the latest commits from trunk. So I
>>>> couldn't see the test failures there.
>>>>
>>>> Anyway I digged into it, and almost had me wished I have switched to
>>>> git, so I can do a stach. Yeah I will switch later. Writing a book
>>>> took all my time.
>>>> Then I remembered your commit. The problem is that the route model
>>>> must be stateless and agnostic, eg not tied to a runtime CamelContext.
>>>> You can use the route model to create runtime routes, and thus it can
>>>> act as a skeleton.
>>>>
>>>> So in your change you introduced state as it remembered the endpoint
>>>> you would lookup at runtime. But the problem is that you could have it
>>>> lookup endpoints from CamelContext A and then use the route model to
>>>> create a new runtime route in another camel context or whatever. Then
>>>> that endpoint is no looked up in CamelContext B, but it will just use
>>>> the existing it previous looked up from CamelContext A.
>>>>
>>>> For example using the routeContext in XML.
>>>> http://camel.apache.org/configuring-camel.html
>>>>
>>>> You may consider buying a beer when we meet. My wife got a bit cranky
>>>> because I was occupied digging into this issue,
>>>> than talking with her when she came home from work.
>>>>
>>>> Anyway welcome to the club.
>>>>
>>>> I actually wrote this as a reminder to us all about the route model
>>>> must be stateless. The mistake here could be done by any of us, so
>>>> there are no hard feelings. Just that it took me for a little ride,
>>>> which doesn't happend that often anymore with Camel. (Well except
>>>> crappy and mysterious issues with osgi, but that's another story for
>>>> all of us).
>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> -----------------
>>>> FuseSource
>>>> Email: cibsen@fusesource.com
>>>> Web: http://fusesource.com
>>>> Twitter: davsclaus
>>>> 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
>> 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
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Johan, it happens for all committers
Posted by Johan Edstrom <se...@gmail.com>.
Claus,
None taken - here is the original use-case that once upon a time started out as
modeled from the StartStop routes test, basically to dynamically and programatically
invoke route from a BundleActivator from an osgi service.
The below code is from a loop where we wire up several "datasourcepollers"
RouteDefinition route = new RouteDefinition();
String staging = ds.getConfig().getStagingDirectory();
String fileExtension = ds.getConfig().getInputDataFileExtension();
NcarLogger.development.info("Starting a route from : " + ds.getConfig().getStagingDirectory());
NcarLogger.development.info("Number of coverage offered is " + ds.getConfig().getOfferedCoverages().size());
// The file polling camel route.
route.from("datasource://" + staging + "?exclude=.*tmp&recursive=true&idempotent=true&initialDelay=5000&delay=" + delayNextPoll
+ "&useFixedDelay=" + useFixedDelay + "&move=${in.header.FileDestination}" + "&idempotentStore=#idempotentRepository");
TransformationMultiplexer mp = new TransformationMultiplexer();
mp.setDatasetIdentifiers(ds.getConfig().getOfferedCoverages());
List destinations = Arrays.asList(transformerInformationService.getTransformers().values().toArray());
mp.setTransformerDestinations(destinations);
route.to("log:datasourcepoller");
route.onCompletion().bean(mp);
route.id("Coverage route from " + ds.getConfig().getStagingDirectory());
routesToStart.add(route);
camelContext.startRoute(route);
FromDefinition from = route.getInputs().get(0);
//NPE
//DatasourcePollerEndpoint ep = (DatasourcePollerEndpoint) from.getEndpoint();
DatasourcePollerEndpoint ep = (DatasourcePollerEndpoint) camelContext.getEndpoint(from.getUri());
This behavior was working up until Revision #954840 Committed by ningjiang 6/15/10 5:44 AM CAMEL-2811 the routeContext should be independent on CamelContext,
I'm guessing since we "should" resolve it i.e keep the model context agnostic - perhaps we should do away / Deperecate that call completely?
Since it is very easy to resolve, it just through me for a loop.
Cheers!
On Dec 17, 2010, at 11:44 PM, Claus Ibsen wrote:
> On Fri, Dec 17, 2010 at 7:20 PM, Johan Edstrom <se...@gmail.com> wrote:
>> Claus,
>>
>> Yes, beer is on me.
>> The explanation makes sense but I'll ping you on usage of the model.
>>
>
> Btw I wrote this mail in a good spirit, using a bit of scandinavian
> humor. Don't take this wrong - Its just for a smile.
>
>> I made the change after hunting an NPE when upgrading code from an
>> older Camel release.
>>
>
> Ah nice maybe you can can provide more details and we can either add a
> note in a release note or get the NPE fixed it ifs a valid bug.
>
>
>>
>>
>> On Dec 17, 2010, at 11:15 AM, Claus Ibsen wrote:
>>
>>> That you commit something which you shouldn't have done.
>>>
>>> Today it was Johan's Ed. first time he did that. Welcome to the club.
>>> I am the president, I must have committed the most bad commits to
>>> Camel :)
>>>
>>> Your little change in the route model (FromDefinition) really got me
>>> puzzled today.
>>> http://svn.apache.org/viewvc?rev=1050112&view=rev
>>>
>>> I have been working on a bigger improvement and have changed files in
>>> core, core-xml, spring. And suddenly I got unit test failures in
>>> camel-spring.
>>> I wondered why because the commits today have been simple and not in
>>> that area. And the CI servers have been busy with other projects and
>>> haven't got around testing the latest commits from trunk. So I
>>> couldn't see the test failures there.
>>>
>>> Anyway I digged into it, and almost had me wished I have switched to
>>> git, so I can do a stach. Yeah I will switch later. Writing a book
>>> took all my time.
>>> Then I remembered your commit. The problem is that the route model
>>> must be stateless and agnostic, eg not tied to a runtime CamelContext.
>>> You can use the route model to create runtime routes, and thus it can
>>> act as a skeleton.
>>>
>>> So in your change you introduced state as it remembered the endpoint
>>> you would lookup at runtime. But the problem is that you could have it
>>> lookup endpoints from CamelContext A and then use the route model to
>>> create a new runtime route in another camel context or whatever. Then
>>> that endpoint is no looked up in CamelContext B, but it will just use
>>> the existing it previous looked up from CamelContext A.
>>>
>>> For example using the routeContext in XML.
>>> http://camel.apache.org/configuring-camel.html
>>>
>>> You may consider buying a beer when we meet. My wife got a bit cranky
>>> because I was occupied digging into this issue,
>>> than talking with her when she came home from work.
>>>
>>> Anyway welcome to the club.
>>>
>>> I actually wrote this as a reminder to us all about the route model
>>> must be stateless. The mistake here could be done by any of us, so
>>> there are no hard feelings. Just that it took me for a little ride,
>>> which doesn't happend that often anymore with Camel. (Well except
>>> crappy and mysterious issues with osgi, but that's another story for
>>> all of us).
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> FuseSource
>>> Email: cibsen@fusesource.com
>>> Web: http://fusesource.com
>>> Twitter: davsclaus
>>> 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
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
Re: Johan, it happens for all committers
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Dec 17, 2010 at 7:20 PM, Johan Edstrom <se...@gmail.com> wrote:
> Claus,
>
> Yes, beer is on me.
> The explanation makes sense but I'll ping you on usage of the model.
>
Btw I wrote this mail in a good spirit, using a bit of scandinavian
humor. Don't take this wrong - Its just for a smile.
> I made the change after hunting an NPE when upgrading code from an
> older Camel release.
>
Ah nice maybe you can can provide more details and we can either add a
note in a release note or get the NPE fixed it ifs a valid bug.
>
>
> On Dec 17, 2010, at 11:15 AM, Claus Ibsen wrote:
>
>> That you commit something which you shouldn't have done.
>>
>> Today it was Johan's Ed. first time he did that. Welcome to the club.
>> I am the president, I must have committed the most bad commits to
>> Camel :)
>>
>> Your little change in the route model (FromDefinition) really got me
>> puzzled today.
>> http://svn.apache.org/viewvc?rev=1050112&view=rev
>>
>> I have been working on a bigger improvement and have changed files in
>> core, core-xml, spring. And suddenly I got unit test failures in
>> camel-spring.
>> I wondered why because the commits today have been simple and not in
>> that area. And the CI servers have been busy with other projects and
>> haven't got around testing the latest commits from trunk. So I
>> couldn't see the test failures there.
>>
>> Anyway I digged into it, and almost had me wished I have switched to
>> git, so I can do a stach. Yeah I will switch later. Writing a book
>> took all my time.
>> Then I remembered your commit. The problem is that the route model
>> must be stateless and agnostic, eg not tied to a runtime CamelContext.
>> You can use the route model to create runtime routes, and thus it can
>> act as a skeleton.
>>
>> So in your change you introduced state as it remembered the endpoint
>> you would lookup at runtime. But the problem is that you could have it
>> lookup endpoints from CamelContext A and then use the route model to
>> create a new runtime route in another camel context or whatever. Then
>> that endpoint is no looked up in CamelContext B, but it will just use
>> the existing it previous looked up from CamelContext A.
>>
>> For example using the routeContext in XML.
>> http://camel.apache.org/configuring-camel.html
>>
>> You may consider buying a beer when we meet. My wife got a bit cranky
>> because I was occupied digging into this issue,
>> than talking with her when she came home from work.
>>
>> Anyway welcome to the club.
>>
>> I actually wrote this as a reminder to us all about the route model
>> must be stateless. The mistake here could be done by any of us, so
>> there are no hard feelings. Just that it took me for a little ride,
>> which doesn't happend that often anymore with Camel. (Well except
>> crappy and mysterious issues with osgi, but that's another story for
>> all of us).
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> FuseSource
>> Email: cibsen@fusesource.com
>> Web: http://fusesource.com
>> Twitter: davsclaus
>> 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
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Johan, it happens for all committers
Posted by Johan Edstrom <se...@gmail.com>.
Claus,
Yes, beer is on me.
The explanation makes sense but I'll ping you on usage of the model.
I made the change after hunting an NPE when upgrading code from an
older Camel release.
On Dec 17, 2010, at 11:15 AM, Claus Ibsen wrote:
> That you commit something which you shouldn't have done.
>
> Today it was Johan's Ed. first time he did that. Welcome to the club.
> I am the president, I must have committed the most bad commits to
> Camel :)
>
> Your little change in the route model (FromDefinition) really got me
> puzzled today.
> http://svn.apache.org/viewvc?rev=1050112&view=rev
>
> I have been working on a bigger improvement and have changed files in
> core, core-xml, spring. And suddenly I got unit test failures in
> camel-spring.
> I wondered why because the commits today have been simple and not in
> that area. And the CI servers have been busy with other projects and
> haven't got around testing the latest commits from trunk. So I
> couldn't see the test failures there.
>
> Anyway I digged into it, and almost had me wished I have switched to
> git, so I can do a stach. Yeah I will switch later. Writing a book
> took all my time.
> Then I remembered your commit. The problem is that the route model
> must be stateless and agnostic, eg not tied to a runtime CamelContext.
> You can use the route model to create runtime routes, and thus it can
> act as a skeleton.
>
> So in your change you introduced state as it remembered the endpoint
> you would lookup at runtime. But the problem is that you could have it
> lookup endpoints from CamelContext A and then use the route model to
> create a new runtime route in another camel context or whatever. Then
> that endpoint is no looked up in CamelContext B, but it will just use
> the existing it previous looked up from CamelContext A.
>
> For example using the routeContext in XML.
> http://camel.apache.org/configuring-camel.html
>
> You may consider buying a beer when we meet. My wife got a bit cranky
> because I was occupied digging into this issue,
> than talking with her when she came home from work.
>
> Anyway welcome to the club.
>
> I actually wrote this as a reminder to us all about the route model
> must be stateless. The mistake here could be done by any of us, so
> there are no hard feelings. Just that it took me for a little ride,
> which doesn't happend that often anymore with Camel. (Well except
> crappy and mysterious issues with osgi, but that's another story for
> all of us).
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/