avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Date Tue, 08 Jan 2002 16:12:11 GMT
I think we have come to the conclusion that Poolable interface is not
helpful, and makes certain things more difficult.  The remainder of the
discussion has been what *else* people have found limiting.  If Avalon
is not to be moved into absolescence, it must learn from its limitations.
Periodically we need to discuss what works and what does not work.

That is why we have the Lifestyle interfaces (real need) and Namespaces
for Configuration objects.

Paulo Gaspar wrote:

> Hi Berin,
>>Which is exactly what ExcaliburComponentManager does.  There are necessary
>>improvements, but they will come.
>>
> 
> It is quite different:
>   I have also a kind of "ComponentHandler", with a different name but 
>   which implementation is also dependent on the type of the component's 
>   lifecycle.


The ComponentHandler uses a ComponentFactory that handles the initialization
and destruction phases of a Component.  The Container is responsible for the
runtime phases (i.e. suspend()/re*()/resume() cycles).  In the "big" picture,
the ComponentHandler determines when to create a new instance of a Component
and when to destroy an instance of a Component.  The Container works with
the ComponentHandler.

ExcaliburComponentManager/Selector have the three lifestyles: ThreadSafe,
SingleThreaded, Poolable.  The Poolable interface we all agree is not beneficial
to the system as a whole.  Also, having Components that are used only once
is not a good pattern as it adds undue stress on the garbage collecter and
only adds to the latency of looking up a Component.  Therefore the point
of the original thread was to merge SingleThreaded and Poolable so that
all SingleThreaded Components are pooled.



>   There is no "DefaultComponentFactory". Each type of component has its
>   specific factory. This factory takes care of configuration too.


In essence, you have merged the ComponentHolder and ComponentFactory into
one class.  The ComponentFactory gives the Configuration information to the
Component.  This works well in most situations.



>   (Much of this configuration cab be eased using a "configuration bean"
>    a Configurer and a Converter, like Peter did on Ant Myrmidon proposal
>    ...although my code already went a lot beyond what was there some 3 
>    months ago.)


:)  This is one of the things I am working on.  A completely managed solution.
By using a number of "Managers" all working independantly on different parts
of the system.  That way, the users of the Managed Container only have to
worry about the Components and how they are mapped together in a system--all
reconfiguration and logger remapping are done automatically.

Perhaps this goes beyond what you are thinking of.  However, such a managed
system is able to make expensive decisions about the most efficient way to
allocate resources asynchronously from the rest of the system.  That way
latencies involved in lookup and releasing of components are minimized to
simple get() and put() calls on a Map.



>   My "ComponentHandler" still takes care of lifecycle management 
>   operations and strategies, like:
>     - Initializing, starting, stopping, disposing, etc.
>     - Using only one instance for thread safe components and always a new
>       instance for the others.


That is the implementer's perogative on how they want to manage their system
or define Components.  However, if your system does not work with any Avalon
Component, then you have lost the ability to use a number of well tested
Components.  Hopefully you have not lost that ability.




> Of course.
> I am just using the opportunity to throw some doubt on other markers too.
> =;o)


Which is why I changed the name of this thread.



>>>>The next question is why make everything more "bean" like.  JavaBeans,
>>>>while usable, do have a distinct disadvantage in that they are not
>>>>clearly marked.
>>>>
>>>>
>>>I do not see much use for most pure (no methods) markers. I ended up
>>>deleting them some 3 months ago and I do not miss them a bit.
>>>
>>The Idea of a Component being marked explicitly as a Component does
>>have some value to me.  It forces you to think in terms of what a 
>>Component
>>is supposed to do.  That way you don't run into the JavaBeans antipattern
>>of everything (data objects included) being a Bean.  You encapsulate
>>data accessor logic apart from the data itself.  It is not a correct
>>pattern to implement Data as a Component.
>>
> 
> The above mentioned specific factory per component class takes care of 
> that.


It seems like alot of work for a Component writer to create a new factory
for each Component.  I beleive that slows development time unnecessarily.
By having one generic ComponentFactory, you can focus on more important
issues like Component interaction, and how it should handle when Components
are not available.



> Precisely, although I often (ab)use an abstract class that puts 
> together 3 of them (Initializable, Disposable and Startable) just to
> ease implementing some LifeCycle validation:
>   - Checking if the component is active;
>   - Making sure it is not started before being intialized;
>   - etc.
> 
> Of course that I end up with some empty methods, but most of those
> components have no performance issues.


Again, your perogative to do this.  I am sure you do this so that you
limit the number of Factories you have to create.  Again, I think it
is wasteful to have to write a Factory for every type of Component,
but it is your perogative as to how you manage your Components.  Avalon
as a framework does not enforce a specific algorithm--only a specific
interface



>>>>A Role defines the logical use of the Component in the system.  If
>>>>the Role interface extends the Component interface, all the hard
>>>>work is done for you and you don't have to recast the Component
>>>>to release it.
>>>>
>>>I understand and I do not have to recast any component since my 
>>>component manager returns Object instead of Component.


