Mike Edwards wrote:
Folks,
I made an observation while debugging my composite loading code in the
Spring implementation that gave me pause for thought - and I'd like to
see if the code that handles contributions is behaving the way people
expect.
I found that in my test case, I am pointing explicitly at a particular
composite that I want to use with the test case. However, the
contribution root is much higher up in the file system than the
composite file (org.apache.tuscany..... etc).
The contribution root is taken from the top of the directory tree and
the contribution handling code loads up everything it finds in the
(sub)tree. It then resolves all of the artifacts it finds. This is
done irrespective of whether the artifacts are going to be used. In
particular, it resolves ALL composites found in the subtree - even if
they are not in practice going to get used.
Is this the desired behaviour?
Certainly, it implies a lot more work than necessary (it's equivalent
to eager loading of everything). In a test situation it can be very
frustrating, since if anything in the contribution is in error in some
way, the error gets hit even if the test you're running has nothing to
do with it....
Comments, anyone?
Yours, Mike.
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.
step 2:
- extend that logic to other implementation types as well
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
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.
Makes sense?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
