Jean-Sebastien,
Comments inline...
Jean-Sebastien Delfino wrote:
Mike,
Good timing, as I am actually starting to work on some lazy +
incremental loading and resolution of SCA assemblies. I had the
following in mind:
step 1:
- change the CompositeProcessor to not resolve its references to others
until it's actually referenced by another composite (through an
<include> or an <implementation.composite>) or included in the domain as
a deployable.
Yes, this is an essential first step. Resolution should cascade down
from composites that are actually deployed. Mere presence in a
contribution should have no significance in this process.
step 2:
- extend that logic to other implementation types as well
Agrred
step 3:
- not even read the entire composite until it's needed, just register
its name in the ArtifactResolver and stop there (we just need the top
level element to know its name), then actually read and process its
contents later in the resolution phase
It may not ultimately gain us much in performance, but it will make
testing a damned sight easier. Testing can probe small pieces of a
larger configuration - the last thing you want is some error in one part
of a contribution screwing up tests running against some other part.
I have started to experiment with step 1. I'm not sure yet about step 3
as I'll have to run concrete tests to evaluate what we actual gain by
doing it.
That covers the lazy loading part.
Another aspect I'm starting to look into is incremental changes to an
SCA domain, as we add/remove contributions, add/remove composites
to/from an SCA domain in memory model, we need to configure/unconfigure
bindings, wire/unwire references, break/fix pieces of the assembly
model, incrementally. I'll post more ideas later on the subject, in a
different thread.
This calls for another thread of discussion. This is required. Part of
the thinking here is that there may be different kinds of repository for
contribution material - some "passive" like a file system, some "active"
like a formal repository. Operations of adding/updating/removing
elements in the repository should generate events that signal changes to
the runtime, which the runtime must then act on.
Another part of the thinking here is that in a distributed runtime,
different parts of the Domain configuration will be targeted at
different runtime nodes. There is a question about how it is decided
that a given part of the domain ends up on a given node.
Makes sense?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
