On Wed, Jul 8, 2009 at 6:32 PM, Raymond Feng<[email protected]> wrote: > Hi, > > I have a few questions on these changes: > > 1) Is the domain name an SCA concept? Isn't the domain URI good enough?
The domain URI is a URI so it can include all sorts of domain configuration including things like the multicast and static routes to other domain nodes which you probably don't want pronting out in all the log messages. (this is something i've started to implement and will post more about soon - so we can configure the dynamic domain including the multicast options, static routes etc via the domain URI and then talk to that domain with an SCAClient using a compatible domain URI) > > 2) The NodeFactory before can create Nodes that are under different SCA > domains (A node configuration has the domainURI property). Why do we need to > have different node factories indexed by the domain URIs? That will lead to > multiple instances of the same extension point or extension in the same JVM. > As an aside from my comment below what is the issue with having multiple extension instances when using multiple factories (which is what we used to do and it worked on)? > The NodeFactory owns the ExtensionPointRegistry that is shared by the nodes > it creates. The extension points and extensions in the registry are mostly > independent of the applications. > > For those have state about the domain/node/app, we create a new instance of > CompositeActivator for each node. If the problem is the EndpointRegistry, we > can add a EndpointRegsitryFactory that can create/get EndpointRegistry by > domain URIs. > All those in (2) are something I've been wondering if we should revisit now that 2.x has progressed on a bit and we've had an opportunity to try it for a while, i think there's some refactoring and tidying up we could do to simplify things now. One issue is the problem of "...mostly independent..." which as it is now to fix properly we'd really need to come up with a new extension type so we can tell which are independent and which aren't. ...ant
