cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: creating Overflow Resource
Date Thu, 19 Apr 2001 21:04:21 GMT
Santiago Gala wrote:
> giacomo wrote:
> >
> > On Thu, 19 Apr 2001, Berin Loritsch wrote:
> >
> >
> >> giacomo wrote:
> >>
> >>> On Thu, 19 Apr 2001, Berin Loritsch wrote:
> >>>
> >>>
> >>>> giacomo wrote:
> >>>>
> >>>>> I think I've found the reason why C2 creates masses of Overflow
> >>>>> Resources from JaxpParser. The JaxpParser itself states that it
> >>>>> ThreadSafe but extends AbstractXMLProducer which is Recyclable.
> >>>>> DefaultComponentHandler for this class first checks if it is Poolable
> >>>>> (note that Recyclable exteds Poolable) and create a pool for it.
> >>>>> leads to the creation of new instances whenever a parser is lookup()ed.
> >>>>> On the other side when the parser is released to the manager it
> >>>>> passed back to the handler which examines the interfaces implemented
> >>>>> the parser. The hnandler first tests if it implements ThreadSafe,
> >>>>> the JaxpParser it does, and thus does not put it back to the pool.
> >>>>>
> >>>>> First we have to clean up the interfaces of the JaxpParser.
> >>>>>
> >>>>> Second, Berin, could you double check if the sequence of interface
> >>>>> checks in the component management system in Avalon is correct?
> >>>>
> >>>> The affects of implementing conflicting interfaces like ThreadSafe,
> >>>> Poolable, and SingleThreaded is undefined according to the Avalon Spec.
> >>>> The interface definitely needs to be cleaned up.
> >>>>
> >>>> The way the ComponentHandler (the class that enforces the lifecycle
> >>>> for a Component) works, is that it makes the assumption that the
> >>>> class only implements one of the lifestyle (ThreadSafe, Poolable,
> >>>> and SingleThreaded) interfaces.  If it extends Poolable, it creates
> >>>> a pool.  This is usually the first check.  If it is ThreadSafe,
> >>>> it will instantiate an instance of the class and hold it until the
> >>>> class is disposed.  Finally if the Component is SingleThreaded, it
> >>>> acts like a simple factory.
> >>>
> >>> This is not always the case. Take the Actions which extends
> >>> ThreadSafe. But if someone writes a Action which can't be ThreadSafe
> >>> (whatever the reason is) it should be able to "downgrade" the action to
> >>> Poolable and the component management system should be able to take
> >>> that into account, right?
> >>
> >> I thought the contract with Actions stated that they _must_ be made
> >> threadsafe and reentrant.  If this is not the case, then the ThreadSafe
> >> interface should _not_ be included in the interface that describes an
> >> Action.
> >>
> >> In all reality, no work interface should extend a lifestyle interface
> >> unless by the contract of the API it _must_ be enforced that way.
> >> The decision of the lifestyle of a component should be done at the last
> >> possible moment (much like making methods "final" in Java).  Once set,
> >> they should never be over-ridden.  The ambiguities that arise over
> >> lifestyle conflicts should be avoided if at all possible.
> >>
> >> If we need to change the interface of some of the work interfaces to
> >> not explicitely determine it's lifestyle, then let's do that.  The
> >> Action interface is a prime example of something where if you don't
> >> want it ThreadSafe, then the work interface should not specify it
> >> that way.  The SitemapComponent is a prime example of something that
> >> *requires* all implementing classes to be Poolable or SingleThreaded
> >> (preferably Poolable).
> >>
> >> The lifestyle and work interfaces are separate concerns, and should
> >> only be merged when you are sure of the contract (e.g. with the
> >> final implementation, or enforcing a contract in the interface).
> >
> >
> > ok, convinced. We have to cleanup the interfaces from the jaxpParser
> > ASAP.
> >
> A request (I think there is avalon people 'round here :) ).
> Could avalon check for multiple life-cycle implements declared and
> complain loudly upon configuration of components?


> I don't think it has a heavy overhead in terms of resources, and it
> would enhance greatly usability of the framework.


> I could take a look at this if someone points me to the classes doing
> the work in Avalon.

The ComponentHandler is the only one that directly manipulates the lifecycle
of Components

> I already catched a similar problem, where a class (AbstractXMLProducer,
> I think) was declared as Recyclable, with a recycle method and then,
> like three levels down the inheritance hierarchy, recycle() was
> reimplemented without calling super, possibly because the intermediate
> classes were not declared as Recyclable.

That's not easily testable.  If we could include a UML diagram, that
would help to catch some of these anomolies.

Once a superclass implements the Recyclable interface, all subclasses
are Recyclable whether they are declared that way or not.

> OTOH, if the Recyclable interface is declared only at the bottom of the
> hierarchy, the implementor needs to understand how to recycle all super
> classes, which can lead to implementation problems.

The recycle should be done as it is, but we do need to be careful.
Perhaps profuse JavaDocs would help.

> Java has no way to specify the kind of thing needed here (compulsory
> super call) except for default constructors, and this kind of bugs turn
> quickly into debugging nightmares.


To unsubscribe, e-mail:
For additional commands, email:

View raw message