Fine, I don't think we need it as anyone who wants to share the factory can easily do that sharing themselves (isn't that what the NodeManager.factory field in the osgi node module is doing?), and when we add config options to NodeFactory its going to be unclear which options are being used by NodeFactory.getInstance. But lets just leave getInstance for now and make progress on the rest of it.
...ant On Tue, Feb 2, 2010 at 5:04 PM, Raymond Feng <[email protected]> wrote: > I have different opinions here: > > 1) I prefer to use NodeFactory.getInstance() which gives us a singleton of > Tuscany runtime in the same classloading space. As extension points and > extensions are independent of any states (such as domain, contributions, > composites) of the SCA applications, it's safe to share. It leads to better > performance and less memory consumption. > > 2) I'm willing to comprise to have an option of newInstance() even though I > don't see a critical need to configure NodeFactory differently in the same > classloading space. > > 3) AFAIK, we have two use cases here that a Tuscany runtime is shared in the > same classloading space: > > * Deep integration with JEE container such as Tomcat or WebSphere to serve > multiple SCA-enabled web applications. > * Tuscany runtime is installed to an OSGi framework to serve multiple > SCA-enabled bundles. > > What do you want to configure the NodeFactory differently here? > > Thanks, > Raymond > -------------------------------------------------- > From: "ant elder" <[email protected]> > Sent: Tuesday, February 02, 2010 2:05 AM > To: <[email protected]> > Subject: Re: Our story for Domain/Node > >> I'll reply to separate points in separate emails to try to keep the >> discussion clear: >> >> On Fri, Jan 29, 2010 at 9:43 PM, Raymond Feng <[email protected]> wrote: >>> >>> Hi, >>> >>> I would like summarize our story for Domain/Node so that we can be on the >>> same page moving forward. >>> >>> A) The key players and steps: >>> >>> 1) The JVM is started >>> >>> 2) Tuscany runtime classes are loaded by the JVM into the one or more >>> class >>> spaces (within a class space, there is at most one class for a given >>> class >>> name): >>> * One class space per JVM (such as Tomcat deep integration or standalone >>> Tuscany launcher) >>> * Multiple class spaces (such as Web applications that package the >>> Tuscany >>> jars) >>> >>> 3) Tuscany runtime is bootstrapped and NodeFactory can be instantiated to >>> encapsulate the ExtensionPointRegistry which manages all the extension >>> points and extensions in Tuscany. >>> * In most cases, NodeFactory.getInstance() returns the shared NodeFactory >>> * You can also call NodeFactory.newInstance() to creates a new instance >>> >> >> We should try to understand the uses of newInstance/getInstance as its >> confusing with both and very easy to not notice which is used or >> realize the difference with which ever you happen to. It would be much >> simpler if we could just have one of those. Do we really need to have >> a shared NodeFactory and the getInstance method? All the uses I can >> see of them could be changed to work with just >> NodeFactory.newInstance() and then manage sharing of that instance >> themselves. This is also going to get more complicated if we start >> passing in things like the registry configuration - what happens when >> getInstance is used but with different configurations? Or changes to >> the environment cause unexpected changes in the app, eg Tuscany is >> packaged in a webapp and getInstance is used but then Tuscany is moved >> to a shared library used by several webapps. >> >> ...ant > >
