avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerhard Froehlich" <g-froehl...@gmx.de>
Subject RE: Points to the new ContainerManager
Date Wed, 20 Feb 2002 15:43:56 GMT

>>>The ContainerManager will create any arbitrary Container.  Whether it
>>>uses the Container interface directly i.e. Container.WORK_DIRECTORY,
>>>or it extends it is up to the developer.
>>>You will have to cast--and in the end I think this is best.
>> Hmm well yes and no. It's OK that the Component interface disappears
>> at the end.
>> But this is more "how to implement Avalon", because I see the user running 
>> first into a ClassCastException here. You force in the code of the
>> ContainerManager:
>>   private Container m_containerInstance;
>> and you return Object, IMHO that's not really "typesafe" (I know Java is
>> typesafe, but I guess you know what I mean).
>Oops.  I need to make m_containerInstance an Object....
>Seriously, Container is not a useful interface to interact with.
>Therefore, the user Must cast the instance to a useable interface.


>There is no way of creating a one-size-fits-all model (I wish there
>were).  Every invoker (command line, servlet, embedded block, etc.)
>will have a different work interface that they use for the container.


>>>:) It can extend AbstractContainer.  The purpose of AbstractContainer
>>>is to simplify the initialization process--but be flexible enough to
>>>retrofit your custom mappings on top of it.
>> Hehe as you see I oriented myself at the TestCase. Can you describe
>> me in short words, how we would implement this new beans in Cocoon.
>> Writing our own Container and integrate the CocoonComponentManager, I
>> guess?
>Well, the ComponentManager implementation would *still* be the
>ContainerComponentManager.  The only difference is that the Cocoon
>container would recognize that certain roles will be ComponentSelector
>accessed, and it will have a reference to the ContainerManager for the
>Sitemap.  Remember that the Sitemap is also a container in its own

...back in the code...

>>>In the end it is not required.  Anyone is free to specify any arbitrary
>>>class.  However, if it wants to take advantage of the ContainerManager's
>>>work, it should implement Contextualizable.
>> Yep I see. But see my points above "typesafe".
>I will fix that problem.  Until we have generics in java, we will still
>be forced to cast.....

C# has it, therefor Java too soon ;).

>>>>The Container returns the ComponentManager. Behind the szene
>>>>following happens. AbstractContainer creates a ContainerComponentManager,
>>>>which is a inner class in the moment. I guess it will be a real
>>>>in the future, or?
>>>Its implementation is tied to AbstractContainer, so the virdict is still
>>>out on that.  I do *not* want to expose public get/has methods on the
>>>AbstractContainer, which is what would be necessary if the 
>>>ContainerComponentManager is external.  It would have to be coded to an
>>>interface (which demands public methods).
>> That means, for me as user I have to implment my own Container and integrate
>> then my own ComponentManager to get the full features. Sry but it seems
>> I didn't understand it full.
>> However here I see space for improvement, maybe we can take some labor from
>> the user and make it more pluggable.
>The ContainerComponentManager/Selector merely delegates its logic to the
>Container.  Therefore the Container only has to change how the
>ComponentHandlers are mapped--or directly override the get/has methods.
>If you need to do tricky things, it is still possible--without having
>to worry about the ComponentManager/ComponentSelector implementations.
>It is easy to write a one-size-fits-all implementation for those.
>>>I don't see the ContainerComponentManager being used outside the context
>>>of the AbstractContainer.  The only reason for separating it would be to
>>>shorten the length of the AbstractContainer.java file.  I like the
>>>ability to have tight controls on access points for instantiating the
>>>ContainerComponentManager.  It's whole purpose is merely to delegate
>>>calls back to the Container.
>> Hmm OK I understand you here...but as mentioned above, maybe there is way
>> to take away some labor of the user and make it more pluggable without
>> getting unsafe.
>> Just to think about.
>I don't think the ComponentManagers/ComponentSelectors themselves should
>be made pluggable.  The default behavior for the implementation is all
>contained in the Container, and if that needs to change it is easy to
>do so.

Ok I think there are some major understanding issues on my side.
...back in the code...


Me, Ambivalent? Well, yes and no.

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