avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <paulo.gas...@krankikom.de>
Subject RE: [RT] Is Poolable Harmful?
Date Tue, 08 Jan 2002 04:52:41 GMT
Hi Berin,

> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Monday, January 07, 2002 8:11 PM
> Paulo Gaspar wrote:
> > Answer inline:
> > 
> > > ...
> >
> > 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.

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 

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

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

  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.

> > ...
> > 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.
Of course.
I am just using the opportunity to throw some doubt on other markers too.
> > 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.

The above mentioned specific factory per component class takes care of 

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

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.

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

Again, the above mentioned factory makes my aware of that.

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

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

Imagine a "sitemap" where you can configure complex java components 
(like database connections, caches, SQL queries, lists of "records", 
etc), aggregate them trough script and publish them using Velocity or 
even (argh!) XSLT. You can also have modules (sub-sitemaps), matchers, 

The idea is that:
 - Site structure is defined in XML;
 - Complex components are implemented in Java and parameterized via XML;
 - Simple logic glue via scripting;
 - Complex logic via Java.

I want to call objects by type and name:

And I want to make sure that all resources are released after each 
request is processed.

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

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.

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.

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.

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.

Have fun,
Paulo Gaspar


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