You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2003/02/09 15:15:24 UTC
[proposal] avalon-framework state checker
Hi peeps,
lots of code that assumes a 'hostile' environment keeps track of the
lifecycle and ensures it is correctly followed. Part of the defensive
coding paradigm I guess. Often not to accurately, though :D
I wrote a class org.apache.avalon.framework.State which codifies this
correct behaviour. The proposal is that it is included in framework
4.1.4. I've yet to test it (and write the testcase).
comments?
cheers,
- Leo
Example usage is something like:
/**
* Convenience base class. Typical use involves overriding initialize()
and dispose(),
* but make sure to call super on them.
*
* @author <a href="mail at leosimons dot com">Leo Simons</a>
* @version $Id$
*/
public abstract class AbstractService
implements LogEnabled, Configurable, Contextualizable,
Serviceable, Initializable,
Disposable
{
// ---------------------------------------------------------------
// Instance Properties
// ---------------------------------------------------------------
/**
* Provides access to the logger.
*/
protected Logger m_logger = null;
protected ServiceManager m_serviceManager = null;
/**
* Provides access to the serviceManager.
*/
protected Configuration m_configuration = null;
/**
* Provides access to the context.
*/
protected Context m_context = null;
/**
* Provides access to the current state.
*/
protected int m_state = State.STATIC;
// ---------------------------------------------------------------
// Constructors
// ---------------------------------------------------------------
/**
* default constructor.
*/
public void ContainerImpl()
{
m_state = State.change( m_state, State.CONSTRUCTED, this );
}
// ---------------------------------------------------------------
// Lifecycle Methods
// ---------------------------------------------------------------
/** @see LogEnabled@enableLogging */
public void enableLogging( Logger logger )
{
m_state = State.change( m_state, State.LOGENABLED, this );
m_logger = logger;
}
/** @see Contextualizable#contextualize */
public void contextualize( Context context )
throws ContextException
{
m_state = State.change( m_state, State.CONTEXTUALIZED, this );
m_context = context;
}
/** @see Configurable#configure */
public void configure( Configuration configuration )
throws ConfigurationException
{
m_state = State.change( m_state, State.CONFIGURED, this );
m_configuration = configuration;
}
/** @see Serviceable#service */
public void service( ServiceManager manager )
throws ServiceException
{
m_state = State.change( m_state, State.SERVICED, this );
m_serviceManager = manager;
}
/** @see Initializable#initialize */
public void initialize()
throws Exception
{
m_state = State.change( m_state, State.INITIALIZED, this );
}
/** @see Disposable#dispose */
public void dispose()
{
m_state = State.change( m_state, State.DISPOSED, this );
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] avalon-framework state checker
Posted by Peter Donald <pe...@realityforge.org>.
On Mon, 10 Feb 2003 01:15, Leo Simons wrote:
> I wrote a class org.apache.avalon.framework.State which codifies this
> correct behaviour. The proposal is that it is included in framework
> 4.1.4. I've yet to test it (and write the testcase).
If you want it you can keep outside of framework ... much like the
CopmponentStateValidator in util... the one we have previously decided not to
put in framework.
If your code actually needs this then it is likely that you system is so badly
fubarred anyway that no amount of defensive coding will help you fix it.
--
Cheers,
Peter Donald
------------------------------------
The two secrets to success:
1- Don't tell anyone everything.
------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] avalon-framework state checker
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
> Hi peeps,
>
> lots of code that assumes a 'hostile' environment keeps track of the
> lifecycle and ensures it is correctly followed. Part of the defensive
> coding paradigm I guess. Often not to accurately, though :D
>
> I wrote a class org.apache.avalon.framework.State which codifies this
> correct behaviour. The proposal is that it is included in framework
> 4.1.4. I've yet to test it (and write the testcase).
>
> comments?
We already have one in Excalibur Util. THe ComponentStateValidator,
and its associated test cases.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] avalon-framework state checker
Posted by Leo Simons <le...@apache.org>.
Leo Simons wrote:
> Berin Loritsch wrote:
>
>> We already have one in Excalibur Util. THe ComponentStateValidator,
>> and its associated test cases.
>
> acked (didn't see it before, probably because we don't use it
> ourselves). There's lots of code that should change to use it instead of
> doing this stuff only partially (like our various containers).
actually not true either. Most code rightfully doesn't bother checking.
org.apache.avalon.merlin.container.impl needs updating though (which is
what I was looking at writing this class :D).
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] avalon-framework state checker
Posted by Leo Simons <le...@apache.org>.
Berin Loritsch wrote:
> We already have one in Excalibur Util. THe ComponentStateValidator,
> and its associated test cases.
acked (didn't see it before, probably because we don't use it
ourselves). There's lots of code that should change to use it instead of
doing this stuff only partially (like our various containers).
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org