Lifecycle extension lifecycle order?? Was: avalon-excalibur/lifecycle/src

[dv...@phpapp.org]

Hi all,

Your discussion remind me something that seems very important to me about
lifecycle extension.

As i see the two lifecycle extension interfaces, there is no mean to impose a
specific order while applying the extensions. This means that a lifecycle
extension provider has no mean to tell the lifecycle extension manager when it
must be applied relatively (in time) to other extensions during a specified stage.

(Example : Serviceable.service() before Initializable.initialize() even if they
are at the same stage.)

I think the combination of lifecycle extensions is a use case we must think
about. For example in an attempt to implement core avalon lifecycle with the
lifecycle extension mechanism you will need this kind of ordering specification.

I would think the resolution of the order as a kind of incremental ordering
while extensions are discovered (at the container *boot* time). This may be
compared to the serialization of the order of some modules' compilation based on
their respective dependencies.

To conclude, i personally think the lifecycle extension mechanism needs to be
more thought, even if i find it usefull and the portability it can provide for
containers very attractive.

Cheers,
A+. Didier.

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

Re: Lifecycle extension lifecycle order?? Was: avalon-excalibur/lifecycle/src

[Stephen McConnell <mc...@apache.org>]

dvillevalois@phpapp.org wrote:

>Hi all,
>
>Your discussion remind me something that seems very important to me about
>lifecycle extension.
>
>As i see the two lifecycle extension interfaces, there is no mean to impose a
>specific order while applying the extensions. This means that a lifecycle
>extension provider has no mean to tell the lifecycle extension manager when it
>must be applied relatively (in time) to other extensions during a specified stage.
>
>(Example : Serviceable.service() before Initializable.initialize() even if they
>are at the same stage.)
>
>I think the combination of lifecycle extensions is a use case we must think
>about. For example in an attempt to implement core avalon lifecycle with the
>lifecycle extension mechanism you will need this kind of ordering specification.
>
>I would think the resolution of the order as a kind of incremental ordering
>while extensions are discovered (at the container *boot* time). This may be
>compared to the serialization of the order of some modules' compilation based on
>their respective dependencies.
>
>To conclude, i personally think the lifecycle extension mechanism needs to be
>more thought, even if i find it usefull and the portability it can provide for
>containers very attractive.
>  
>

Hi Didier:

The concerns your raising related to phase ordering and aspects of how a 
container manages multiple handlers. These issue are not exposed under 
the current package - because they are container specific today.  I 
don't kown what the Fortress approach is off-hand, but the Merlin 
appoach when dealing with multiple phases in a single component is to 
apply stages in the same order as specificed in the component meta-info.  

For example, the Assembly package includes some demonstrations of a 
component type that declares multiple handler depedencies:

  <type>
    <stages>
      <stage type="org.apache.avalon.playground.Exploitable" />
      <stage type="org.apache.avalon.playground.Demonstratable"/>
    </stages>
  </type>

In the above example, the Exploitable stage handler will be applied 
first, followed by the Demonstratable handler.

Cheers, Steve.

>
>Cheers,
>A+. Didier.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>  
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net




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

Re: Lifecycle extension lifecycle order?? Was: avalon-excalibur/lifecycle/src

[Didier Villevalois <dv...@phpapp.org>]

Berin Loritsch wrote:

> For LifeCycleExtensions, the idea so far is to have them be the last
> thing before Initializable.initialize() is called. 

Okay for this.

> In Fortress, you handle the order explicitly by adding your Creators and
> Accessors in the order you want them to be run.  Merlin has its own
> mechanism for ensuring order--and it is a little more automated. 

Well, this is like i thought it was. (Sorry i did not verify before you 
tell :) )

> You can group all your extensions into one Creator or one Accessor, as
> appropriate. 

This is pretty cool for dependently implemented extensions. For example, 
this might well fit an EJB container implementation as all the needed 
extensions are functionnaly closely related.

