You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by giacomo <gi...@apache.org> on 2001/04/19 00:57:21 UTC
creating Overflow Resource
I think I've found the reason why C2 creates masses of Overflow
Resources from JaxpParser. The JaxpParser itself states that it is
ThreadSafe but extends AbstractXMLProducer which is Recyclable. The
DefaultComponentHandler for this class first checks if it is Poolable
(note that Recyclable exteds Poolable) and create a pool for it. This
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 is
passed back to the handler which examines the interfaces implemented by
the parser. The hnandler first tests if it implements ThreadSafe, (which
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?
TIA
Giacomo (which needs a little sleep now to be able to finish CA
tomorrow because its already 1am and I usually go up at 6:30am in the
morning)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: creating Overflow Resource
Posted by Berin Loritsch <bl...@apache.org>.
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 is
> >>>>> ThreadSafe but extends AbstractXMLProducer which is Recyclable. The
> >>>>> DefaultComponentHandler for this class first checks if it is Poolable
> >>>>> (note that Recyclable exteds Poolable) and create a pool for it. This
> >>>>> 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 is
> >>>>> passed back to the handler which examines the interfaces implemented by
> >>>>> the parser. The hnandler first tests if it implements ThreadSafe, (which
> >>>>> 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?
Yes.
> I don't think it has a heavy overhead in terms of resources, and it
> would enhance greatly usability of the framework.
agreed.
> 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.
True.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: creating Overflow Resource
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Santiago Gala a écrit :
>
> 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 is
> >>>>> ThreadSafe but extends AbstractXMLProducer which is Recyclable. The
> >>>>> DefaultComponentHandler for this class first checks if it is Poolable
> >>>>> (note that Recyclable exteds Poolable) and create a pool for it. This
> >>>>> 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 is
> >>>>> passed back to the handler which examines the interfaces implemented by
> >>>>> the parser. The hnandler first tests if it implements ThreadSafe, (which
> >>>>> 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.
>
Have a look at DefaultComponentHandler which is currently in
org.apache.excalibur.component (package names are changing a lot in
Avalon these days...)
If some work is to be done in this area, I'd like a suggest a little
refactoring idea that came to me while examining this code : shouldn't
there be several ComponentHandler implementations (say
PoolComponentHandler, SingleThreadComponentHandler, etc) corresponding
to the various component lifecycle options ? This would avoid these
switch statements in DefaultComponentHandler that are in fact methods
redefinition in an inheritance hierarchy.
Upon initialization, the ComponentManager could use a
ComponentHandlerFactory that would make all lifecycle interfaces checks
and return an adequate xxxComponentHandler instance that would be used
during its whole life.
> 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.
>
> 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.
>
> 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.
>
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: creating Overflow Resource
Posted by Santiago Gala <sg...@hisitech.com>.
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 is
>>>>> ThreadSafe but extends AbstractXMLProducer which is Recyclable. The
>>>>> DefaultComponentHandler for this class first checks if it is Poolable
>>>>> (note that Recyclable exteds Poolable) and create a pool for it. This
>>>>> 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 is
>>>>> passed back to the handler which examines the interfaces implemented by
>>>>> the parser. The hnandler first tests if it implements ThreadSafe, (which
>>>>> 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.
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.
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.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: creating Overflow Resource
Posted by giacomo <gi...@apache.org>.
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 is
> > > > ThreadSafe but extends AbstractXMLProducer which is Recyclable. The
> > > > DefaultComponentHandler for this class first checks if it is Poolable
> > > > (note that Recyclable exteds Poolable) and create a pool for it. This
> > > > 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 is
> > > > passed back to the handler which examines the interfaces implemented by
> > > > the parser. The hnandler first tests if it implements ThreadSafe, (which
> > > > 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.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: creating Overflow Resource
Posted by Berin Loritsch <bl...@apache.org>.
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 is
> > > ThreadSafe but extends AbstractXMLProducer which is Recyclable. The
> > > DefaultComponentHandler for this class first checks if it is Poolable
> > > (note that Recyclable exteds Poolable) and create a pool for it. This
> > > 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 is
> > > passed back to the handler which examines the interfaces implemented by
> > > the parser. The hnandler first tests if it implements ThreadSafe, (which
> > > 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).
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: creating Overflow Resource
Posted by giacomo <gi...@apache.org>.
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 is
> > ThreadSafe but extends AbstractXMLProducer which is Recyclable. The
> > DefaultComponentHandler for this class first checks if it is Poolable
> > (note that Recyclable exteds Poolable) and create a pool for it. This
> > 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 is
> > passed back to the handler which examines the interfaces implemented by
> > the parser. The hnandler first tests if it implements ThreadSafe, (which
> > 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?
Giacomo
>
> On Component Return, I will double check the order of tests--but
> the Component must only implement one of those lifestyle interfaces.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: creating Overflow Resource
Posted by Berin Loritsch <bl...@apache.org>.
giacomo wrote:
>
> I think I've found the reason why C2 creates masses of Overflow
> Resources from JaxpParser. The JaxpParser itself states that it is
> ThreadSafe but extends AbstractXMLProducer which is Recyclable. The
> DefaultComponentHandler for this class first checks if it is Poolable
> (note that Recyclable exteds Poolable) and create a pool for it. This
> 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 is
> passed back to the handler which examines the interfaces implemented by
> the parser. The hnandler first tests if it implements ThreadSafe, (which
> 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.
On Component Return, I will double check the order of tests--but
the Component must only implement one of those lifestyle interfaces.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org