You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by J Aaron Farr <ja...@yahoo.com> on 2003/07/16 05:05:54 UTC
Re: [merlin] meta migration strategy
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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] meta migration strategy
Posted by Stephen McConnell <mc...@apache.org>.
Stephen McConnell wrote:
>
>
> J Aaron Farr wrote:
>
>> 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.
>>
>
> Yep - your right.
> In effect the stage descriptor is using the interface classname as a
> key which in turn is mapped to an interface classname declared by an
> extension. The same thing can be achived simply be declaring a urn
> style key. This would simplify both StageDescriptor and
> ExtensionDescriptor.
> I'll look into this this evening.
>
>>
>> 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.
>>
>
> I agree.
>
> Cheers, Steve.
>
Aaron:
Have just completed the proces of going though the meta package,
composition abnd assembly APIs and validating things against a stage and
extension model that is keyed against strings (urn keys) instread of
interface c lassnanames. Baically I have everything building locally
without problem - and doing what it should do (test case confirmance
etc.).I've updated the meta-info readers and writers to recognize the
following format for stages and extensions:
<componentname="demo-stage-consumer" class="SomeClass">
<stage key="urn:osm:some-stage-name"/>
</component>
<componentname="demo-stage-provider" class="AnotherCass">
<extension key="urn:osm:some-stage-name"/>
</component>
Using this approach, you can have multiple candidate stage providers in
which case the Merlin auto selection processes will kick-in. I've also
made sure that existing declarations are supported (simply translating a
type declation to a key).
I'll commit things in sync across the meta anf merlin packages within
the next hour.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] meta migration strategy
Posted by Stephen McConnell <mc...@apache.org>.
J Aaron Farr wrote:
>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.
>
Yep - your right.
In effect the stage descriptor is using the interface classname as a key
which in turn is mapped to an interface classname declared by an
extension. The same thing can be achived simply be declaring a urn style
key. This would simplify both StageDescriptor and ExtensionDescriptor.
I'll look into this this evening.
>
>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.
>
I agree.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org