avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [RT] Is Poolable Harmful?
Date Mon, 07 Jan 2002 19:10:57 GMT
Paulo Gaspar wrote:

> Answer inline:
> 

>>Can I ask a couple questions?  How do you propose to handle the difference
>>between a Component that is ThreadSafe (i.e. can be used simultaneously
>>by multiple clients) and one that is SingleThreaded (i.e. must have a
>>unique instance for each client)?
>>
> 
> What I do in my framework is to ALWAYS have a factory which takes care of 
> reading and holding the component configuration, creating it, initializing,
> disposing, etc. It works a bit like a component factory for a pool.


Which is exactly what ExcaliburComponentManager does.  There are necessary
improvements, but they will come.


> That factory only implements enough functionality to "make the bridge" 
> between the framework and the specifics of each component and the factory
> interface has a function to describe what is the component's lifestyle.
> 
> Another object takes care of managing the components depending on that
> lifestyle (I do not rely on the factory for that, of course).
> 
> 
> 
>>They do have purpose.  If all you deal with are ThreadSafe Components,
>>then the DefaultComponentManager would be enough for you.  Unfortunately,
>>not all projects have that luxury.  Creating a new instance for every
>>client is wasteful and causes more work for the server than is necessary.
>>
> 
> I understand that.
> 
> At the moment, the only components I use that are not ThreadSafe are those
> that are pooled - like database Connections - and some special cases that
> do not match Avalon current scope (like sql queries and other stuff 
> specific to my framework). 
> 
> I do NOT, however, mark (trough their factory) those components as 
> Poolable. I just mark them as SingleThreaded and hide the specifics of the
> pool behind the component factory.


Which was the point of this thread.


> 
> This way, using a third party component or pool is trivial.


True.



>>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.


> 
> Of course that for many objects (including the above mentioned 
> Component factories) I do use interfaces like:
>   Initializable
>   Disposable
>   Startable
>   Contextualizable
>   Configurable
>   Loggable (like your LogEnabled)
>   etc.


That's good.  I'd hate to see it all merged together into one large
monolithic interface.  That way you only use what you need.



>>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.


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.



> 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.



>>>If you change this one I will only miss having an easy to use
>>>component manager that can manage several components for the same
>>>role (naming them). If one day you want to do this one, I would
>>>like to contribute.
>>>
>>
>>We had explored this in the past.  We had big, very impassioned
>>discussions.  The result of that is the ComponentSelector interface.
>>You use a ComponentManager to get the ComponentSelector for a role
>>that will have many implementations.  The ComponentSelector will
>>select your exact implementation of the Role based on an arbitrary
>>Object as a hint (the most common being a string name).
>>
> 
> I also understand that. I tried to use that mechanism as it is but,
> in the end, I found it simpler to change it since my needs are quite
> different.
> 
> I know the Avalon Framework (and some other bits) quite well (at 
> least last Summer's version) since it was my starting code base for 
> the component management and other parts of my framework and I 
> rewrote or rearranged most of it to suite my needs.
> 
> 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?



> To give you a slight idea, I am building something like Cocoon with
> much less XML and I use my standard ComponentManager to build a kind
> of SiteMap. (Obviously I also studied quite a bit of Cocoon.)


And this forces differences how?

-- 

"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