You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Gerhard Froehlich <ge...@at.ibm.com> on 2002/02/20 11:27:30 UTC
Points to the new ContainerManager
Hi Berin,
I try to understand your ContainerManager, to give
my 0.02 EURO Cents to improve it.
I just follow the red threads, how it is executed at least.
ContainerManager returns a Container Object by calling the
getContainer() method. You return a Object and not ContainerObject,
therefor we nee a extra cast here. Why don't you return just
a Object of the type Container?
The returned Container extends AbstractContainer. AbstractContainer
has initalized all components + handler in the config file and their
mappings added it into the new bucket map.
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
ComponentManager
in the future, or?
The Application calls the lookup method of the returned
ContainerComponentManager,
behind the szene the ContainerComponentManager calls the get(..) method of
the
AbstractContainer, which returns a reference to the ComponentHandler which
matched with the role. It returns again a Object and we need a Cast. Why
not a
returning a Handler Object?
At least some checking happens in the lookup method of the
ContainerComponentManager
which I don't understand yet, but at the end this ComponentHandler returns
a Component.
Hmm I see so far some design improvments, please correct me if I'm wrong:
1. Think about the explicit Casts in ContainerManager and
AbstractContainer.
Are they really necessary?
2. Create a standalone ContainerComponentManager. Here I see the difficulty
to detach it from AbstractContainer (hmm just create a standalone class and
pass a reference from the AbstractContainer to it, or?)
So far so good!
~Gerhard
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Points to the new ContainerManager
Posted by Gerhard Froehlich <g-...@gmx.de>.
Berin,
>>>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.
Indeed...
>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.
<sigh>
>>>:) 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
>rite.
...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
>>>>ComponentManager
>>>>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...
~Gerhard
---------------------------------
Me, Ambivalent? Well, yes and no.
---------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Points to the new ContainerManager
Posted by Berin Loritsch <bl...@apache.org>.
Gerhard Froehlich wrote:
> Hi,
>
>>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
rite.
>>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.....
>>>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
>>>ComponentManager
>>>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.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Points to the new ContainerManager
Posted by Gerhard Froehlich <g-...@gmx.de>.
Hi,
>> Hi Berin,
>> I try to understand your ContainerManager, to give
>> my 0.02 EURO Cents to improve it.
>
>Kool beans! It's not done, but it functions....
...and as always, there is never ever a end...
>> I just follow the red threads, how it is executed at least.
>>
>> ContainerManager returns a Container Object by calling the
>> getContainer() method. You return a Object and not ContainerObject,
>> therefor we nee a extra cast here. Why don't you return just
>> a Object of the type Container?
>
>Two reasons:
>
>1) The type Container is an interface, not a concrete class
>2) Considering all the discussion about being limited to implementing
> a Component interface is too binding, I thought it best not to
> introduce that limitation here.
>
>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).
>> The returned Container extends AbstractContainer. AbstractContainer
>> has initalized all components + handler in the config file and their
>> mappings added it into the new bucket map.
>
>:) 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?
>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".
>> 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
>> ComponentManager
>> 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 Application calls the lookup method of the returned
>> ContainerComponentManager,
>> behind the szene the ContainerComponentManager calls the get(..) method of
>> the
>> AbstractContainer, which returns a reference to the ComponentHandler which
>> matched with the role. It returns again a Object and we need a Cast. Why
>> not a
>> returning a Handler Object?
>> At least some checking happens in the lookup method of the
>> ContainerComponentManager
>> which I don't understand yet, but at the end this ComponentHandler returns
>> a Component.
>
>The purpose of the ComponentManager is to return a Component. The
>ComponentHandlers are still effective regardless of whether we return
>Object (as the push is now for framework) or Component. It's a small
>price to pay for that future proofing.
>
>
>
>> Hmm I see so far some design improvments, please correct me if I'm wrong:
>> 1. Think about the explicit Casts in ContainerManager and
>> AbstractContainer.
>> Are they really necessary?
>
>Do you have some specific ones you are concerned about? I prefer to
>deal with specific types if I can...It just makes things easier. It's
>not hurting us *that* much. By removing certain explicit casts, we will
>only be gaining a couple more milliseconds on the test time for 50,000
>lookups and releases.
see above
>> 2. Create a standalone ContainerComponentManager. Here I see the difficulty
>> to detach it from AbstractContainer (hmm just create a standalone class and
>> pass a reference from the AbstractContainer to it, or?)
>
>:/
>
>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.
>> So far so good!
>
>:)
>
>Thank you. I look forward to when this can be done and it be much more
>elegant than the ECM.
Cocoon land too, I swear ;)
~Gerhard
"Sorry, but my karma just ran over your dogma."
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Points to the new ContainerManager
Posted by Berin Loritsch <bl...@apache.org>.
Gerhard Froehlich wrote:
> Hi Berin,
> I try to understand your ContainerManager, to give
> my 0.02 EURO Cents to improve it.
Kool beans! It's not done, but it functions....
> I just follow the red threads, how it is executed at least.
>
> ContainerManager returns a Container Object by calling the
> getContainer() method. You return a Object and not ContainerObject,
> therefor we nee a extra cast here. Why don't you return just
> a Object of the type Container?
Two reasons:
1) The type Container is an interface, not a concrete class
2) Considering all the discussion about being limited to implementing
a Component interface is too binding, I thought it best not to
introduce that limitation here.
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.
> The returned Container extends AbstractContainer. AbstractContainer
> has initalized all components + handler in the config file and their
> mappings added it into the new bucket map.
:) 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.
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.
> 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
> ComponentManager
> 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).
> The Application calls the lookup method of the returned
> ContainerComponentManager,
> behind the szene the ContainerComponentManager calls the get(..) method of
> the
> AbstractContainer, which returns a reference to the ComponentHandler which
> matched with the role. It returns again a Object and we need a Cast. Why
> not a
> returning a Handler Object?
> At least some checking happens in the lookup method of the
> ContainerComponentManager
> which I don't understand yet, but at the end this ComponentHandler returns
> a Component.
The purpose of the ComponentManager is to return a Component. The
ComponentHandlers are still effective regardless of whether we return
Object (as the push is now for framework) or Component. It's a small
price to pay for that future proofing.
> Hmm I see so far some design improvments, please correct me if I'm wrong:
> 1. Think about the explicit Casts in ContainerManager and
> AbstractContainer.
> Are they really necessary?
Do you have some specific ones you are concerned about? I prefer to
deal with specific types if I can...It just makes things easier. It's
not hurting us *that* much. By removing certain explicit casts, we will
only be gaining a couple more milliseconds on the test time for 50,000
lookups and releases.
> 2. Create a standalone ContainerComponentManager. Here I see the difficulty
> to detach it from AbstractContainer (hmm just create a standalone class and
> pass a reference from the AbstractContainer to it, or?)
:/
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.
> So far so good!
:)
Thank you. I look forward to when this can be done and it be much more
elegant than the ECM.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>