avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: Container Abstraction (was RE: ContainerUtil)
Date Wed, 15 May 2002 23:51:59 GMT
> From: Leo Simons [mailto:leosimons@apache.org] 
> > > How much of this is defined for an interface, and how much is
> > > defined for the implementation. Can you only require an 
> > > interface implementation, or are you allowed to require a 
> > > specific interface implementation? (should be the former, but 
> > > is currently non-defined for a lot of software)
> > 
> > MetaInfo is separate from interfaces, or at least should be.
> keyword here (and most of the discussion) "should". How much 
> should you push avalon users towards the "best" way to do stuff?
> (how much are we api, how much are we framework? etc etc)

Good question.  However, I have noticed that users of the framework
do better with meta info than they do with interfaces.  The whole
interface approach is also at odds with the goal of not inheriting
meta info from the parent class.

> > > > Lastly, the lifestyle info--which I believe is where you are 
> > > > having
> > > > problems coming to an acceptible abstraction.
> > > 
> > > Well, deciding a component offers only one service is
> > > probably quite a problem for some people (currently this 
> > > doesn't have to be). This is one of several per-container 
> > > choices that don't fit in the list you made yet, methinks.
> > 
> > It's cleaner that way.  SOC and all that.
> Linux Torvalds wrote something like (paraphrasing here) "not 
> many people are able to work with properly designed software 
> all the time, or even most of the time".

Perhaps, it is because it was not the proper design, really.
The proper design (in my book) is the one that meets the most
needs without introducing too many potential errors.

> You have to use MFC, don't you?

Yes, and as anyone can tell you--it is not well designed at all.
Using Magick++ (from ImageMagick [http://www.imagemagick.org])
is a dream compared to the general nastiness you have to go through
with MFC.

I actually wonder if MFC was really ever designed at all?

> If there's this piece of software that performs multiple 
> services (say, JBoss), and you want to wrap it for use in 
> avalon, well...

Let me ask you:

How do you interact with it?  DO you provide an API via an interface?
Is that interface just a way for the phoenix kernel to control the
Jboss kernel?

Just because you have wrapped Jboss into Phoenix doesn't mean that
there is necessarily an interface for each service it provides.

There is also the possibility of providing interfaces for each of
the main services it does provide like JMS, EJB, etc.  That interface
can delegate to many smaller components which in turn delegate to the
main controlling component.

That way, you can change implementations for specific parts of the
Jboss conglomerate if you want later on.

There are many ways of doing the same thing.  It is cleaner to only
have to worry about one interface at a time.  There are exceptions,
but the exception should not become the rule.

> > > > The reason I have to ask about factory method is that if a
> > > "component"
> > > > instance cannot be reused, why is it created as a component?  
> > > > There
> > > > are other more effective ways of dealing with those objects.
> > > 
> > > ie ComponentManager, right?
> > 
> > Huh?
> Factory is a creational pattern we replaced with something 
> better - ComponentManager. Different setup, overlapping use case.

No.  ComponentManager is only an interface to get the components.
The Container handles the responsibilities of creating the component

Just because we have a Container that happens to also implement the
ComponentManager interface (ECM) doesn't mean we should merge the

They are distinct concepts even if they happen to be implemented

> > If you have to go through a full lifecycle for an object that is 
> > created with the interfaces and contracts of a component, but it 
> > cannot be reused or shared, then we have a problem.  The 
> Cocooners can 
> > tell you beyond a shadow of a doubt that such a "component" 
> is a major 
> > performance sink.
> What if you have a singleton framework that uses factories 
> throughout? Anyway, you'll get my point now...

Hopefully you see what I am getting at.

> > > And what is "lifestyle" here? It seems that part of the
> > > problem is the wide definition. Seems you've defined it as 
> > > "possible creation and usage scope" here...
> > 
> > Yes.  That is always what I have meant when I coined the term 
> > lifestyle--Refering to the creational policies.
> okay:
> The Component lifestyle defines the creational policy for Components.
> That needs to go on the website =)

I thought it was.  Perhaps it should be clearer.

> > Anything higher than that level should be delegated to a parent 
> > container.
> When you start talking about common frameworks....
> Phoenix does a lot with classloaders (should do more, 
> really). One benefit would be we can finally create some 
> common components for access by all applications (or even 
> arbitrarily marked applications).

So how does it handle Classloader scope?  I don't see how
such a thing can be accomplished without a static accessor.

I also see it as potentially harmful because it is not under the
control of a particular container.  It is a potential security
sticking point.

I don't think a Component should dictate that it needs to be
at any scope higher than the container that controls it.  It is
not the Component's concern.  It can specify that it is safe
to implement that way--but it should not count on it.

The whole concept of lifestyle is to allow performance and
memory enhancements based on the minimal safety required for
a component.

Just because a component is marked THreadSafe doesn't mean that
the container doesn't have the righ to use a PerRequest policy
for it.  It might be wasteful, but it is possible.

> > We try to steer clear of Singleton by static 
> accessor--which is really 
> > the only way we can ensure one instance of a component per 
> > classloader.
> Except if your container manages the classloaders (ie phoenix 
> has the option).

And how does it ensure one instance per classloader?

> > A ComponentManager should not generate components.  It should only 
> > manage access to them.  That is one of the reasons Fortress was 
> > created (to migrate
> > from ECM).  A factory is a tool that a Container can use to generate
> > instances
> > of components.  That is really all it is.  ECM is a 
> container, so that
> > does
> > not violate my statement.
> uhuh. Yet a *lot* of software doesn't have a ComponentManager 
> but uses a factory with a pool added to the mix...just that I 
> would like the model to have a provision for that....

You just made my point.  The ComponentManager is only a lookup
mechanism.  Nothing more.

The Container is the logical piece of the system that decides what
component to create and when.

That is why ECM has poisoned our minds :)  It confuses the point
by mixing container and lookup mechanism concerns.  That is what
I hoped to fix with Fortress.

> > Reusable as I have referred to it above means that the 
> component can 
> > litteraly be used again.  The "Factory"/"SingleThreaded" 
> components in 
> > ECM does not reuse instances in any way.  That is bad.
> > 
> > Anything more than that is adding too much to "reusable".  We might 
> > have to capture that information separately.
> you okay with "RuntimeReusable"? I know it's a common 
> concept...just know no common name.

I guess.  We need to do this in passes.  Once we stick the basic
stuff down, we go over it and see what we like and don't like.

> > > Poolable    - multiple instances can live within the same 
> scope; they
> > >               are reusable.
> > >               related framework interfaces: Poolable,
> > >               Reconctexualizable, Reconfigurable, 
> Reparameterisable
> > 
> > Multiple instances in a pool.  the scope usually inferred 
> by this is 
> > "per request".  The Pool is an implementation detail of 
> "per request" 
> > scope of a component.
> I think this is limiting. In this "component scope"-based 
> system, a ThreadPool doesn't fit "request".

You "request" a thread of execution don't you?
Perhaps the word we need is "per access".

> > > A component has one or more scopes in which it is usable;
> > > "request" is the minimum (and implied). container, 
> > > classloader and system imply thread safety. If a class 
> > > implements the Re-XXX interfaces for all the XXX interfaces 
> > > it implements, this implies runtime reusability. If a 
> > > component is runtime reusable and the parts of its context 
> > > that are unique within its scope are thread safe, the 
> > > component is poolable. Poolable is never implied.
> > 
> > I think we have some stuff here to clean up.  First of all, 
> I want to 
> > not consider the concepts of classloader scopes or any 
> scope that is 
> > greater than the container.
> too bad...phoenix really needs to.
> When you want to do guarantee isolation of components you 
> have to use ClassLoaders - they're the only functionality in 
> java that can guarantee IoC doesn't break.

Yes, but what component needs to be declared at that level?
I am not aware of any situation that would be better served that
way.  Perhaps you could enlighten me ;P

> > IF there are to be components that need to be shared across 
> multiple 
> > containers, the child containers should ask the parent for them.
> of course. What about a container for ClassLoaders?


I thought a container took care of all the nitty gritty details
of classloader and instance management.

> > > - implementation version (optional, default: none)
> > > - required work interface implementations (optional, 
> default: none)
> > 
> > Why?  A component should not worry about what implements a work 
> > interface. That is the administrator's and container's 
> responsibility.
> ease of porting existing 'compatibility crap' that doesn't 
> follow our rules. Like stuff in Tomcat. You need to specify 
> which implementation you need as well as which interface 
> version (in practice, these are coupled in like 99% of software).

This might be a need for Phoenix, but for the general use case
(i.e. smaller components) it is not necessary.

> > If we want to allow the liberty for the conatainer to manage those 
> > policies, we need to instead use propertis.  In this case, 
> a component 
> > can be sharable, threadsafe, reusable, and/or perrequest.
> Again, the table you made doesn't have a place to fit all of 
> phoenix in. My thoughts were just, well, thoughts (which I 
> had while baking pancakes, talking on the phone, and watching 
> the news at the same time). Neither will do =)

