You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Ryan Shaw <ry...@stanfordalumni.org> on 2002/04/18 04:11:44 UTC
Re: AbstractInstrumentable extends AbstractLoggable
Okay, attached is a version of AbstractInstrumentable that extends
AbstractLoggable, and a patch for the instrument package build that
is neccessary for the new dependency.
> This would add a new dependency from the instrument package
> to framework, though. Is that a problem for anybody?
>
> Ryan Shaw wrote:
>
> > I have no problem if whoever checks it in wants to add that.
> >
> > Peter Royal wrote:
> >
> > > On Wednesday 17 April 2002 09:37 pm, Ryan Shaw wrote:
> > > > Attached is a utility class to ease the implementation
> > > > of Instrumentables, in the tradition of AbstractLogEnabled.
> > >
> > > It would be nice if it extended AbstractLogEnabled, so you don't have to
> > > choose :)
> > > -pete
> > >
> > > --
> > > peter royal -> proyal@managingpartners.com
> > >
> > > --
> > > 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>
> >
> >
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
Re: AbstractInstrumentable extends AbstractLoggable
Posted by Ryan Shaw <ry...@stanfordalumni.org>.
> [ Leif ]
> [ Leif ]
> > I would rather not have Instrument have any dependencies.
> > Maybe having an AbstractLogEnabledInstrumentable in the logger subproject?
[ Peter Royal]
> That would introduce a dependency on Instrument in Logger, right?
Yep. That doesn't seem right. Instrumentation is very light,
but I feel that logging is lower-level than instrumentation.
> [ Leif ]
> > If the AbstractLogEnabledInstrumentable class was in addition to the
> > AbstractInstrumentable class, then the dependency would only be at
> > compile time and so users who were not using framework could still
> > use the Instrumentable classes.
I agree that being able to use the instrumentation stuff independently
of framework is a desirable goal.
[ Peter Royal ]
> Create another subproject to that contains the class that will have a
> dependency on Instrument and Logger? Perhaps even an "integration"
> subproject to handle these cases.
There has been discussion in the past about the creation of a general
abstract base class which implements all the lifecycle interfaces, to
ease the construction of components.
Maybe now is the time for such a beast. It would have to be a new
subproject, to avoid dependency tangles.
Ryan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AbstractInstrumentable extends AbstractLoggable
Posted by Ryan Shaw <ry...@stanfordalumni.org>.
Peter Royal wrote:
> Create another subproject to that contains the class that will have a
> dependency on Instrument and Logger? Perhaps even an "integration" subproject
> to handle these cases.
See attached.
Re: AbstractInstrumentable extends AbstractLoggable
Posted by Peter Royal <pr...@managingpartners.com>.
On Thursday 18 April 2002 11:34 am, Leif Mortenson wrote:
> I committed the original patch. I would rather not have Instrument have
> any dependencies.
> Maybe having an AbstractLogEnabledInstrumentable in the logger subproject?
That would introduce a dependency on Instrument in Logger, right?
> Not too unmovable on adding the dependency, but it is nice to have it
> independent.
> If the AbstractLogEnabledInstrumentable class was in addition to the
> AbstractInstrumentable
> class, then the dependency would only be at compile time and so users
> who were not using
> framework could still use the Instrumentable classes.
>
> Thoughts?
Create another subproject to that contains the class that will have a
dependency on Instrument and Logger? Perhaps even an "integration" subproject
to handle these cases.
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AbstractInstrumentable extends AbstractLoggable
Posted by Berin Loritsch <bl...@apache.org>.
Leif Mortenson wrote:
> I committed the original patch. I would rather not have Instrument have
> any dependencies.
> Maybe having an AbstractLogEnabledInstrumentable in the logger subproject?
> Not too unmovable on adding the dependency, but it is nice to have it
> independent.
> If the AbstractLogEnabledInstrumentable class was in addition to the
> AbstractInstrumentable
> class, then the dependency would only be at compile time and so users
> who were not using
> framework could still use the Instrumentable classes.
>
> Thoughts?
>
How are we handling optional dependancies now? It would be good as an
option.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AbstractInstrumentable extends AbstractLoggable
Posted by Leif Mortenson <le...@tanukisoftware.com>.
I committed the original patch. I would rather not have Instrument have
any dependencies.
Maybe having an AbstractLogEnabledInstrumentable in the logger subproject?
Not too unmovable on adding the dependency, but it is nice to have it
independent.
If the AbstractLogEnabledInstrumentable class was in addition to the
AbstractInstrumentable
class, then the dependency would only be at compile time and so users
who were not using
framework could still use the Instrumentable classes.
Thoughts?
Leif
Ryan Shaw wrote:
>Okay, attached is a version of AbstractInstrumentable that extends
>AbstractLoggable, and a patch for the instrument package build that
>is neccessary for the new dependency.
>
>>This would add a new dependency from the instrument package
>>to framework, though. Is that a problem for anybody?
>>
>>Ryan Shaw wrote:
>>
>>>I have no problem if whoever checks it in wants to add that.
>>>
>>>Peter Royal wrote:
>>>
>>>>On Wednesday 17 April 2002 09:37 pm, Ryan Shaw wrote:
>>>>
>>>>>Attached is a utility class to ease the implementation
>>>>>of Instrumentables, in the tradition of AbstractLogEnabled.
>>>>>
>>>>It would be nice if it extended AbstractLogEnabled, so you don't have to
>>>>choose :)
>>>>-pete
>>>>
>>>>--
>>>>peter royal -> proyal@managingpartners.com
>>>>
>>>>--
>>>>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>
>>>
>>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
>>
>>------------------------------------------------------------------------
>>
>>/*
>> * Copyright (C) The Apache Software Foundation. All rights reserved.
>> *
>> * This software is published under the terms of the Apache Software License
>> * version 1.1, a copy of which has been included with this distribution in
>> * the LICENSE.txt file.
>> */
>>package org.apache.avalon.excalibur.instrument;
>>
>>import org.apache.avalon.framework.logger.AbstractLogEnabled;
>>
>>/**
>> * Utility class to ease the construction of components that can be instrumented.
>> * Subclasses must override either <code>getChildInstrumentables</code> or
>> * <code>getInstruments</code>, or both, to be of any use.
>> *
>> * @author <a href="mailto:ryan.shaw@stanfordalumni.org">Ryan Shaw</a>
>> */
>>public abstract class AbstractInstrumentable extends AbstractLogEnabled
>>{
>> private String m_name;
>>
>> /**
>> * Any Object which implements Instrumentable can also make use of other
>> * Instrumentable child objects. This method is used to tell the
>> * InstrumentManager about them.
>> *
>> * @return An array of child Instrumentables. This method should never
>> * return null. If there are no child Instrumentables, then
>> * EMPTY_INSTRUMENTABLE_ARRAY can be returned.
>> */
>> public Instrumentable[] getChildInstrumentables()
>> {
>> return Instrumentable.EMPTY_INSTRUMENTABLE_ARRAY;
>> }
>>
>> /**
>> * Obtain a reference to all the Instruments that the Instrumentable object
>> * wishes to expose. All sampling is done directly through the
>> * Instruments as opposed to the Instrumentable interface.
>> *
>> * @return An array of the Instruments available for profiling. Should
>> * never be null. If there are no Instruments, then
>> * EMPTY_INSTRUMENT_ARRAY can be returned. This should never be
>> * the case though unless there are child Instrumentables with
>> * Instruments.
>> */
>> public Instrument[] getInstruments()
>> {
>> return Instrumentable.EMPTY_INSTRUMENT_ARRAY;
>> }
>>
>> /**
>> * Gets the name of the Instrumentable.
>> *
>> * @return The name used to identify a Instrumentable.
>> */
>> public String getInstrumentableName()
>> {
>> return m_name;
>> }
>>
>> /**
>> * Sets the name for the Instrumentable. The Instrumentable Name is used
>> * to uniquely identify the Instrumentable during the configuration of
>> * the InstrumentManager and to gain access to an InstrumentableDescriptor
>> * through the InstrumentManager. The value should be a string which does
>> * not contain spaces or periods.
>> * <p>
>> * This value may be set by a parent Instrumentable, or by the
>> * InstrumentManager using the value of the 'instrumentable' attribute in
>> * the configuration of the component.
>> *
>> * @param name The name used to identify a Instrumentable.
>> */
>> public void setInstrumentableName(String name)
>> {
>> m_name = name;
>> }
>>}
>>
>>
>>------------------------------------------------------------------------
>>
>>Index: build.xml
>>===================================================================
>>RCS file: /home/cvspublic/jakarta-avalon-excalibur/instrument/build.xml,v
>>retrieving revision 1.12
>>diff -u -r1.12 build.xml
>>--- build.xml 8 Apr 2002 12:15:41 -0000 1.12
>>+++ build.xml 18 Apr 2002 02:07:58 -0000
>>@@ -13,6 +13,7 @@
>> <path id="project.class.path">
>> <pathelement path="${java.class.path}"/>
>> <pathelement location="${build.classes}"/>
>>+ <pathelement location="${avalon-framework.jar}"/>
>> <pathelement location="${junit.jar}"/>
>> <pathelement location="${checkstyle.jar}"/>
>> </path>
>>Index: default.properties
>>===================================================================
>>RCS file: /home/cvspublic/jakarta-avalon-excalibur/instrument/default.properties,v
>>retrieving revision 1.3
>>diff -u -r1.3 default.properties
>>--- default.properties 8 Apr 2002 10:32:10 -0000 1.3
>>+++ default.properties 18 Apr 2002 02:07:58 -0000
>>@@ -13,6 +13,12 @@
>> # --------------------------------------------------
>> # REQUIRED LIBRARIES
>> # --------------------------------------------------
>>+
>>+# ----- Avalon Framework, version 4.1 or later -----
>>+avalon-framework.home=${basedir}/../../jakarta-avalon
>>+avalon-framework.lib=${avalon-framework.home}/build/lib
>>+avalon-framework.jar=${avalon-framework.lib}/avalon-framework.jar
>>+
>> # --------------------------------------------------
>>
>> # Settings used to configure compile environment
>>
>>
>>------------------------------------------------------------------------
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>> AbstractInstrumentable.java
>>
>> Content-Type:
>>
>> text/x-java
>> Content-Encoding:
>>
>> base64
>>
>>
>> ------------------------------------------------------------------------
>> instrument-build.patch
>>
>> Content-Type:
>>
>> text/plain
>> Content-Encoding:
>>
>> base64
>>
>>
>> ------------------------------------------------------------------------
>> ??? 1.4
>>
>> Content-Type:
>>
>> text/plain
>>
>>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>