Hi Steve --
I'm looking at the excalibur.assembly code now. This is probably just
going to be a sort of "opinion dump". I will try to preface each opinion
with my interpretation of what's going on, so you can tell what's
based on fact and what's just lost in space ;) Since I'm spewing, I'd
suggest read everything first before responding.
Since I tend to look at the stuff I don't like and ignore the rest, let
me preface all this by saying that this is great stuff and I appreciate
your ongoing efforts to make it architecturally cleaner. Bravo!
Here we go...
.type:
This seems to be the infrastructure for maintaining a collection of
Type objects. I'm guessing that each container will have a single
TypeManager object where the Type information is maintained for
components handled in that container (but in no parent container).
As I read the code I see a lot of inheritance from Service goodies,
some of which show evidence of originally being the Type stuff,
then hacked. Is this inheritance for re-use or inheritance
that really 'means something', i.e., IS-A? I've heard a number of
Java folks say something to the effect that one should "never use
inheritance unless you will 1) instantiate the inherited object, and
2) in some cases use the inheriting object in place of the inherited
object". Inheritance for re-use creates (IMHO) tight webs of
dependency and makes code hard to understand.
DefaultTypeManager.createType() is static but the javadoc refers to
it as 'registering' something. Details... looks like it really just
creates a Type object?
Is it just me or is it weird that Type, which describes Services (as
well as coomponents in general, yes?) also classloads the Class
objects for the services? I would somehow expect that to be part of
the _interpretation_ of the Type data, and hence at a different
level.
.service
This is a somewhat similar critter to Type. Each component has the
ability to declare the service(s?) it provides. Again we're dealing
with a catalog of metadata about the component.
This appears to be a subset of Type data? Is there some reason for
this, for instance is this where Service selection takes place if
multiple components provide the same service?
If you are wanting Type to present a ServiceManager view, so Type is
a kind of facade combining itself with ServiceManager (which is just
another view of Type! eek!) wouldn't it be more flexible to delegate
to a ServiceManager rather than inherit from it? Might express the
design better too. The whole construct feels a bit forced, but I
think I can see where you're headed...
DefaultServiceManager.installService(): shouldn't this be
addService(String)? I don't see what it installs?
So far we have some facilities for accessing metadata. In general they
are isolated from where the metadata is used... yay!
.profile:
In practice the kernel.xml 'profile' aggregates and 'completes'
information about a bunch of Types, so as I start reading this code
I don't know yet if a Profile will be about one component or a
collection of them. What's fairly clear is that, at the individual
component level, we start at the 'bottom' with Type meta-information
and then compose in more concrete information.
It occurs to me that calling the file a 'profile' and calling the
result of composing a Type with a 'profile' file a Profile is a
possible point of confusion.
Ok, with some review I see that a Profile applies to one component.
The terminology is definitely confusing.
The Profile seems to be the result of pulling together all meta and
concrete data about a component, yes?
So by piling the Profile stuff on top of the Type/Service stuff, we
are able to ask the same questions as before, but now the answers
are in some sense complete, all information known about deploying
the component has been assembled into one box, the Profile.
That's enough for now. Gimme some feedback and when my brain recovers
from all this exercise I'll go dig around in .appliance.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
