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 objects.
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:
A-+B
+C+D
+EThe 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 children.
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.
Ok.
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.
Ok.
<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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
