You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Christopher Kohlhaas <ko...@bonn.edu> on 2002/08/06 12:36:43 UTC
Problem with asynchronous disposing in fortress
Consider the following code snipplet:
<code>
contextManager.initialize();
cm = new DefaultContainerManager( contextManager );
cm.initialize();
container = cm.getContainer();
// do something usefull with the container
...
cm.dispose();
/* !!! We have to wait until the container has
* processed all DisposeComponentHandlerCommand(s) asynchronously!!
*/
Thread.sleep(1000);
contextManager.dispose();
</code>
If you don't wait, the components belonging to the container won't be
either discarded nor stopped. Is this a bug or something you have to
consider when you use asynchronously creating/disposing?
Regards Christopher
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] De-Instrument Fortress, Pool (was: RE: Problem with asynchronous disposing in fortress)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Leif,
I understand that the Instrument package is solid as far as the code in
it
is concerned. But the GUMP failures (I just got one for
Excalibur-component)
means that I'm not the only one having problems with the instrument
package.
What I meant by flaky was this:
+ Instrument build is broken.
+ It is not fixed.
+ So Fortress won't build.
Given that our build process is, as far as I can see, damaged. I want to
reduce the number of dependencies for Fortress. One idea would be to
move
Instrumentable + its deps. to framework. That would eliminate one
dependency
for Fortress, and move the parts that are most stable of instrument away
from the not-quite-as-stable parts of instrument.
I am willing to do these refactorings. I am also willing to tear out
all instrument references from Fortress in order to make it build so
I can fix the async disposal bug.
But I am not willing to go through the dep. chain of:
Fix async bug -> fix fortress build -> fix instrument build ->
fix excalibur build system -> god knows what.
I want to put in an 8 line fix in command manager, and I have to do
all the above. What utter crap. A 2 minute fix has become a 4 hour
fix. And I don't have time, and so I give up and let the bug remain
unfixed.
What utter crap result.
/LS
> From: Leif Mortenson [mailto:leif@tanukisoftware.com]
>
> >
> >
> > + I don't think that a supposedly production-quality package such as
> > Fortress should be dependent on something as flaky as Instrument.
> >
> The instrument package esp the code in instrument.jar is
> actually quite
> stable and has been in use for
> quite some time.
>
> Berin merged the 3 indstrument projects into a single package
> a couple
> weeks ago and there have
> been some build problems that were caused by that because the
> projects
> were not being built in
> the correct order. There may also have been some problems
> with Fortress
> over the last couple
> days as I have been doing a lot of work there.
>
> The errors you were seeing were clearly not Instrument
> errors, they were
> simple class not found
> errors. Which usually means that a jar is missing. So the
> question is
> why isnt the pool project
> finding the instrument jars when it is being built. That had been
> working for months.
>
> I was able to get the full excalibur build working last night from a
> clean build without any problems.
> Where are you seeing the errors? Only in GUMP? or from a
> manual build.
> Most likely the problems
> are simple misconfiguration of gump.
>
> Sorry for all the problems, I had not realized that GUMP was failing
> because of this.
>
> I just checked again, the latest failure is still because Cocoon is
> missing or something.
> http://jakarta.apache.org/builds/gump/latest/jakarta-avalon-ex
calibur.html
[java] Exception in thread "main" java.lang.NoClassDefFoundError:
org/apache/cocoon/Main
Where is it that you are seeing the failures?
I looked at the gump.xml but there isn't even a reference to fortress in
there. The "excalibur-pool"
project entry is correctly depending on instrument. Looking at the
dependencies of the instrument
project they were wrong up until the changes that I made yesterday. So
that should also be fine
with just framework and altrmi.
I am not seeing the problem from what you posted.
Leif
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] De-Instrument Fortress, Pool (was: RE: Problem with asynchronous
disposing in fortress)
Posted by Leif Mortenson <le...@tanukisoftware.com>.
>
>
> + I don't think that a supposedly production-quality package such as
> Fortress should be dependent on something as flaky as Instrument.
>
The instrument package esp the code in instrument.jar is actually quite
stable and has been in use for
quite some time.
Berin merged the 3 indstrument projects into a single package a couple
weeks ago and there have
been some build problems that were caused by that because the projects
were not being built in
the correct order. There may also have been some problems with Fortress
over the last couple
days as I have been doing a lot of work there.
The errors you were seeing were clearly not Instrument errors, they were
simple class not found
errors. Which usually means that a jar is missing. So the question is
why isnt the pool project
finding the instrument jars when it is being built. That had been
working for months.
I was able to get the full excalibur build working last night from a
clean build without any problems.
Where are you seeing the errors? Only in GUMP? or from a manual build.
Most likely the problems
are simple misconfiguration of gump.
Sorry for all the problems, I had not realized that GUMP was failing
because of this.
I just checked again, the latest failure is still because Cocoon is
missing or something.
http://jakarta.apache.org/builds/gump/latest/jakarta-avalon-excalibur.html
[java] Exception in thread "main" java.lang.NoClassDefFoundError:
org/apache/cocoon/Main
Where is it that you are seeing the failures?
I looked at the gump.xml but there isn't even a reference to fortress in
there. The "excalibur-pool"
project entry is correctly depending on instrument. Looking at the
dependencies of the instrument
project they were wrong up until the changes that I made yesterday. So
that should also be fine
with just framework and altrmi.
I am not seeing the problem from what you posted.
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] De-Instrument Fortress, Pool (was: RE: Problem with asynchronous
disposing in fortress)
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Berin Loritsch wrote:
>Funny, I haven't seen any GUMP complaints... And the problem
>was not with the code, but with the CVS version of ANT.
>
I was surprised as well. There was just one with excalibur-component
that was my fault.
But I just broke that last night merging the ICM into the ECM.
I committed a fix and explained it in the GUMP failure thread.
Hopefully that fixes it.
Is there a way to test GUMP builds other than waiting for the nightly
build? I always
try to be careful about not breaking the regular build... But it hard
to catch everything
with the GUMP builds just by looking at gump.xml
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] De-Instrument Fortress, Pool (was: RE: Problem with asynchronous disposing in fortress)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> Funny, I haven't seen any GUMP complaints... And the problem
> was not with the code, but with the CVS version of ANT.
Not instrument build, but something has changed that broke:
----------------------------------------------------
This email is autogenerated from the output from:
<http://jakarta.apache.org/builds/gump/2002-08-07/excalibur-component.ht
ml>
----------------------------------------------------
Buildfile: build.xml
dependencies:
compile:
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-avalon-excalibur/component/build/classes
[javac] Compiling 19 source files to
/home/rubys/jakarta/jakarta-avalon-excalibur/component/build/classes
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ComponentHandler.java:21: cannot resolve
symbol
[javac] symbol : class CounterInstrument
[javac] location: package instrument
[javac] import org.apache.excalibur.instrument.CounterInstrument;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ComponentHandler.java:22: cannot resolve
symbol
[javac] symbol : class Instrumentable
[javac] location: package instrument
[javac] import org.apache.excalibur.instrument.Instrumentable;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ComponentHandler.java:23: cannot resolve
symbol
[javac] symbol : class InstrumentManager
[javac] location: package instrument
[javac] import org.apache.excalibur.instrument.InstrumentManager;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ComponentHandler.java:24: cannot resolve
symbol
[javac] symbol : class ValueInstrument
[javac] location: package instrument
[javac] import org.apache.excalibur.instrument.ValueInstrument;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/AbstractDualLogEnabledInstrumentable.java:
12: cannot resolve symbol
[javac] symbol : class Instrument
[javac] location: package instrument
[javac] import org.apache.excalibur.instrument.Instrument;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/AbstractDualLogEnabledInstrumentable.java:
13: cannot resolve symbol
[javac] symbol : class Instrumentable
[javac] location: package instrument
[javac] import org.apache.excalibur.instrument.Instrumentable;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/AbstractDualLogEnabledInstrumentable.java:
27: cannot resolve symbol
[javac] symbol : class Instrumentable
[javac] location: class
org.apache.avalon.excalibur.component.AbstractDualLogEnabledInstrumentab
le
[javac] implements Instrumentable
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ComponentHandler.java:44: cannot resolve
symbol
[javac] symbol : class ValueInstrument
[javac] location: class
org.apache.avalon.excalibur.component.ComponentHandler
[javac] private ValueInstrument m_referencesInstrument;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ComponentHandler.java:47: cannot resolve
symbol
[javac] symbol : class CounterInstrument
[javac] location: class
org.apache.avalon.excalibur.component.ComponentHandler
[javac] private CounterInstrument m_getsInstrument;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ComponentHandler.java:50: cannot resolve
symbol
[javac] symbol : class CounterInstrument
[javac] location: class
org.apache.avalon.excalibur.component.ComponentHandler
[javac] private CounterInstrument m_putsInstrument;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ComponentHandler.java:114: cannot resolve
symbol
[javac] symbol : class InstrumentManager
[javac] location: class
org.apache.avalon.excalibur.component.ComponentHandler
[javac]
final InstrumentManager instrumentManager,
[javac]
^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/AbstractDualLogEnabledInstrumentable.java:
64: cannot resolve symbol
[javac] symbol : class Instrument
[javac] location: class
org.apache.avalon.excalibur.component.AbstractDualLogEnabledInstrumentab
le
[javac] protected void addInstrument( Instrument instrument )
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/AbstractDualLogEnabledInstrumentable.java:
84: cannot resolve symbol
[javac] symbol : class Instrumentable
[javac] location: class
org.apache.avalon.excalibur.component.AbstractDualLogEnabledInstrumentab
le
[javac] protected void addChildInstrumentable( Instrumentable
child )
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/AbstractDualLogEnabledInstrumentable.java:
134: cannot resolve symbol
[javac] symbol : class Instrumentable
[javac] location: class
org.apache.avalon.excalibur.component.AbstractDualLogEnabledInstrumentab
le
[javac] public final Instrumentable[] getChildInstrumentables()
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/AbstractDualLogEnabledInstrumentable.java:
160: cannot resolve symbol
[javac] symbol : class Instrument
[javac] location: class
org.apache.avalon.excalibur.component.AbstractDualLogEnabledInstrumentab
le
[javac] public final Instrument[] getInstruments()
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/DefaultComponentFactory.java:37: cannot
resolve symbol
[javac] symbol : class Instrumentable
[javac] location: package instrument
[javac] import org.apache.excalibur.instrument.Instrumentable;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/DefaultComponentFactory.java:38: cannot
resolve symbol
[javac] symbol : class InstrumentManageable
[javac] location: package instrument
[javac] import org.apache.excalibur.instrument.InstrumentManageable;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/DefaultComponentFactory.java:39: cannot
resolve symbol
[javac] symbol : class InstrumentManager
[javac] location: package instrument
[javac] import org.apache.excalibur.instrument.InstrumentManager;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/DefaultComponentFactory.java:86: cannot
resolve symbol
[javac] symbol : class InstrumentManager
[javac] location: class
org.apache.avalon.excalibur.component.DefaultComponentFactory
[javac] private InstrumentManager m_instrumentManager;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/DefaultComponentFactory.java:143: cannot
resolve symbol
[javac] symbol : class InstrumentManager
[javac] location: class
org.apache.avalon.excalibur.component.DefaultComponentFactory
[javac] final InstrumentManager
instrumentManager,
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ExcaliburComponentManager.java:32: cannot
resolve symbol
[javac] symbol : class Instrument
[javac] location: package instrument
[javac] import org.apache.excalibur.instrument.Instrument;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ExcaliburComponentManager.java:33: cannot
resolve symbol
[javac] symbol : class Instrumentable
[javac] location: package instrument
[javac] import org.apache.excalibur.instrument.Instrumentable;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ExcaliburComponentManager.java:34: cannot
resolve symbol
[javac] symbol : class InstrumentManageable
[javac] location: package instrument
[javac] import org.apache.excalibur.instrument.InstrumentManageable;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ExcaliburComponentManager.java:35: cannot
resolve symbol
[javac] symbol : class InstrumentManager
[javac] location: package instrument
[javac] import org.apache.excalibur.instrument.InstrumentManager;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ExcaliburComponentManager.java:56: cannot
resolve symbol
[javac] symbol : class InstrumentManageable
[javac] location: class
org.apache.avalon.excalibur.component.ExcaliburComponentManager
[javac] InstrumentManageable,
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ExcaliburComponentManager.java:57: cannot
resolve symbol
[javac] symbol : class Instrumentable
[javac] location: class
org.apache.avalon.excalibur.component.ExcaliburComponentManager
[javac] Instrumentable
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ExcaliburComponentManager.java:92: cannot
resolve symbol
[javac] symbol : class InstrumentManager
[javac] location: class
org.apache.avalon.excalibur.component.ExcaliburComponentManager
[javac] private InstrumentManager m_instrumentManager;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ExcaliburComponentManager.java:630: cannot
resolve symbol
[javac] symbol : class InstrumentManager
[javac] location: class
org.apache.avalon.excalibur.component.ExcaliburComponentManager
[javac] public void setInstrumentManager( InstrumentManager
instrumentManager )
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ExcaliburComponentManager.java:677: cannot
resolve symbol
[javac] symbol : class Instrument
[javac] location: class
org.apache.avalon.excalibur.component.ExcaliburComponentManager
[javac] public Instrument[] getInstruments()
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ExcaliburComponentManager.java:691: cannot
resolve symbol
[javac] symbol : class Instrumentable
[javac] location: class
org.apache.avalon.excalibur.component.ExcaliburComponentManager
[javac] public Instrumentable[] getChildInstrumentables()
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ExcaliburComponentSelector.java:34: cannot
resolve symbol
[javac] symbol : class Instrument
[javac] location: package instrument
[javac] import org.apache.excalibur.instrument.Instrument;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ExcaliburComponentSelector.java:35: cannot
resolve symbol
[javac] symbol : class Instrumentable
[javac] location: package instrument
[javac] import org.apache.excalibur.instrument.Instrumentable;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ExcaliburComponentSelector.java:36: cannot
resolve symbol
[javac] symbol : class InstrumentManageable
[javac] location: package instrument
[javac] import org.apache.excalibur.instrument.InstrumentManageable;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ExcaliburComponentSelector.java:37: cannot
resolve symbol
[javac] symbol : class InstrumentManager
[javac] location: package instrument
[javac] import org.apache.excalibur.instrument.InstrumentManager;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ExcaliburComponentSelector.java:59: cannot
resolve symbol
[javac] symbol : class InstrumentManageable
[javac] location: class
org.apache.avalon.excalibur.component.ExcaliburComponentSelector
[javac] InstrumentManageable,
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ExcaliburComponentSelector.java:60: cannot
resolve symbol
[javac] symbol : class Instrumentable
[javac] location: class
org.apache.avalon.excalibur.component.ExcaliburComponentSelector
[javac] Instrumentable
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ExcaliburComponentSelector.java:110:
cannot resolve symbol
[javac] symbol : class InstrumentManager
[javac] location: class
org.apache.avalon.excalibur.component.ExcaliburComponentSelector
[javac] private InstrumentManager m_instrumentManager;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ExcaliburComponentSelector.java:515:
cannot resolve symbol
[javac] symbol : class InstrumentManager
[javac] location: class
org.apache.avalon.excalibur.component.ExcaliburComponentSelector
[javac] public void setInstrumentManager( final
InstrumentManager instrumentManager )
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ExcaliburComponentSelector.java:562:
cannot resolve symbol
[javac] symbol : class Instrument
[javac] location: class
org.apache.avalon.excalibur.component.ExcaliburComponentSelector
[javac] public Instrument[] getInstruments()
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ExcaliburComponentSelector.java:576:
cannot resolve symbol
[javac] symbol : class Instrumentable
[javac] location: class
org.apache.avalon.excalibur.component.ExcaliburComponentSelector
[javac] public Instrumentable[] getChildInstrumentables()
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/AbstractDualLogEnabledInstrumentable.java:
139: cannot resolve symbol
[javac] symbol : variable Instrumentable
[javac] location: class
org.apache.avalon.excalibur.component.AbstractDualLogEnabledInstrumentab
le
[javac] return
Instrumentable.EMPTY_INSTRUMENTABLE_ARRAY;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/AbstractDualLogEnabledInstrumentable.java:
143: cannot resolve symbol
[javac] symbol : class Instrumentable
[javac] location: class
org.apache.avalon.excalibur.component.AbstractDualLogEnabledInstrumentab
le
[javac] Instrumentable[] children = new Instrumentable[
m_childList.size() ];
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/AbstractDualLogEnabledInstrumentable.java:
143: cannot resolve symbol
[javac] symbol : class Instrumentable
[javac] location: class
org.apache.avalon.excalibur.component.AbstractDualLogEnabledInstrumentab
le
[javac] Instrumentable[] children = new Instrumentable[
m_childList.size() ];
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/AbstractDualLogEnabledInstrumentable.java:
165: cannot resolve symbol
[javac] symbol : variable Instrumentable
[javac] location: class
org.apache.avalon.excalibur.component.AbstractDualLogEnabledInstrumentab
le
[javac] return Instrumentable.EMPTY_INSTRUMENT_ARRAY;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/AbstractDualLogEnabledInstrumentable.java:
169: cannot resolve symbol
[javac] symbol : class Instrument
[javac] location: class
org.apache.avalon.excalibur.component.AbstractDualLogEnabledInstrumentab
le
[javac] Instrument[] instruments = new Instrument[
m_instrumentList.size() ];
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/AbstractDualLogEnabledInstrumentable.java:
169: cannot resolve symbol
[javac] symbol : class Instrument
[javac] location: class
org.apache.avalon.excalibur.component.AbstractDualLogEnabledInstrumentab
le
[javac] Instrument[] instruments = new Instrument[
m_instrumentList.size() ];
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ComponentHandler.java:166: cannot resolve
symbol
[javac] symbol : class Instrumentable
[javac] location: class
org.apache.avalon.excalibur.component.ComponentHandler
[javac] ((Instrumentable)handler).setInstrumentableName(
instrumentableName );
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ComponentHandler.java:209: cannot resolve
symbol
[javac] symbol : class ValueInstrument
[javac] location: class
org.apache.avalon.excalibur.component.ComponentHandler
[javac] addInstrument( m_referencesInstrument = new
ValueInstrument( "references" ) );
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ComponentHandler.java:210: cannot resolve
symbol
[javac] symbol : class CounterInstrument
[javac] location: class
org.apache.avalon.excalibur.component.ComponentHandler
[javac] addInstrument( m_getsInstrument = new
CounterInstrument( "gets" ) );
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ComponentHandler.java:211: cannot resolve
symbol
[javac] symbol : class CounterInstrument
[javac] location: class
org.apache.avalon.excalibur.component.ComponentHandler
[javac] addInstrument( m_putsInstrument = new
CounterInstrument( "puts" ) );
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/DefaultComponentFactory.java:215: cannot
resolve symbol
[javac] symbol : class InstrumentManageable
[javac] location: class
org.apache.avalon.excalibur.component.DefaultComponentFactory
[javac] if( ( component instanceof InstrumentManageable ) &&
( m_instrumentManager != null ) )
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/DefaultComponentFactory.java:217: cannot
resolve symbol
[javac] symbol : class InstrumentManageable
[javac] location: class
org.apache.avalon.excalibur.component.DefaultComponentFactory
[javac] ( (InstrumentManageable)component
).setInstrumentManager( m_instrumentManager );
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/DefaultComponentFactory.java:271: cannot
resolve symbol
[javac] symbol : class Instrumentable
[javac] location: class
org.apache.avalon.excalibur.component.DefaultComponentFactory
[javac] if( component instanceof Instrumentable )
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/DefaultComponentFactory.java:273: cannot
resolve symbol
[javac] symbol : class Instrumentable
[javac] location: class
org.apache.avalon.excalibur.component.DefaultComponentFactory
[javac] Instrumentable instrumentable =
(Instrumentable)component;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/DefaultComponentFactory.java:273: cannot
resolve symbol
[javac] symbol : class Instrumentable
[javac] location: class
org.apache.avalon.excalibur.component.DefaultComponentFactory
[javac] Instrumentable instrumentable =
(Instrumentable)component;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/DefaultComponentFactory.java:279: cannot
resolve symbol
[javac] symbol : class Instrumentable
[javac] location: class
org.apache.avalon.excalibur.component.DefaultComponentFactory
[javac] (Instrumentable)component,
m_instrumentableName );
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ExcaliburComponentManager.java:679: cannot
resolve symbol
[javac] symbol : variable Instrumentable
[javac] location: class
org.apache.avalon.excalibur.component.ExcaliburComponentManager
[javac] return Instrumentable.EMPTY_INSTRUMENT_ARRAY;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ExcaliburComponentManager.java:695: cannot
resolve symbol
[javac] symbol : class Instrumentable
[javac] location: class
org.apache.avalon.excalibur.component.ExcaliburComponentManager
[javac] Instrumentable[] children = new Instrumentable[
values.size() ];
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ExcaliburComponentManager.java:695: cannot
resolve symbol
[javac] symbol : class Instrumentable
[javac] location: class
org.apache.avalon.excalibur.component.ExcaliburComponentManager
[javac] Instrumentable[] children = new Instrumentable[
values.size() ];
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ExcaliburComponentSelector.java:564:
cannot resolve symbol
[javac] symbol : variable Instrumentable
[javac] location: class
org.apache.avalon.excalibur.component.ExcaliburComponentSelector
[javac] return Instrumentable.EMPTY_INSTRUMENT_ARRAY;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ExcaliburComponentSelector.java:580:
cannot resolve symbol
[javac] symbol : class Instrumentable
[javac] location: class
org.apache.avalon.excalibur.component.ExcaliburComponentSelector
[javac] Instrumentable[] children = new Instrumentable[
values.size() ];
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-avalon-excalibur/component/src/java/org/apac
he/avalon/excalibur/component/ExcaliburComponentSelector.java:580:
cannot resolve symbol
[javac] symbol : class Instrumentable
[javac] location: class
org.apache.avalon.excalibur.component.ExcaliburComponentSelector
[javac] Instrumentable[] children = new Instrumentable[
values.size() ];
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -deprecation for details.
[javac] 62 errors
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] De-Instrument Fortress, Pool (was: RE: Problem with asynchronous disposing in fortress)
Posted by Berin Loritsch <bl...@apache.org>.
Funny, I haven't seen any GUMP complaints... And the problem
was not with the code, but with the CVS version of ANT.
> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Sent: Wednesday, August 07, 2002 4:01 AM
> To: 'Avalon Developers List'
> Subject: [VOTE] De-Instrument Fortress, Pool (was: RE:
> Problem with asynchronous disposing in fortress)
>
>
> I'd like to call a vote for
>
> + removing instrumentation from Fortress and Pool.
>
> + removing it from GUMP.
>
> Both of the above only temporarily.
>
> Reasons:
>
> + Doesn't build. We've had daily GUMP complains for quite a
> while now, and
> I am greeted with the following:
>
> compile:
> [javac] Compiling 17 source files to
> C:\Home\leo\private\Apache\jakarta-aval
> on-excalibur\pool\build\classes
> [javac]
> C:\Home\leo\private\Apache\jakarta-avalon-excalibur\pool\src\java\or
> g\apache\avalon\excalibur\pool\ResourceLimitingPool.java:12:
> cannot resolve symb ol
> [javac] symbol : class CounterInstrument
> [javac] location: package instrument
> [javac] import org.apache.excalibur.instrument.CounterInstrument;
> [javac] ^
> [javac]
> C:\Home\leo\private\Apache\jakarta-avalon-excalibur\pool\src\java\or
> g\apache\avalon\excalibur\pool\ResourceLimitingPool.java:13:
> cannot resolve symb ol
> ... AND SO ON ...
>
> [javac] Note: Recompile with -deprecation for details.
> [javac] 23 errors
>
>
> + I don't think that a supposedly production-quality package such as
> Fortress should be dependent on something as flaky as Instrument.
>
> + Not maintained. The instrument package has sort of fallen between
> chairs. Day after day we get GUMP complaints, and nothing is fixed.
> This indicates that the package isn't used, or isn't maintained by
> anyone. If this is because the author has a temporary hectic time
> or whatever isn't important - the end result is that depending on
> this package just isn't a very safe bet anymore.
>
> ---------------------
>
> I am willing to do the de-instrumentation (just comment it
> out) and fix the async disposal bug, but as it is now I don't
> have the hours it takes to fix
> the build and then fix the async bug.
>
> /LS
>
>
> --
> To unsubscribe, e-mail:
> <mailto:avalon-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[VOTE] De-Instrument Fortress, Pool (was: RE: Problem with asynchronous disposing in fortress)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
I'd like to call a vote for
+ removing instrumentation from Fortress and Pool.
+ removing it from GUMP.
Both of the above only temporarily.
Reasons:
+ Doesn't build. We've had daily GUMP complains for quite a while now,
and
I am greeted with the following:
compile:
[javac] Compiling 17 source files to
C:\Home\leo\private\Apache\jakarta-aval
on-excalibur\pool\build\classes
[javac]
C:\Home\leo\private\Apache\jakarta-avalon-excalibur\pool\src\java\or
g\apache\avalon\excalibur\pool\ResourceLimitingPool.java:12: cannot
resolve symb
ol
[javac] symbol : class CounterInstrument
[javac] location: package instrument
[javac] import org.apache.excalibur.instrument.CounterInstrument;
[javac] ^
[javac]
C:\Home\leo\private\Apache\jakarta-avalon-excalibur\pool\src\java\or
g\apache\avalon\excalibur\pool\ResourceLimitingPool.java:13: cannot
resolve symb
ol
... AND SO ON ...
[javac] Note: Recompile with -deprecation for details.
[javac] 23 errors
+ I don't think that a supposedly production-quality package such as
Fortress should be dependent on something as flaky as Instrument.
+ Not maintained. The instrument package has sort of fallen between
chairs. Day after day we get GUMP complaints, and nothing is fixed.
This indicates that the package isn't used, or isn't maintained by
anyone. If this is because the author has a temporary hectic time
or whatever isn't important - the end result is that depending on
this package just isn't a very safe bet anymore.
---------------------
I am willing to do the de-instrumentation (just comment it out) and fix
the
async disposal bug, but as it is now I don't have the hours it takes to
fix
the build and then fix the async bug.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Problem with asynchronous disposing in fortress
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Leif Mortenson wrote:
> What is the problem that you are seeing.
> I did a clean build and then build from the root and it all works fine.
>
> If I do a clean build and then build from fortress, it goes off and
> starts building other
> projects via the dependencies build file. But it gets into a loop
> trying to build instrument.
> It is too late to figure this out here tonight, but for now, just
> build the root fist and all
> seems ok.
>
> I'd love to hear how it gets into a loop. Tried debugging it before
> but it has always been
> late and never made heads or tails of it :-/
Ok, I got this worked out it was being caused by a bug in Ant 1.6alpha
where it appears
that the inheritAll attribute of the ant task was being ignored. I am
using Ant 1.5 now and
all appears to be working perfectly.
Cheers,
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Problem with asynchronous disposing in fortress
Posted by Leif Mortenson <le...@tanukisoftware.com>.
What is the problem that you are seeing.
I did a clean build and then build from the root and it all works fine.
If I do a clean build and then build from fortress, it goes off and
starts building other
projects via the dependencies build file. But it gets into a loop
trying to build instrument.
It is too late to figure this out here tonight, but for now, just build
the root fist and all
seems ok.
I'd love to hear how it gets into a loop. Tried debugging it before but
it has always been
late and never made heads or tails of it :-/
Leif
Leo Sutic wrote:
>Ran into a bit of a problem...
>
>It doesn't compile. The instrument-manager etc. appear broken.
>
>/LS
>
>
>
>>-----Original Message-----
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>Sent: den 6 augusti 2002 15:57
>>To: 'Avalon Developers List'
>>Subject: RE: Problem with asynchronous disposing in fortress
>>
>>
>>
>>
>>>From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>>>
>>>
>>>
>>>>From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>>>>
>>>>
>>>>
>>>>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>>>>
>>>>>Aha! It is a bug introduced by the whole assume ownerhip
>>>>>
>>>>>
>>>stuff. I
>>>
>>>
>>>>>didn't like it because instead of *using* what someone
>>>>>
>>>>>
>>>else owned,
>>>
>>>
>>>>>it stole it from them.
>>>>>
>>>>>
>>>>Not really. The the contextmanager will only assume
>>>>
>>>>
>>ownership of the
>>
>>
>>>>managers it creates itself:
>>>>
>>>> CommandManager cm = new CommandManager();
>>>> assumeOwnership( cm );
>>>> childContext.put( COMMAND_QUEUE, cm.getCommandQueue() );
>>>>
>>>>What should be done is to put a flush() operation in the command
>>>>manager's dispose method.
>>>>
>>>>
>>>Berin,
>>>
>>>if you agree with the solution outlined above, you fine with
>>>letting me implement it?
>>>
>>>
>>Go for it.
>>
>>
>>--
>>To unsubscribe, e-mail:
>><mailto:avalon-dev-> unsubscribe@jakarta.apache.org>
>>For
>>additional commands,
>>e-mail: <ma...@jakarta.apache.org>
>>
>>
>>
>>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
RE: Problem with asynchronous disposing in fortress
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
?
You're right.
And I thought I had done an update of it...
/LS
> From: Greg Steuck [mailto:greg-avalon-dev@nest.cx]
>
> I'm afraid you are looking at an old revision of
> DefaultQueue. rev 1.13 has different code.
>
> >>>>> "Leo" == Leo Sutic <le...@inspireinfrastructure.com> writes:
>
> Leo> null check neccesary (due to bug).
>
> Leo> I'll get back to this tomorrow, got to rush now. Will try
> Leo> building instrument as Leif said.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Problem with asynchronous disposing in fortress
Posted by Greg Steuck <gr...@nest.cx>.
I'm afraid you are looking at an old revision of DefaultQueue. rev 1.13
has different code.
>>>>> "Leo" == Leo Sutic <le...@inspireinfrastructure.com> writes:
Leo> null check neccesary (due to bug).
Leo> I'll get back to this tomorrow, got to rush now. Will try
Leo> building instrument as Leif said.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Problem with asynchronous disposing in fortress
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
DefaultQueue.java:
public QueueElement[] dequeueAll()
{
QueueElement[] elements = null;
try
{
if( m_mutex.attempt( m_timeout ) )
{
try
{
elements = new QueueElement[ size() ];
for( int i = 0; i < elements.length; i++ )
{
elements[ i ] =
(QueueElement)m_elements.remove();
}
}
finally
{
m_mutex.release();
}
}
}
catch( InterruptedException ie )
{
}
return elements;
}
null check neccesary (due to bug).
I'll get back to this tomorrow, got to rush now. Will try building
instrument as Leif said.
/LS
> -----Original Message-----
> From: Gregory Steuck [mailto:greg@buildpoint.com]
> Sent: den 6 augusti 2002 18:52
> To: Avalon Developers List
> Subject: RE: Problem with asynchronous disposing in fortress
>
>
>
> Leo> public void dispose ()
> Leo> {
> Leo> QueueElement[] remainingElements =
> Leo>getCommandQueue().dequeueAll();
> Leo> if (remainingElements != null)
> Leo> {
> Leo> for( int i = 0; i < remainingElements.length; i++ )
> Leo> {
> Leo> getEventHandler.handleEvent(
> remainingElements[i] );
> Leo> }
> Leo> }
> Leo> }
>
> According to Source.dequeueAll documentation:
>
> * Dequeues all available elements. Returns a zero-sized array in
> * case of a timeout while attempting to obtain the mutex or if
> * there is nothing left on the queue.
> *
> * @return all pending <code>QueueElement</code>s on the queue
>
> So != null check is unnecessary.
>
> --
> To unsubscribe, e-mail:
> <mailto:avalon-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Problem with asynchronous disposing in fortress
Posted by Gregory Steuck <gr...@buildpoint.com>.
Leo> public void dispose ()
Leo> {
Leo> QueueElement[] remainingElements =
Leo>getCommandQueue().dequeueAll();
Leo> if (remainingElements != null)
Leo> {
Leo> for( int i = 0; i < remainingElements.length; i++ )
Leo> {
Leo> getEventHandler.handleEvent( remainingElements[i] );
Leo> }
Leo> }
Leo> }
According to Source.dequeueAll documentation:
* Dequeues all available elements. Returns a zero-sized array in
* case of a timeout while attempting to obtain the mutex or if
* there is nothing left on the queue.
*
* @return all pending <code>QueueElement</code>s on the queue
So != null check is unnecessary.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Problem with asynchronous disposing in fortress
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Berin, could you put this into CommandManager:
public void dispose ()
{
QueueElement[] remainingElements =
getCommandQueue().dequeueAll();
if (remainingElements != null)
{
for( int i = 0; i < remainingElements.length; i++ )
{
getEventHandler.handleEvent( remainingElements[i] );
}
}
}
and have it implement Disposable:
import org.apache.avalon.framework.activity.Disposable;
/**
* The CommandManager handles asynchronous commands from the rest of the
system.
* The only exposed piece is the Queue that other components use to give
Commands
* to this system. You <strong>must</strong> register this with a
ThreadManager
* for it to work.
*
* @author <a href="mailto:bloritsch@apache.org">Berin Loritsch</a>
*/
public class CommandManager implements EventPipeline, Disposable
------------
I was just thinking... Shouldn't the CommandManager take a ThreadManager
as a parameter to its constructor and deregister itself when disposed?
/LS
> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Sent: den 6 augusti 2002 16:27
> To: 'Avalon Developers List'; bloritsch@apache.org
> Subject: RE: Problem with asynchronous disposing in fortress
>
>
> Ran into a bit of a problem...
>
> It doesn't compile. The instrument-manager etc. appear broken.
>
> /LS
>
> > -----Original Message-----
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > Sent: den 6 augusti 2002 15:57
> > To: 'Avalon Developers List'
> > Subject: RE: Problem with asynchronous disposing in fortress
> >
> >
> > > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> > >
> > > > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> > > >
> > > > > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > > > >
> > > > > Aha! It is a bug introduced by the whole assume ownerhip
> > > stuff. I
> > > > > didn't like it because instead of *using* what someone
> > > else owned,
> > > > > it stole it from them.
> > > >
> > > > Not really. The the contextmanager will only assume
> > ownership of the
> > > > managers it creates itself:
> > > >
> > > > CommandManager cm = new CommandManager();
> > > > assumeOwnership( cm );
> > > > childContext.put( COMMAND_QUEUE, cm.getCommandQueue() );
> > > >
> > > > What should be done is to put a flush() operation in the command
> > > > manager's dispose method.
> > >
> > > Berin,
> > >
> > > if you agree with the solution outlined above, you fine
> with letting
> > > me implement it?
> >
> >
> > Go for it.
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:avalon-dev-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands,
> > e-mail: <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <mailto:avalon-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Problem with asynchronous disposing in fortress
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Ran into a bit of a problem...
It doesn't compile. The instrument-manager etc. appear broken.
/LS
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: den 6 augusti 2002 15:57
> To: 'Avalon Developers List'
> Subject: RE: Problem with asynchronous disposing in fortress
>
>
> > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> >
> > > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> > >
> > > > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > > >
> > > > Aha! It is a bug introduced by the whole assume ownerhip
> > stuff. I
> > > > didn't like it because instead of *using* what someone
> > else owned,
> > > > it stole it from them.
> > >
> > > Not really. The the contextmanager will only assume
> ownership of the
> > > managers it creates itself:
> > >
> > > CommandManager cm = new CommandManager();
> > > assumeOwnership( cm );
> > > childContext.put( COMMAND_QUEUE, cm.getCommandQueue() );
> > >
> > > What should be done is to put a flush() operation in the command
> > > manager's dispose method.
> >
> > Berin,
> >
> > if you agree with the solution outlined above, you fine with
> > letting me implement it?
>
>
> Go for it.
>
>
> --
> To unsubscribe, e-mail:
> <mailto:avalon-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Problem with asynchronous disposing in fortress
Posted by Berin Loritsch <bl...@apache.org>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> >
> > > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > >
> > > Aha! It is a bug introduced by the whole assume ownerhip
> stuff. I
> > > didn't like it because instead of *using* what someone
> else owned,
> > > it stole it from them.
> >
> > Not really. The the contextmanager will only assume ownership
> > of the managers it creates itself:
> >
> > CommandManager cm = new CommandManager();
> > assumeOwnership( cm );
> > childContext.put( COMMAND_QUEUE, cm.getCommandQueue() );
> >
> > What should be done is to put a flush() operation in the command
> > manager's dispose method.
>
> Berin,
>
> if you agree with the solution outlined above, you fine with
> letting me implement it?
Go for it.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Problem with asynchronous disposing in fortress
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> >
> > Aha! It is a bug introduced by the whole assume ownerhip
> > stuff. I didn't like it because instead of *using* what
> > someone else owned, it stole it from them.
>
> Not really. The the contextmanager will only assume ownership
> of the managers it creates itself:
>
> CommandManager cm = new CommandManager();
> assumeOwnership( cm );
> childContext.put( COMMAND_QUEUE, cm.getCommandQueue() );
>
> What should be done is to put a flush() operation in the command
> manager's dispose method.
Berin,
if you agree with the solution outlined above, you fine with letting
me implement it?
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Problem with asynchronous disposing in fortress
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> Aha! It is a bug introduced by the whole assume ownerhip
> stuff. I didn't like it because instead of *using* what
> someone else owned, it stole it from them.
Not really. The the contextmanager will only assume ownership
of the managers it creates itself:
CommandManager cm = new CommandManager();
assumeOwnership( cm );
childContext.put( COMMAND_QUEUE, cm.getCommandQueue() );
What should be done is to put a flush() operation in the command
manager's dispose method.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Problem with asynchronous disposing in fortress
Posted by Berin Loritsch <bl...@apache.org>.
> From: Christopher Kohlhaas [mailto:kohlhaas@informatik.uni-bonn.de]
>
> The problem lies in the contextManager because it assumes
> ownership of the TPCThreadManager that is used in the
> command_queue. If the ContextManager gets disposed before the
> command_queue is empty all pending DisposeCommands silently
> get killed.
>
> <code>
> componentManager.dispose();
> Thread.sleep(1000);
> contextManager.dispose();
> </code>
Aha! It is a bug introduced by the whole assume ownerhip stuff.
I didn't like it because instead of *using* what someone else owned,
it stole it from them.
Ok. We need to address this RSN.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Problem with asynchronous disposing in fortress
Posted by Christopher Kohlhaas <ko...@informatik.uni-bonn.de>.
Berin Loritsch [bloritsch@apache.org] wrote:
> > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> >
> > I'd say bug... when dispose() returns you should be able to
> > expect that it has completed and that all handlers have been
> > disposed (as the container itself must be considered disposed
> > when the method returns). Besides, async management serves
> > little purpose when disposing the container.
> >
> > Berin?
>
> If it is not properly disposing of all the components, et. al.
> then we have an issue. I was not aware of any real issue with
> the approach, and the Thread.sleep(1000) should be unnecessary.
> Esp. since background threads (unless marked Daemon) will not
> let the VM shut down until they are processed.
>
> What prompted the inclusion of the Thread.sleep()?
>
The problem lies in the contextManager because it assumes ownership of
the TPCThreadManager that is used in the command_queue. If the
ContextManager gets disposed before the command_queue is empty all
pending DisposeCommands silently get killed.
<code>
componentManager.dispose();
Thread.sleep(1000);
contextManager.dispose();
</code>
Regards Christopher
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Problem with asynchronous disposing in fortress
Posted by Berin Loritsch <bl...@apache.org>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> I'd say bug... when dispose() returns you should be able to
> expect that it has completed and that all handlers have been
> disposed (as the container itself must be considered disposed
> when the method returns). Besides, async management serves
> little purpose when disposing the container.
>
> Berin?
If it is not properly disposing of all the components, et. al.
then we have an issue. I was not aware of any real issue with
the approach, and the Thread.sleep(1000) should be unnecessary.
Esp. since background threads (unless marked Daemon) will not
let the VM shut down until they are processed.
What prompted the inclusion of the Thread.sleep()?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Problem with asynchronous disposing in fortress
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
I'd say bug... when dispose() returns you should be able to expect that
it has completed and that all handlers have been disposed (as the
container itself must be considered disposed when the method returns).
Besides, async management serves little purpose when disposing the
container.
Berin?
/LS
> -----Original Message-----
> From: Christopher Kohlhaas [mailto:kohlhaas@bonn.edu]
> Sent: den 6 augusti 2002 12:37
> To: avalon-dev@jakarta.apache.org
> Subject: Problem with asynchronous disposing in fortress
>
>
> Consider the following code snipplet:
>
> <code>
> contextManager.initialize();
> cm = new DefaultContainerManager( contextManager );
> cm.initialize();
>
> container = cm.getContainer();
> // do something usefull with the container
> ...
>
> cm.dispose();
> /* !!! We have to wait until the container has
> * processed all DisposeComponentHandlerCommand(s) asynchronously!!
> */
> Thread.sleep(1000);
>
> contextManager.dispose();
> </code>
>
> If you don't wait, the components belonging to the container
> won't be either discarded nor stopped. Is this a bug or
> something you have to consider when you use asynchronously
> creating/disposing?
>
>
> Regards Christopher
>
>
> --
> To unsubscribe, e-mail:
> <mailto:avalon-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>