On Sun, Jul 25, 2010 at 5:55 AM, William Tam <email.w...@gmail.com> wrote: > I observed some issue regarding restarting Camel Context that I want to > discuss. The detail is in the CAMEL-2991. > > * First off, any objection if SendProcessor implements Navigate? It allows > services associated with the destination endpoint to be restarted. >
Why does navigate allow services associated with the destination to be restarted? Can you be more clear? The idea with navigate is for navigating the process graph. For example a Content Based Router, where you can navigate the when/otherwise processors etc. A SendProcessor doesn't have any "children" to navigate, and therefore should NOT be navigate. > * There is a problem with type converter not getting restarted because the > lazy instantiation won't start the services on the type converter unless the > type converter is newly created. I notice (in a lot of unit tests) that it > is OK to use the type converter even if the CamelContext (its "container") > is stopped or has never been started. If we want this behavior, then it > does not seem to make sense for type converter to be a service. Type > converter could be used anytime including during the shutdown cycling. > Since type converter has been added to the "servicesToClose" list, the type > converter could be stopped (unpredictably) when it is needed during the > shutdown cycle. IMO, type converter probably should not be a service. > I assume you mean the DefaultTypeConverter ? The DefaultTypeConverter must be a Service so CamelContext can start/stop it. It's important that it's the CamelContext that starts it on startup so all the type converters can be loaded up-front. Then there is no lazy loading. The problem with a lazy loading would be at runtime you can end up with concurrent access to the type converter registry and then multiple threads need to load the type converters, which enforces locking/synchronization. And you don't want this overhead at runtime. Hence the converters are loaded on startup. And to do this the DefaultTypeConverter MUST be a service so we have the start/stop methods. There is no strict check in several places of the code to check that a "service" is started before its being used. And therefore you can access code which has been stopped. Can you give an example of an unit test, which uses a type converter after CamelContext has been stopped? And when you say type converter you have to be more precise. There is a TypeConverterRegistry and then there are the 150+ individual type converters. The former is the DefaultTypeConverter which loads all the type converters. The latter is most often not a service because they are @Converter scanned. -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
