On Tue, 2003-07-15 at 19:19, Stephen McConnell wrote:
> I've completed the re-shuffling of the Merlin Meta content into a
> separate sandbox project and now the Merlin build has been restructured
> to use Avalon Meta instead of Merlin Meta (at the meta-info level).
> There is a direct and immediate impact of this change ...
Just checked out the meta module and built it. Everything looks good.
I've been holding off mucking around in the meta package until this
restructuring was done, but now that things look a little more stable,
I've got one question:
Do stages/phases have to be valid classes?
In other words, currently when we say we have a lifecycle or stage
extension, the verifier makes sure that the component implements the
stage class:
public void verifyImplementsPhases( final String name,
final Class implementation,
final Class[] phases )
throws VerifyException
{
for( int i = 0; i < phases.length; i++ )
{
if( !phases[ i ].isAssignableFrom( implementation ) )
{
final String message =
REZ.getString( "verifier.noimpl-phase.error",
name,
implementation.getName(),
phases[ i ].getName() );
throw new VerifyException( message );
}
}
}
But the stage names are really just Strings. What if we want to create
a stage extension which acts on components where there actually is _no_
implemented stage interface. Instead, the extension uses the supplied
meta-info (Context object for Lifecycle extensions, Appliance Object for
stage deployment extensions) and applies this information in some way to
the object. Examples might include a JNDI extension which uses either
meta-info or meta-data to know how or where to bind the object. In this
case, we really don't want some marker interface for the service to
implement. We just want a string stage name which the extension can
pickup on.
Now, this could be implemented by developing a standard service/block
which via it's configuration is passed a set of services to bind (or
somehow extend) along with any other needed info/data. I'm not sure
which is the better solution. I believe the extension solution could be
implemented just by changing the verifier.
--
jaaron <http://jadetower.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
