avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Kohlhaas <christoph...@einfachanders.de>
Subject [patches] Fortress and Event
Date Wed, 04 Dec 2002 02:14:49 GMT
I already sent this patches a few weeks ago, but none of them made it
into CVS yet. Thought that they got lost between the more important
threads so I resend them.

I've included a small descprition of the bugs:

The bug in event-package

The bug sometimes occurs on disposing of the TPCThreadManager and results

Unexpected condition while releasing worker: Thread[TPCThreadManager Worker #0,5,TPCThreadManager]
        at org.apache.excalibur.event.command.EventThreadPool.releaseWorker(EventThreadPool.java:141)
        at org.apache.excalibur.thread.impl.WorkerThread.recycleThread(WorkerThread.java:134)
        at org.apache.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:123)

It's caused by Threads in the EventThreadPool that were still running after
disposing of the Pool.

This was a nasty bug, I had to fix EventThreadPool, AbstractThreadManager and TPCThreadManager
(Spend some hours on it). See ThreadManager_disposing.patch for more info.

The bugs in AbstractServiceManager

1. AbstractServiceManager wraps all ComponentHandlers in a
LEAwareComponentHandler. But the LEAwareComponentHandler isn't
Disposable so none of the componentHandlers ever gets disposed. I've added
an getDelegate() Method to LEAwareComponentHandler and dispose the
delegates on disposing of the Container.

2. If the container gets disposed before all its ComponentHandlers are
prepared, an IllegalStateException("You cannot get a component from a
disposed holder") is thrown by the PrepareHandlerCommands that are still in
the initialization queue. That is correct, because the
ComponentHandlers were disposed in the dispose method after the
previous fix. To solve this, I have added a disable() method to
PrepareHandlerCommand to prevent execution of the command after
disposing of the ComponSee container_disposing.patch for more info

The bug in FortressServiceManager

The lookup-method consulted the parent ServiceManager if the Service was not
found while the hasService didn't. I just added a call to



View raw message