The key technical requirement AIUI is to support multiple domain/contribution/composite applications with plugable implementations of all the runtime extensions to do that. But that doesn't mean supporting multiple different extension implementations concurrently in the same active runtime, and so far when we've tried to do that we've never been very successful - eg the multiple ServletHost or SCA bindings impls. The runtime is pretty lightweight and has lazy loading of things all over the place so its probably not much overhead to run several instances, and its also unlikely that there would ever be very many different endpoint registry impls wanted to be run concurrently so its not really going to be a lot of overhead to use separate runtimes. I can see you're keen to do this though so why don't you go ahead and implement the tweaks you talked about in the first email in this thread.
What i do think would be good though is if we could just pick one registry impl and make it work consistently for all the main use cases we have instead of trying to maintain several different ones each with separate capabilities and limitations and test and samples and ways of being configured. ...ant On Mon, Jan 25, 2010 at 4:54 PM, Raymond Feng <[email protected]> wrote: > Come on, Ant. I'm talking about a key technical requirement here: > > 1) Now we have the ability to run a shared Tuscany runtime in a JVM and it > can be used to create multiple nodes, with each of them running a composite > application from one or more SCA domains. > > 2) The Tuscany runtime (NodeFactory and the ExtensionPointRegistry) doesn't > keep any application related states, including the > domain/contribution/composite. This is keen to be able to embed Tuscany in a > managed container such as Web or OSGi so that one shared instance of Tuscany > runtime to work with multiple composite apps. > > 3) Requiring different Tuscany runtime instances for composite applications > from different SCA domains will definitely increase the memory footprint and > the overhead to bootstrap more Tuscany runtime instances. > > 4) I'm not against the possibility to use different Tuscany runtime > instances at the application scope, for example, each web app can > potentially package Tuscany runtime in the WAR. But for the shared Tuscany > runtime case, I want the feasibility to use a singleton to deal with > multiple composite apps from one or more SCA domains that require different > protocols for the endpoint registry. > > Thanks, > Raymond > -------------------------------------------------- > From: "ant elder" <[email protected]> > Sent: Monday, January 25, 2010 1:49 AM > To: <[email protected]> > Subject: Re: Changing the endpoint registry usage to be based on the > discovered impl not the domain uri scheme > >> On Sun, Jan 24, 2010 at 5:55 PM, Raymond Feng <[email protected]> wrote: >>> >>> [[SNIP]] >>> >>>> It sounds like we don't really need multiple registries concurrently >>>> in the same runtime but whats really wanted is a way to have >>>> separately configurable Tuscany runtime instances from the same set of >>>> Tuscany jars. That would be really useful, it would simplify a a lot >>>> of our code, it would fix other cases where this has been an issue >>>> like the ServletHost problems mentioned above, and it would help with >>>> some other things i've never been able to find easy ways to do with >>>> the current configuration options. So - >>> >>> NO! Why do we have to clone Tuscany runtime instances in the same JVM for >>> the mere purpose of supporting multiple domains? Please remember that all >>> the code in the extension point registry is stateless and independent of >>> the application state (domain/node/contribution/composite). >>> >> >> Thats a strawman argument Raymond so I'm not going to get drawn into it. >> >> ...ant > >
