avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject RE: Merlin/Fortress update ?
Date Fri, 02 Aug 2002 17:31:24 GMT
> > Other important points are that a extension provider can 
> > declare its own 
> > phase dependencies and also classic service dependencies.  
> > Merlin will 
> > take care of the ordering of component establishment based on 
> > the phase 
> > and service dependencies that the component publishes. 
> > 
> > Extension providers must implement the following interface:
> > 
> >     org.apache.excalibur.merlin.assembly.resource.Extension
> > 
> > The interface declares the operation "extend( int stage, 
> > Object object, 
> > Context context ) which will be invoked by the Merlin 
> > container during 
> > the appropriate stages.  Merlin defines a number of stages 
> > that can be 
> > associated with an extension provider.  Merlin will only 
> > invoke extend 
> > if the provider declares that it supports the particular stage.
> > 
> > Standard stages include the following:
> > 
> >    CREATE    invoked immediately before initialization
> >    ACCESS    invoked immediate before lookup
> >    RELEASE   invoked immediately before release
> >    DESTROY   invoked immediately before dispose
> >    INNER     equivalent to ACCESS + RELEASE
> >    OUTER     equivalinet to CREATE + DESTROY
> >    ALL       equivalent to INNER + OUTER
> 
> 
> :/
> 
> I kind of like Marcus' solution a bit better.  We have simple
> methods that have a specific meaning.  If a lifecycle event happens
> on more than one type of use (create/destroy/access/release),
> the implementor has the freedom to use OO principles more clearly
> by encapsulating the common elements in a separate method.

what we have here is the flexibility vs simplicity problem.

we could replace all lifecycle interfaces with

public interface LifecycleEnabled
{
	// default stages
	public final static String STAGE_ENABLE_LOGGING = "LogEnabled";
	public final static String STAGE_CONFIGURE = "Configurable";
	public final static String STAGE_START = "Start";
	public final static String STAGE_STOP = "Stop";
	// ...

	handleStage( String phase, Object parameters )
			throws LifecycleException;
}

public abstract class AbstractLifecycleEnabled
		implements LifecycleEnabled
{
	public Object handleStage( String phase, Object[] parameters )
			throws LifecycleException
	{
		switch(phase)
		{
			case STAGE_ENABLE_LOGGING:
			   logEnabled( (Logger)parameters[0] );
			   return null;
			case STAGE_CONFIGURE:
			   configure( (Configuration)parameters[0] );
			   return null;
			default:
			   return ExtensionManager.handleStage( this,
					phase, parameters );
		}
	}

	abstract void logEnabled( Logger logger );
	abstract void configure( Configuration configuration );
}

public NoopLifecycleEnabled
{
	void logEnabled( Logger logger ) {}
	void configure( Configuration configuration ) {}
}

public MyComponent extends NoopLifecycleEnabled
{
	void configure( Configuration configuration )
	{
		// do stuff
	}
}

which would make working with the standard lifecycle somewhat more
complex but extension easier. It is a matter of where to put the
complexity I guess.
I like Marcus' version as writing an extension is more similar to
writing a component that way. To follow this line of thought completely
it should probably be something like:

class PersistentConfigurableHandler implements
		CreationExtensionHandler, DestructionExtensionHandler
{
     /** By contract, Other methods are only called if this returns
	 true. This is defined in ExtensionHandler, the common
	 superinterface to the implemented interfaces. */
     boolean accept( Object obj )
     {
          if( obj instanceof PersistantConfigurable )
		return true;

          return false;
     }

     /** from CreationExtensionHandler */
     void create( Object component, Context context )
	     throws PersistentConfigurationException
     {
     	((PersistantConfigurable)component).configure(
		(Configuration)context.get("configuration" ) );
     }
     /** from DestructionExtensionHandler */
     void destroy( Object component, Context context )
	     throws PersistentConfigurationException
     {
     	Configuration = ((PersistantConfigurable)component)
			.saveConfiguration();
     }
}

which would make it the extension setup even more similar to the
'normal' avalon framework lifecycle.

cheers,

- Leo



--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message