On Thu, Feb 11, 2010 at 6:43 PM, Raymond Feng <[email protected]> wrote: > Conceptually, the contributions are known to the SCA domain. But they don't > have to be physically stored with the nodes or a central place. We adopt the > URL idea to represent physical locations of contributions. A node just needs > to know a list of URLs for the contributions that can be loaded locally or > remotely. The list of contributions can be built following the import/export > statements of the installed contributions within an SCA domain. > > Now it's a matter how a Node gets its contribution URLs. Such information is > part of the node configuration, which can be provided by one of the > following ways: > > 1) A local node.xml file to list the contribution locations > 2) Programmatically configured using the NodeConfiguration model > 3) Locally discovered from the classpath > 4) Provisioned from the SCA domain dynamically > > We already support 1, 2, and 3. Once we port SCA Domain Manager into 2.x and > (potentially) reuse the DomainRegistry to share the metadata in addition to > the runtime endpoint descriptions, we can support 4). >
>From that list (4) is most interesting to me. I think we should discourage (3) as it circumvents SCA by having the contributions on the classpath (and only works for jar contributions), and (1) and (2) are less useful in a dynamic domain environment and will be less needed if we have (4). So, to get (4) working are there any alternative proposals for how to get it working or modifications for what I suggested earlier in this thread? ...ant