Of course, in either case, you have to cast it to use it.


>>>
>>And if your Role interface extends Component, you have the same
>>convenience--while maintaining the protection that forces you to
>>separate data and the interface to get the data.
>>
> 
> Again, the above mentioned factory makes my aware of that.


I won't belabor this point.  I just know that a "ComponentManager"
that deals with Objects is open to abuse by less disciplined people
than yourself.  For a framework, I am not convinced if it is
proper.  Of course, I am open to understanding the motivation for
it.



>>>Since I focus on building components that are as independent from 
>>>the framework as possible (which makes them more reusable) I always
>>>use a component factory. Even if only to take care of configuration.
>>>
>>That's fine.  I just would have a hard time with a ComponentManager
>>that is really simply an ObjectManager.  That would be bad.
>>
> 
> I believe it is a ComponentManager... and one with several extra tasks.
> But that has to do with the specifics of this project.


By extending the ComponentManager interface, you can handle those extra
tasks (hopefully).

The problem with ExcaliburComponentManager is that it is not *just* a
ComponentManager, but it is also a Container.  That is merging too many
concerns, and I want to separate the Container code from the Component
Management code.  It is best when the ComponentManager only manages access
to Components.



>>>I am only focusing on the parts of what I have that can be done in 
>>>Avalon since what I have is quite a bit different. 
>>>
>>How much so?
>>
> 
> Quite a lot because of the way I choused to lookup components (by role
> AND a name), with many components for the same role, some with default
> configuration parameters, component tracker per requester, etc.


I have some questions on the lookup by role and name.  Because Avalon
as a framework is only concerned with the interface and enough contracts
to specify results (not methodology), the default configuration params and
component tracking is orthagonal to this discussion.  You are perfectly
able to do that and have your system be fully Avalon compliant.

The question comes when you feel it is necessary to change the interface
of the ComponentManager.  Either Avalon is not doing something correctly,
or it may be able to learn something.

Therefore, I want to get some more information on why you felt it necessary
to change interfaces.

As to Component Management, we have discussed many ideas before we came up
with what we have now.  Among them were JNDI, strict ComponentManager (i.e.
it was considered wrong to have multiple components for a role),
NamedComponentManager (with your lookup by role and name), and the current
ComponentManager/Selector approach.

Many times, use has tempered our views of the world.  Our personal experience
deems what is more natural for us to use, and how we view our world.  Cocoon
started out down the path of the NamedComponentManager.  I don't think it
was correct for the NamedComponent interface, but it did have a certain
simplicity.

The question arose when we have n-dimensional needs for gaining access to a
Component.  For instance, a ComponentManager addresses one dimension: role.
ComponentSelector defines a purposely loose contract so that you can use
any object or query objects to address all the extra dimensions that might
arise for future systems.

The ComponentSelector adds a little bit of Complexity to the overall system,
and an additional lookup step.  In my communications with other CBD frameworks,
there are other approaches we have not considered yet (or if we have, I don't
recall).

It is most common to use JNDI in J2EE frameworks.  However, we have already
ruled that out for Avalon as it is too heavy for resource constrained
environments.

Another interesting approach is the use of a Query object to lookup the
required component.  The one Query object addresses as many dimensions as
is necessary in the system to lookup the correct component.  This can include
role, name, locale, and session information into the one lookup request.

The manager, as it were, would make choices based on the information in the
Query Object.  That would allow the Components for which there was one
entry for the role to return immediately.  For Components that required even
more information, the next part of the Query object was used.

That does present some nice ways of expressing a system.  The problem is creating
a Query Object for every type of Component you have to deal with.  In the Cocoon
world, the Environment would be a perfect part of the Query Object as it addresses
all dimensions of the problem space other than role.




> At first you do not see the differences. The essence looks the same.
> It looks like I could do it the Avalon way.


You probably could ;)



> It is because my problem domain is so different from Avalon's that I 
> ended up finding that a lot could be made much simpler by changing 
> the way the ComponentManager related stuff works.


And that is why I want to learn from you.


> 
> That added complexity to the ComponentManager (still not very big) but
> simplified a lot the overall project.
> 
> 
> It is just one of those things that you have to play a lot with to
> understand why.


Well a short history of the decision process would help alot more than
playing with it.




> Notice that I followed a different approach than Cocoon, where the 
> sitemap has almost nothing to do with the ComponentManager.
> 
> In my implementation, the sitemap is stored in the ComponentManager.
> Overall, my implementation is much, much, much simpler.


Cocoon's Sitemap is stored in a ComponentManager as well.  It just needs
access to a large number of other Components.



> I am not saying that Cocoon could be implemented this way. I am not
> sure about that even after using quite some Cocoon code. These are
> two different beasts, with different objectives although with many
> things in common.


You are right.  Cocoon can't be implemented that way, but it can be
cleaned up some in this regard.  They are very different beasts.



-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


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


Mime
View raw message