But what for extensions developped independently ? Example i could have 
a component that is (let us say) Securable and Persistable. Let's say it 
uses its security supplied knowledge to decide if its state should be 
retrieved during the Persistable.loadData(). (I do not want to discuss 
if this design is good or not because i won't do that like this but...) 
So what happens if Persistable.loadData() is called before 
Securable.secure() ?

I would assume (as a component developper) that some informations exist 
about this. But what if don't have any waranty about the application 
order. There should be a contract explicitely stated about this in the 
lifecycle extension specification.

Else i am confident that everybody will reprogram its own extensions if 
it does not have control over the container of the assembly meta-data. 
Another drift may be that component implementors describe what they do 
expect about the ordering of extensions. But what next if two components 
require different ordering ???

Maybe this could be fixed by saying like "no order of extensions 
application can be assumed, and recommendation is to do critical 
processing in the (last called) initialize() method". But this sounds to 
me like a hack.

Leo. speaks about container pluggable implementations of extensions. But 
those do not remain  pluggable if the container needs to have 
extra-knowledge about what is their ordering. And this is worst even if 
that is the application assembler that needs to know. Am i wrong ?

I would propose a mechanism to express this ordering from the extension 
provider.
Together with an extension specification, the provider describes what 
ordering policy it follows. And in its implementation, he uses a 
mechanism to ensure this ordering.

This mechanism could be implemented in two ways :
* Preordering at boot time based on declarative informations (meta-data 
xml files are not required this can be done with an extension MetaClass)
* Delaying if not all required extensions have been applied (this can be 
done by some programmatic assertions at the beginning of the 
Creator/Accessor execution but this is dangerous as this can introduce 
dead-locks)

Extensions will be defined as layers, each one augmenting the contracts 
that tie the component and the container.

MetaClass example:

class PersistableExtension implements ExtensionMetaClass
{
    public Class[] loadsAfter()
    {
        return new Class[] { SecurableExtension.class };
    }
}

And then classical dependency graph resolution... But i am not yet 
convinved by this solution. Maybe another solution would be to cut the 
four phases in more phases. But this would mean actually creating the 
extensions... Damned, can't find better than ordering declarations.

> I think we did address all those issues before, and there was some great
> synergy and good understanding between the developers who developed it:
> Marcus Crafter, Stephen McConnell, and myself. 

Sorry, i did look to the archive but did not succeed (dislikes this 
search) to find relevant informations. I hope to not come over things 
that were previously stated and that there is no offense.

> If there are any questions, please ask.

Thanks! I followed your advice. :)

A+. Didier.


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

Re: Lifecycle extension lifecycle order?? Was: avalon-excalibur/lifecycle/src

[Berin Loritsch <bl...@apache.org>]

dvillevalois@phpapp.org wrote:
> Hi all,
> 
> Your discussion remind me something that seems very important to me about
> lifecycle extension.
> 
> As i see the two lifecycle extension interfaces, there is no mean to impose a
> specific order while applying the extensions. This means that a lifecycle
> extension provider has no mean to tell the lifecycle extension manager when it
> must be applied relatively (in time) to other extensions during a specified stage.
> 
> (Example : Serviceable.service() before Initializable.initialize() even if they
> are at the same stage.)

For LifeCycleExtensions, the idea so far is to have them be the last
thing before Initializable.initialize() is called.

In Fortress, you handle the order explicitly by adding your Creators and
Accessors in the order you want them to be run.  Merlin has its own
mechanism for ensuring order--and it is a little more automated.

> I would think the resolution of the order as a kind of incremental ordering
> while extensions are discovered (at the container *boot* time). This may be
> compared to the serialization of the order of some modules' compilation based on
> their respective dependencies.

You can group all your extensions into one Creator or one Accessor, as
appropriate.

> To conclude, i personally think the lifecycle extension mechanism needs to be
> more thought, even if i find it usefull and the portability it can provide for
> containers very attractive.

I think we did address all those issues before, and there was some great
synergy and good understanding between the developers who developed it:
Marcus Crafter, Stephen McConnell, and myself.

If there are any questions, please ask.


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