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 <seij...@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: cib...@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: cib...@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