Which is why I put the table out there.

> > > Seems like a reasonable abstraction to me. Coming back to my
> > > earlier question, it seems that we should disable inheritance 
> > > of meta info; redefinition of this meta info for child 
> > > components should be rather trivial, don't you think?
> > 
> > Absolutely. +1
> some points I think we all agree on (ie the discussion is 
> muddy so lets start with stating the obvious):
> - manage versioning in some way (pragamatic support conflicts 
> with clean design wrt implementation specs)
> - "The Component lifestyle defines the creational policy for 
> Components."
> - we call these two "common component meta information"
> - we define them through custom meta information rather than 
> through std java features
> - we want an abstraction of the meta information to make 
> porting of components between containers easier
> - we want this to be a part of a more general common ground 
> or abstraction for containers
> - I feel the abstraction should define a way to support any 
> lifecycle, rather than lifecycles for containers with a limited scope
> - inheritance will not be used for meta information as that 
> creates too many problems
> - we instead will provide some tools that 
> autogenerate/morph/edit meta information (providing features 
> like inheritance where required)
> - the abstraction should allow support for multiple ways of 
> defining meta information, like different xml languages, 
> different sources, management protocol, etc
> - we don't want marker interfaces
> - we need to make it quite clear to the average avalon user 
> which container is best for which situation
> I'm going to bed =)

Sounds good.

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message