You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Gary Shea <sh...@gtsdesign.com> on 2002/11/22 22:59:59 UTC
[merlin] new appliance code opinion/ideas dump
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [merlin] new appliance code opinion/ideas dump
Posted by Stephen McConnell <mc...@apache.org>.
Stephen McConnell wrote:
>> 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.
>>
>
> Have been thinking about the same thing. Bottom line there is no
> dramtic or fundimental reason to have this as inheritance based. In
> fact I've been reworking TypeManager locally to turn it into a
> component. This follows the thinking in my post about bootstrap
> versus pluggable components that provide core services. If the
> pluggable things are always full components, then there is no reason
> why one should not allow an alternative TypeManager (or XxxxManager)
> component.
>
> For the moment I suggest maintaining the inheritance approach while I
> turn things into conponents and then look at this again in a few days.
But thinking a little more .. an appliance manager could aggregate a
profile manager could aggregate a type manager could aggregate a service
manager.
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [merlin] new appliance code opinion/ideas dump
Posted by Stephen McConnell <mc...@apache.org>.
p.s. I've moved all of the org.apache.excalibur.assembly.* content to:
CVS: avalon-sandbox
Project: assembly
Java Package: org.apache.avalon.assembly.*
I've updated the docs and have put in place unit tests on service, type,
and profile managers.
Cheers, Steve.
Stephen McConnell wrote:
>
>
> Gary Shea wrote:
>
>> On Fri, 22 Nov 2002, at 23:57 [+0100], Stephen McConnell
>> (mcconnell@apache....:
>>
>>
>>> There is a distinct difference between Type and Service. Imagine for
>>> example a jar file container the service org.omg.CosTime.TimeService.
>>> The TimeService interface is described by a class and a Service is the
>>> meta info about the service. This service can exist indepedently of an
>>> componet implemetation class (i.e. the service interface and meta
>>> defintion can exist in a seperate jar from a component the provides the
>>> service). On the other hand, types can declare that they provide
>>> services - which basically means that a type manager when registering
>>> types in its repository needs to be able to access/register services
>>> from a service manager.
>>>
>>
>>
>> Are you saying that merlin supports Service jar manifest entries? Like:
>>
>> Name: blah/blah/someinterface.class
>> Avalon: Service
>>
>
> Yep.
>
>
> If your doing something like navigation of a container, components and
> services, a service definition established from an Avalon: Service
> manfest entry allows the introuction of supplimentary attributes - but
> its totally optional - a service production declaration on a component
> type is sufficient.
>
> Cheers, Steve.
>
>>
>> That's the only way this distinction makes sense to me, otherwise no
>> information about the service's work interface (even its class name!) is
>> needed for assembly, and all information about a Service is derived from
>> various Type sources.
>>
>> Regards,
>>
>> Gary
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>>
>>
>>
>>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [merlin] new appliance code opinion/ideas dump
Posted by Stephen McConnell <mc...@apache.org>.
Gary Shea wrote:
>On Fri, 22 Nov 2002, at 23:57 [+0100], Stephen McConnell (mcconnell@apache....:
>
>
>>There is a distinct difference between Type and Service. Imagine for
>>example a jar file container the service org.omg.CosTime.TimeService.
>> The TimeService interface is described by a class and a Service is the
>>meta info about the service. This service can exist indepedently of an
>>componet implemetation class (i.e. the service interface and meta
>>defintion can exist in a seperate jar from a component the provides the
>>service). On the other hand, types can declare that they provide
>>services - which basically means that a type manager when registering
>>types in its repository needs to be able to access/register services
>>from a service manager.
>>
>>
>
>Are you saying that merlin supports Service jar manifest entries? Like:
>
>Name: blah/blah/someinterface.class
>Avalon: Service
>
Yep.
If your doing something like navigation of a container, components and
services, a service definition established from an Avalon: Service
manfest entry allows the introuction of supplimentary attributes - but
its totally optional - a service production declaration on a component
type is sufficient.
Cheers, Steve.
>
>That's the only way this distinction makes sense to me, otherwise no
>information about the service's work interface (even its class name!) is
>needed for assembly, and all information about a Service is derived from
>various Type sources.
>
>Regards,
>
> Gary
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [merlin] new appliance code opinion/ideas dump
Posted by Gary Shea <sh...@gtsdesign.com>.
On Fri, 22 Nov 2002, at 23:57 [+0100], Stephen McConnell (mcconnell@apache....:
> There is a distinct difference between Type and Service. Imagine for
> example a jar file container the service org.omg.CosTime.TimeService.
> The TimeService interface is described by a class and a Service is the
> meta info about the service. This service can exist indepedently of an
> componet implemetation class (i.e. the service interface and meta
> defintion can exist in a seperate jar from a component the provides the
> service). On the other hand, types can declare that they provide
> services - which basically means that a type manager when registering
> types in its repository needs to be able to access/register services
> from a service manager.
Are you saying that merlin supports Service jar manifest entries? Like:
Name: blah/blah/someinterface.class
Avalon: Service
That's the only way this distinction makes sense to me, otherwise no
information about the service's work interface (even its class name!) is
needed for assembly, and all information about a Service is derived from
various Type sources.
Regards,
Gary
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [merlin] new appliance code opinion/ideas dump
Posted by Stephen McConnell <mc...@apache.org>.
Gary Shea wrote:
>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).
>
At this stage the relationship between a container and a TypeManager is
undefined. If you follow the structure of the Merlin system - then yes,
one container, one type manager etc. However, I envisage the potential
for a container to manage multiple type managers - maybe one for
internal services, another for contained compoents, and maybe another
for published components. Whatever - the pricipal is that its a manager
of a set of types (class + metainfo).
>
> 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.
>
Yep - cleaning up of docs from cut-and-paste is still pending.
:-)
> 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.
>
Have been thinking about the same thing. Bottom line there is no
dramtic or fundimental reason to have this as inheritance based. In
fact I've been reworking TypeManager locally to turn it into a
component. This follows the thinking in my post about bootstrap versus
pluggable components that provide core services. If the pluggable
things are always full components, then there is no reason why one
should not allow an alternative TypeManager (or XxxxManager) component.
For the moment I suggest maintaining the inheritance approach while I
turn things into conponents and then look at this again in a few days.
> DefaultTypeManager.createType() is static but the javadoc refers to
> it as 'registering' something. Details... looks like it really just
> creates a Type object?
>
Yep - javadoc is incorrect. This is simply a convinience operation to
create a new type without having to know about how the type is
constructed. The static methods do not register anything.
>
> 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.
>
>
Umm - would it be ok if I answered "it's just you"?
;-)
There is a distinct difference between Type and Service. Imagine for
example a jar file container the service org.omg.CosTime.TimeService.
The TimeService interface is described by a class and a Service is the
meta info about the service. This service can exist indepedently of an
componet implemetation class (i.e. the service interface and meta
defintion can exist in a seperate jar from a component the provides the
service). On the other hand, types can declare that they provide
services - which basically means that a type manager when registering
types in its repository needs to be able to access/register services
from a service manager.
>.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.
>
A catalog of services (indepedently of the ability of a system to
provide solutions or implemetations)
>
> This appears to be a subset of Type data?
>
No. Related but not subset. A Type declares services that it provides
via 0..n ServiceDescriptors. A ServiceDescriptor referrences a Service.
When you get into characterising a service verus characterising "the
provision of a service", you end up seperating attributes between a
service defintion and the declarion of service provisioning.
> Is there some reason for
> this, for instance is this where Service selection takes place if
> multiple components provide the same service?
>
>
Two main reasons:
1. physical seperation of service defintion from type
2. ability to have multiple service versions that coexist across
different classloaders
> 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...
>
>
I have the same feeling ( a liitle "forced"). Inital objective was to
sketch out interfaces and throw in a default implemetation. These
things need to be worked up but I really wanted to put something out
there for discussion as opposed to comming up with something perfect.
> DefaultServiceManager.installService(): shouldn't this be
> addService(String)? I don't see what it installs?
>
>
Fixed - thanks.
>
>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.
>
A profile is about deployment scanario.
name + type + configuration + context + logging setup, etc.
> 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.
>
>
A Profile has a 1-1 relationship with a Type.
A Type may be referenced my many Profiles. For example - take class X
(the type) and using congiuration A is represented as deployment Profile
P1. Taking class x (the type) and using configuration B is represented
as deployment profile P2. The profiles simply represent potential
solutions for establishment of a particular appliance. Thet do not
represent deployed solutions - its just the collection of information on
which deployment (via an appliace) can be made.
> Ok, with some review I see that a Profile applies to one component.
> The terminology is definitely confusing.
>
>
:-(
More javadoc?
Something that makes it clear the a Profile is "the named collection of
information for the potential deployment of a specific componet type".
> The Profile seems to be the result of pulling together all meta and
> concrete data about a component, yes?
>
>
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.
>
>
Yes.
>
>That's enough for now. Gimme some feedback and when my brain recovers
>from all this exercise I'll go dig around in .appliance.
>
>
Which is not yet complete - what's missing is accessors on the Appliace
interface for the service the a client needs (and generally speaking the
client is the implimentation of a framework ServiceManager or
ComponentManager.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>