avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [Patch] #11
Date Wed, 28 May 2003 12:47:51 GMT
Anton Tagunov wrote:
> Hello Berin!
> It great so much of my patches has been applied.
> Hmm.. can ContextManager be used in a _nested_ container?
> Not likely, but theoretically possible.
> Hence, this patch. Do you like what is in the patch on this subject?

I'll look more deeply at the patch in a bit.  For now, I am addressing
the other questions.

> 2) =======================
> AT> LoggerManager, PoolManager, InstrumentManager, MetaInfoManager
> AT> LifecycleExtensionsManager, Queue are passed to the Container
> AT> twice: via contextualize() and via service()
> BL> This duplication originated from having them *originally* passed in as
> BL> context entries.  Later, after looking at what these things really were,
> BL> we determined that we were using a Context to access services.  We
> BL> should go the other way and make them only available via the service
> BL> mechanism.
> I understand they are service because they have an interface and
> a ROLE in it? But we never really release them -- is not that an
> argument for accessing them via Context?

They are *services* because they are entities that perform a function.
They are logically services, and behaviorily services.  The purpose
of the Context is to pass constants to the client.

Admittedly there is some overlap between a Context and the
ServiceManager, and in a future version of Avalon we _might_ merge
the concepts.  However, we should be true to the purpose of these

> And after all they are quite different from user services - these
> are system entities.

Yes they are system entities, but they are services.

> If they are available via ServiceManager someone may configure a
> component implementing a PoolManager or a Queue interface or a
> MetaInfoManager in the normal .xconf file and have nested containers
> use that.

True.  They should be expected to know what they are doing.  I
purposely did not want to limit users of Fortress to *have* to use
the central PoolManager, etc. if they didn't want to.

Everything will be able to be overridden.  That is the beauty of
a heirarchical system.  You have your central container, and you
can have other containers put on top of that.  Your containers
would be allowed to replace any service passed to them within that
level of the hierarchy.

For example:


The root container (A) defines all the core system services.  Container
B or C can simply use them, or define new ones.  If container C defines
new system services, it only affects itself (there is no way for it
to infect the root container).  If container C defines new system
services then it will affect containers D and E because they are C's

Again, the developer who does this should know what they are doing.
9 times out of 10 most people will simply use what is available.

> But should these things really be configured like that?
> I do not mean this is a security violation but rather that
> these things are so deep internal to system things ( like Queue )
> that it looks a bit of order to configure them where normal
> user components are configured.

What if I have a modularly written system like Cocoon?  One container
has a different set of components than the next, and I may want to
use a different pool to manage my component instances.

I think it should be like that.

> So, I personally would have been more comfortable with accessing
> them from the Context. Mainly because we never release them.
> ServiceManager context contract is just to "heavy" in concept
> for such a simple thing as "take what I give you once and live on it".

No its not.  The ServiceManager concept is very simple.  They are
services, not *constants*.  The Context should be a place for data,
not services.

Now, if those services were never in the context to begin with,
would you still be asking about it?  I doubt that, because most
people just go with what they have been given.  It is because
there was a duplication that we had a problem.

> Is there any use to discussion this topic?

I haven't had a convincing argument why services should be in a
context, and I am of the mindset that it was a mistake to use that
"contract" to begin with.

> The patch supplied in this mail goes the ServiceManager
> way and removes the duplicated entities from m_childContext.

Good. :)  It will most likely be applied then.

> 3) ===============================
> This patch also hides *CONFIGURAION and *CONFIGURATION_URI
> from the container implementation.


> 4) ===============================
> I have also updated the main section of the
> inline documentation on ContextManager a bit.
> The inline sections on separate methods still
> are outdated sometimes - but I think this is
> bearable at them moment.


<snip type="patch"/>

"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".

-----Chris Rock

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

View raw message