You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@avalon.apache.org by bl...@apache.org on 2003/03/11 14:29:30 UTC
cvs commit: avalon-excalibur/lifecycle/src - New directory
bloritsch 2003/03/11 05:29:30
avalon-excalibur/lifecycle/src - New directory
---------------------------------------------------------------------
To unsubscribe, e-mail: cvs-unsubscribe@avalon.apache.org
For additional commands, e-mail: cvs-help@avalon.apache.org
Re: Lifecycle extension lifecycle order?? Was: avalon-excalibur/lifecycle/src
Posted by 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
Posted by 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
Posted by 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
Lifecycle extension lifecycle order?? Was: avalon-excalibur/lifecycle/src
Posted by 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: avalon-excalibur/lifecycle/src
Posted by Leo Simons <le...@apache.org>.
Stephen McConnell wrote:
> Wow - slow down - go read the instrument documetation.
I just went over all that this weekend :D
> A lifecycle extension is two parts:
>
> * an interface implemented by a component that represents
> a supplimentary stage (as distrinct from a work interface)
> * an implementation of a handler that is capable of supporting
> the stage using the contracts defined by the lifecycle
> package
its a case of terminology. I made the exact same seperation; the case I
was making is that you can define a supplementary stage without the
handler. The component requiring the supplementary stage doesn't care
how it is handled, as long as it is handled. A container can implement
support for that handling without a lifecycle extension package.
>> so it is impossible to define a generic way to handle lifecycle
>> management from the container side, and also impossible to define a
>> generic way to create plugins to assist in that management.
>
> Correction.
>
> It is possible - that was the objective of the project. That objective
> was reached. We have this working today.
agreed. Case of terminology again. It is "general" in that it can be
used across multiple containers. Not in that it can be satisfactory
successfully applied in every container.
Your assumption (example again) is that any container providing support
for Instrumentable will do so by having an instrumentable "handler" or
some kind. I can provide support for instrumentable in a container
without having lifecycle.jar on my path. Just did so this weekend :D
>> MyContainerUtil extends ContainerUtil
>> {
>> setupInstrumentation( Object obj, InstrumentManager im )
>> { /* ... */ }
>> }
cheers!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-excalibur/lifecycle/src
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> What is a lifecycle extension?
>
> It is the concept
>
> "(1) I have here this interface, which exposes some methods that are
> to be called somewhere in the lifecycle of a component in a
> well-defined manner."
>
> it is not
>
> "(2) I also have some code here which can do the management of this
> part of the lifecycle on behalf of the container."
>
> though that is extremely useful too.
>
> (1) doesn't need anything special:
>
> /** this is a lifecycle extension interface! */
> interface Instrumentable
> {
> setupInstrumentation( InstrumentManager manager );
> }
>
> this is IMO a very good idea, and the idea belongs in framework. It
> requires no code. It would be nice to have a standard way of marking
> an interface as being intended for lifecycle extension, but we need a
> metadata setup for that.
Wow - slow down - go read the instrument documetation.
A lifecycle extension is two parts:
* an interface implemented by a component that represents
a supplimentary stage (as distrinct from a work interface)
* an implementation of a handler that is capable of supporting
the stage using the contracts defined by the lifecycle
package
Enabling - protability of extensions across different containers.
>
> (2) is about the way a container handles instrumentation. The problem
> is that we have not defined "container",
Not required.
Defintion of a container is not something components need to see - the
lifecycle extension innterface are things that need to see by component
providing plug-in support for new stages.
> nor have we defined the "standard assumed container setup",
Not required.
The lifecycle extension interfaces only deal with the interfaces
implemented by handlers. This is indepedent of particular container
implementations. In fact if you look at Merlin and Fortress - their
respective impleemntations and setup are distinctly different.
> so it is impossible to define a generic way to handle lifecycle
> management from the container side, and also impossible to define a
> generic way to create plugins to assist in that management.
Correction.
It is possible - that was the objective of the project. That objective
was reached. We have this working today. Remember - this is dealing
with the interface contracts - its not attempting to define the total
deployment scenario. I agree that more in this area can be done
concerning common approaches to things like setup and so on - but that
is orthoginal to the interface contracts.
Cheers, Steve.
>
> Leo Sutic wrote:
>
>> While there are many ways to handle lifecycle extensions, there are
>> many ways of handling configuration, initialization, contextualization,
>> logging and so on but we still have settled on just one way in Avalon.
>>
>> That there are several ways to accomplish one goal should not keep
>> up from stating that "well, *this* is how we do it in Avalon".
>
>
> +1, where "Avalon" is the project @ avalon.apache.org :D
>
>> It was my understanding that the instrument package was an extension
>> that
>> would be handled via the lifecycle extension package instead of moving
>> it (the instrument package) into Framework.
>
>
> it is possible to manage instrumentation as a lifecycle extension
> using the lifecycle package moved from excalibur to sandbox and now
> back into excalibur. The instrument materials don't really care how
> they are integrated into a container. A container could opt to have a
> hard dependency on instrumentation, and use something as simple as
>
> MyContainerUtil extends ContainerUtil
> {
> setupInstrumentation( Object obj, InstrumentManager im )
> { /* ... */ }
> }
>
>> I can see the rationale for standardizing lifecycle extensions, so,
>> in my opinion, they should definitely be in framework. Not in an
>> extension,
>> not in a standard extension, but in framework.
>
>
> I disagree. I think the current content of the
> org.apache.avalon.lifecycle package should not be a part of
> avalon-framework.jar.
>
> As an example, I'm perfectly okay with saying that all containers the
> avalon projects produces provide support for lifecycle extensions, and
> that they do so using the same lifecycle-extension-support-package.
> I'm not okay with saying that Plexus should support lifecycle
> extensions, and not at all with saying that it should provide support
> for Instrumentable packages by using that same
> lifecycle-extension-support-package.
>
> to contrast, I am okay with saying that Plexus is not a compliant
> avalon container if it calls initialize() before service() on an
> object that implements both Initializable and Servicable.
>
> Of course I'm just using the name Plexus as an example container
> developed outside of the avalon project which supports
> avalon-framework but for which I have no idea if and how it supports
> lifecycle extensions.
>
> cheers!
>
> - Leo
>
>
>
> ---------------------------------------------------------------------
> 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: avalon-excalibur/lifecycle/src
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: news [mailto:news@main.gmane.org] On Behalf Of Leo Simons
>
> What is a lifecycle extension?
>
> It is the concept
>
> "(1) I have here this interface, which exposes some methods
> that are to
> be called somewhere in the lifecycle of a component in a well-defined
> manner."
>
> it is not
>
> "(2) I also have some code here which can do the management
> of this part of the lifecycle on behalf of the container."
>
> though that is extremely useful too.
OK, so (1) is from the component's side (i.e. a request for the
container to
do something with/to the component), and (2) is from the container's
side
(i.e. the code that will do that something).
Then, all stages of a component's usual lifecycle - Configurable, etc. -
can be realized as lifecycle extensions. So this is a meta-model of the
lifecycle.
Right?
Then, why doesn't the meta-model belong with the model?
If lifecycle extensions are made framework-scoped instead of container
specific, then you can use one package for AltRMI remoting in all
containers,
you can use one package for instrumentation in all containers, etc.
etc....
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-excalibur/lifecycle/src
Posted by Leo Simons <le...@apache.org>.
What is a lifecycle extension?
It is the concept
"(1) I have here this interface, which exposes some methods that are to
be called somewhere in the lifecycle of a component in a well-defined
manner."
it is not
"(2) I also have some code here which can do the management of this part
of the lifecycle on behalf of the container."
though that is extremely useful too.
(1) doesn't need anything special:
/** this is a lifecycle extension interface! */
interface Instrumentable
{
setupInstrumentation( InstrumentManager manager );
}
this is IMO a very good idea, and the idea belongs in framework. It
requires no code. It would be nice to have a standard way of marking an
interface as being intended for lifecycle extension, but we need a
metadata setup for that.
(2) is about the way a container handles instrumentation. The problem is
that we have not defined "container", nor have we defined the "standard
assumed container setup", so it is impossible to define a generic way to
handle lifecycle management from the container side, and also impossible
to define a generic way to create plugins to assist in that management.
Leo Sutic wrote:
> While there are many ways to handle lifecycle extensions, there are
> many ways of handling configuration, initialization, contextualization,
> logging and so on but we still have settled on just one way in Avalon.
>
> That there are several ways to accomplish one goal should not keep
> up from stating that "well, *this* is how we do it in Avalon".
+1, where "Avalon" is the project @ avalon.apache.org :D
> It was my understanding that the instrument package was an extension
> that
> would be handled via the lifecycle extension package instead of moving
> it (the instrument package) into Framework.
it is possible to manage instrumentation as a lifecycle extension using
the lifecycle package moved from excalibur to sandbox and now back into
excalibur. The instrument materials don't really care how they are
integrated into a container. A container could opt to have a hard
dependency on instrumentation, and use something as simple as
MyContainerUtil extends ContainerUtil
{
setupInstrumentation( Object obj, InstrumentManager im )
{ /* ... */ }
}
> I can see the rationale for standardizing lifecycle extensions, so,
> in my opinion, they should definitely be in framework. Not in an
> extension,
> not in a standard extension, but in framework.
I disagree. I think the current content of the
org.apache.avalon.lifecycle package should not be a part of
avalon-framework.jar.
As an example, I'm perfectly okay with saying that all containers the
avalon projects produces provide support for lifecycle extensions, and
that they do so using the same lifecycle-extension-support-package. I'm
not okay with saying that Plexus should support lifecycle extensions,
and not at all with saying that it should provide support for
Instrumentable packages by using that same
lifecycle-extension-support-package.
to contrast, I am okay with saying that Plexus is not a compliant avalon
container if it calls initialize() before service() on an object that
implements both Initializable and Servicable.
Of course I'm just using the name Plexus as an example container
developed outside of the avalon project which supports avalon-framework
but for which I have no idea if and how it supports lifecycle extensions.
cheers!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-excalibur/lifecycle/src
Posted by Leo Simons <le...@apache.org>.
Stephen McConnell wrote:
> Leo Simons wrote:
>
> Correction - I'm not implying that "lifecycle extensions are part of the
> framework" - if fact I've said the opposite.
uh, okay then!
>> lifecycle extensions are but one way of several setups currently in
>> use for accomplishing a certain goal. So the lifecycle stuff is not a
>> "standard extension" of avalon-framework, just "an extension".
>
> I agree.
cool :D
> So, what is the point you are raising?
that it makes no sense to put this stuff into the avalon cvs module
instead of into the excalibur cvs module /at this point in time/ because
it would be work that would unneedlessly delay releases and result in
confusion, integration build failures, and other nasty stuff. IOW: "you
should not be worrying about cvs structure so much" :D
cheers!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-excalibur/lifecycle/src
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> you should not be worrying about cvs structure so much. End users
> don't see it. We should use the cvs setup that makes it easiest to
> develop.
>
> In the meantime, responding to the implied "lifecycle extensions are
> part of the framework":
Correction - I'm not implying that "lifecycle extensions are part of the
framework" - if fact I've said the opposite.
I do happen to think that people are confusing avalon CVS with Avalon
Framework - whicb is perhaps natural because currently avalon framework
is the only thing in the avalon CVS.
>
> lifecycle extensions are but one way of several setups currently in
> use for accomplishing a certain goal. So the lifecycle stuff is not a
> "standard extension" of avalon-framework, just "an extension".
I agree.
So, what is the point you are raising?
How does this address the question of where the appropriate place is for
two interfaces that only deal with framework contract extension?
Cheers, Steve.
>
> cheers,
>
> - Leo
>
> Stephen McConnell wrote:
>
>>
>>
>> bloritsch@apache.org wrote:
>>
>>> bloritsch 2003/03/11 05:29:30
>>>
>>> avalon-excalibur/lifecycle/src - New directory
>>
>>
>> Berin:
>>
>> This should be under the avalon CVS, not excalibur. It not a utility
>> - it's a couple of interfaces that define extensions to the framework
>> contract.
>>
>> Cheers, Steve.
>
>
>
>
> ---------------------------------------------------------------------
> 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: avalon-excalibur/lifecycle/src
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: news [mailto:news@main.gmane.org] On Behalf Of Leo Simons
>
> lifecycle extensions are but one way of several setups
> currently in use
> for accomplishing a certain goal. So the lifecycle stuff is not a
> "standard extension" of avalon-framework, just "an extension".
While there are many ways to handle lifecycle extensions, there are
many ways of handling configuration, initialization, contextualization,
logging and so on but we still have settled on just one way in Avalon.
That there are several ways to accomplish one goal should not keep
up from stating that "well, *this* is how we do it in Avalon".
It was my understanding that the instrument package was an extension
that
would be handled via the lifecycle extension package instead of moving
it (the instrument package) into Framework.
I can see the rationale for standardizing lifecycle extensions, so,
in my opinion, they should definitely be in framework. Not in an
extension,
not in a standard extension, but in framework.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-excalibur/lifecycle/src
Posted by Leo Simons <le...@apache.org>.
you should not be worrying about cvs structure so much. End users don't
see it. We should use the cvs setup that makes it easiest to develop.
In the meantime, responding to the implied "lifecycle extensions are
part of the framework":
lifecycle extensions are but one way of several setups currently in use
for accomplishing a certain goal. So the lifecycle stuff is not a
"standard extension" of avalon-framework, just "an extension".
cheers,
- Leo
Stephen McConnell wrote:
>
>
> bloritsch@apache.org wrote:
>
>> bloritsch 2003/03/11 05:29:30
>>
>> avalon-excalibur/lifecycle/src - New directory
>
> Berin:
>
> This should be under the avalon CVS, not excalibur. It not a utility -
> it's a couple of interfaces that define extensions to the framework
> contract.
>
> Cheers, Steve.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-excalibur/lifecycle/src
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>>>> This should be under the avalon CVS, not excalibur. It not a
>>>> utility - it's a couple of interfaces that define extensions to the
>>>> framework contract.
>>>
>>>
>>>
>>>
>>> :/ I don't think you are going to get consensus on that.
>>
>>
>>
>>
>> Lets' discuss it and see.
>>
>>> Esp. since
>>> by the time we are done with handling these things, they might go
>>> away.
>>
>>
>> Sorry - I'm using extensions and I'm not about to drop support for
>> extensions.
>
>
> I did not say that we would not be able to support extending the
> lifecycle. All I am saying is that the is a possibility of doing
> it in a more elegant way in the future.
Berin:
Its kind of accademic if one likes/dislikes/or-whatever the lifecycle
interfaces (I happen to feel that the meet a requirement and I havn't
had any problems with them). The subject here is the *release* of the
lifecycle package. Before removal from from sandbox there are a couple
of things to consider:
(a) do we have agreement on the release of lifecycle - in
particular, the migration out of sandbox
(b) what is the CVS destination that the package will migrate to
>
>
> I also am using extensions for my GUIApp project over at SourceForge.
> Vincent has been helping me make it sing--including support for an
> event bus and more. I myself don't want to see them go away.
>
>>> Peter's interceptor ideas have merit, and with the advent of
>>> utilities like CGLib, it makes it really easy to use interceptors.
>>>
>>> I understand your position, but in order to get a release RSN I
>>> suggest going with the least radical path towards adoption.
>>
>>
>> I'm tempted to say that this strategy will backfire. Even we are
>> releasing the lifecycle package or not. If we release it we should
>> do it properly. If we are not releasing it then you should kill of
>> referenced to extension in Fortress. I don't know if this is viable
>> or not in Fortress - I do know that (a) interfaces are required in
>> Merlin, and (b) that the interfaces have been validated and have
>> proved functional and valuable.
>
>
> We need to release it. I would be able to kill off the reference to
> it in Fortress, BUT then I would lose instrumentation support (I have
> a InstrumentableCreator that takes care of the integration).
I'm 100% with you - *release* is the objective.
>
> The question is *where* do they go.
Yes.
> I really don't think that they should be in Avalon Framework.
I agree - see prev. email where I said the same thing. I said that
lifecycle extensions below in the avalon CVS because that represent a an
optional extension to the component contract. The package itself is not
a utility.
To be clear - I do not see the avalon CVS repository as exclusive to
framework. In fact we have already discussed this substantially a few
months ago. That discussion focussed on what things belong where. The
process identified excalibur as the place for utilities for building
containers and components. It also identified the avalon CVS as the
place for constructs relating to the container/component contract
(currently framework) and eventually other things like meta models, or
interfaces dealing with framework extension.
> They kind of have the same conundrum
> as the Instrument package. They are a set of interfaces, which can
> be used in other projects. Both of these projects sit between
> Framework and the components/containers.
I don't see Instrument on the same level as the lifecycle extensions.
Lifecycle is a very simple contract for declaring lifecycle extension
semantics. It does not contain a lifecycle extension implementation
(that's a container concern). The Instrument package is an example of a
set of interfaces that should be using the lifecycle extension mechanism
to introduce itself formally. Instrument is an example of a lifecycle
stage interface and Instrument Manager is an example of a stage handler.
Clearly, the instrument suite is an instance of an extension.
>
>> Currently the avalon CVS contains the framework. This does not mean
>> that framework is the only project at this level. We have already
>> discussed the need to start work on the seperation of framework imp
>> and interfaces which means we will rapidly being seeing the emergence
>> of at least two projects in framework. The lifecycle extension
>> simply belong at this level. I am not suggesting that the extension
>> interfaces be included in framework - only that that the extension
>> package belongs in the avalon cvs - not excalibur.
>
>
> Can you put up a proposal for it?
OK - I'll put something together ASAP.
> I already did the vote for moving it
> to excalibur, to which I believe you gave your +1. I was not aware that
> you felt it should be in the "Avalon" repository.
I did raise it in my reply to the email you referenced.
;-)
Cheers, Steve.
--
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: avalon-excalibur/lifecycle/src
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>>> This should be under the avalon CVS, not excalibur. It not a utility
>>> - it's a couple of interfaces that define extensions to the framework
>>> contract.
>>
>>
>>
>> :/ I don't think you are going to get consensus on that.
>
>
>
> Lets' discuss it and see.
>
>> Esp. since
>> by the time we are done with handling these things, they might go
>> away.
>
> Sorry - I'm using extensions and I'm not about to drop support for
> extensions.
I did not say that we would not be able to support extending the
lifecycle. All I am saying is that the is a possibility of doing
it in a more elegant way in the future.
I also am using extensions for my GUIApp project over at SourceForge.
Vincent has been helping me make it sing--including support for an
event bus and more. I myself don't want to see them go away.
>> Peter's interceptor ideas have merit, and with the advent of
>> utilities like CGLib, it makes it really easy to use interceptors.
>>
>> I understand your position, but in order to get a release RSN I
>> suggest going with the least radical path towards adoption.
>
> I'm tempted to say that this strategy will backfire. Even we are
> releasing the lifecycle package or not. If we release it we should do
> it properly. If we are not releasing it then you should kill of
> referenced to extension in Fortress. I don't know if this is viable or
> not in Fortress - I do know that (a) interfaces are required in Merlin,
> and (b) that the interfaces have been validated and have proved
> functional and valuable.
We need to release it. I would be able to kill off the reference to
it in Fortress, BUT then I would lose instrumentation support (I have
a InstrumentableCreator that takes care of the integration).
The question is *where* do they go. I really don't think that they
should be in Avalon Framework. They kind of have the same conundrum
as the Instrument package. They are a set of interfaces, which can
be used in other projects. Both of these projects sit between
Framework and the components/containers.
> Currently the avalon CVS contains the framework. This does not mean
> that framework is the only project at this level. We have already
> discussed the need to start work on the seperation of framework imp and
> interfaces which means we will rapidly being seeing the emergence of at
> least two projects in framework. The lifecycle extension simply belong
> at this level. I am not suggesting that the extension interfaces be
> included in framework - only that that the extension package belongs in
> the avalon cvs - not excalibur.
Can you put up a proposal for it? I already did the vote for moving it
to excalibur, to which I believe you gave your +1. I was not aware that
you felt it should be in the "Avalon" repository.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-excalibur/lifecycle/src
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>>
>> bloritsch@apache.org wrote:
>>
>>> bloritsch 2003/03/11 05:29:30
>>>
>>> avalon-excalibur/lifecycle/src - New directory
>>>
>>>
>>
>> Berin:
>>
>> This should be under the avalon CVS, not excalibur. It not a utility
>> - it's a couple of interfaces that define extensions to the framework
>> contract.
>
>
> :/ I don't think you are going to get consensus on that.
Lets' discuss it and see.
> Esp. since
> by the time we are done with handling these things, they might go
> away.
Sorry - I'm using extensions and I'm not about to drop support for
extensions.
> Peter's interceptor ideas have merit, and with the advent of
> utilities like CGLib, it makes it really easy to use interceptors.
>
> I understand your position, but in order to get a release RSN I
> suggest going with the least radical path towards adoption.
I'm tempted to say that this strategy will backfire. Even we are
releasing the lifecycle package or not. If we release it we should do
it properly. If we are not releasing it then you should kill of
referenced to extension in Fortress. I don't know if this is viable or
not in Fortress - I do know that (a) interfaces are required in Merlin,
and (b) that the interfaces have been validated and have proved
functional and valuable.
Currently the avalon CVS contains the framework. This does not mean
that framework is the only project at this level. We have already
discussed the need to start work on the seperation of framework imp and
interfaces which means we will rapidly being seeing the emergence of at
least two projects in framework. The lifecycle extension simply belong
at this level. I am not suggesting that the extension interfaces be
included in framework - only that that the extension package belongs in
the avalon cvs - not excalibur.
Cheers, Steve.
--
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: avalon-excalibur/lifecycle/src
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> Stephen McConnell wrote:
>
>> Berin Loritsch wrote:
>>
>>> Stephen McConnell wrote:
>>>
>>>>
>>>> Berin:
>>>>
>>>> This should be under the avalon CVS, not excalibur. It not a
>>>> utility - it's a couple of interfaces that define extensions to the
>>>> framework contract.
>>>
>>>
>>> :/ I don't think you are going to get consensus on that.
>>
>>
>> Lets' discuss it and see.
>
>
> consider it shown!
Leo ...:-)
What is shown? It's being dicussed. I don't see a conclusion just yet.
> I think Berin is making the right move :D
I think Berin is making the right move in terms of moving forward on the
release. I don't think the Excalibur CVS is a good move - for a number
of reasons (see prior email).
>
>>> Esp. since
>>> by the time we are done with handling these things, they might go
>>> away.
>>
>>
>> Sorry - I'm using extensions and I'm not about to drop support for
>> extensions.
>
>
> yeah but that doesn't mean avalon as a whole is required to support
> extensions.
I didn't say avalon as a whole is required to support extensions.
I don't think that avalon as a whole is required to support extensions.
> Remember that this is alpha code which has not been subject to a
> release vote, so you should not assume consensus (just the lazy
> variant). Given the massive amount of discussions surrounding this
> stuff, I think it is safe to assume there isn't consensus.
I think the term "this is alpha code" is missleading and creates the
suggestion of a risk that frankly is not there. Please - I would
suggest that people take a look at the lifecycle package - any you find
a couple of interfaces that define a contract together with a bunch of
good documentation. You will find information about containers that
provide support. We are not dicussing the containers or their
respective status - we are discussing the release of the lifecycle
extension package which is basically the interfaces that detail a
contractual extension between a container and a component.
>
> If extensions are voted down, avalon is going to drop support for
> them. That would mean you would have to do your support for them
> elsewhere.
Take a look at the package - what support?
Two interfaces - there isn't any support here - the works been done.
>
>
>>> I understand your position, but in order to get a release RSN I
>>> suggest going with the least radical path towards adoption.
>>
>>
>> I'm tempted to say that this strategy will backfire.
>
>
> why?
Because the Berin's suggestion to move the lifecycle package into
excalibur is based on eliminated the need to address the real question.
The real question is about the release of a package that defines a
contract for component lifecycle extension. It need not be the only one
- but but releasing this we are saying that Avalon - this community - is
endorcing an approach to lifecycle extension at the framework level.
This does not make it a mandatory extension to the framework and does
not force anything. But it is important and should be treated as such.
>> Even we are releasing the lifecycle package or not. If we release it
>> we should do it properly.
>
>
> why is releasing it as an independent package "improper"?
Because releasing this under excalibur is inconsistent. It is not a
utility or a component. It is contractual extension relative to the
framework. This is distinclty different from everything else in excalibur.
>
>> Currently the avalon CVS contains the framework. This does not mean
>> that framework is the only project at this level. We have already
>> discussed the need to start work on the seperation of framework imp
>> and interfaces which means we will rapidly being seeing the emergence
>> of at least two projects in framework. The lifecycle extension
>> simply belong at this level. I am not suggesting that the extension
>> interfaces be included in framework - only that that the extension
>> package belongs in the avalon cvs - not excalibur.
>
>
> I suggest we deal with cvs (re)structuring after "Excalibur phase III"
> and phoenix 4.1 have been released, at least. Right now more moving of
> packages will just cause further delays. We need to get to "release
> early release often".
This is trivial. The package over on sandbox is well setup and can be
moved to the "appropriate" place with minimum effort.
Cheers, Steve.
--
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: avalon-excalibur/lifecycle/src
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: news [mailto:news@main.gmane.org] On Behalf Of Leo Simons
>
> If extensions are voted down, avalon is going to drop support
> for them.
> That would mean you would have to do your support for them elsewhere.
Good, at least everyone will know where we stand, then. If we don't get
extensions, then we have to re-solve the issue with how to handle
packages
such as instrument.
I'd rather we went to vote on this one and had it voted down, than
quietly assuming that it will be there (as we did when discussing
whether to put Instrument in framework).
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-excalibur/lifecycle/src
Posted by Leo Simons <le...@apache.org>.
Stephen McConnell wrote:
> Berin Loritsch wrote:
>> Stephen McConnell wrote:
>>>
>>> Berin:
>>>
>>> This should be under the avalon CVS, not excalibur. It not a utility
>>> - it's a couple of interfaces that define extensions to the framework
>>> contract.
>>
>> :/ I don't think you are going to get consensus on that.
>
> Lets' discuss it and see.
consider it shown! I think Berin is making the right move :D
>> Esp. since
>> by the time we are done with handling these things, they might go
>> away.
>
> Sorry - I'm using extensions and I'm not about to drop support for
> extensions.
yeah but that doesn't mean avalon as a whole is required to support
extensions. Remember that this is alpha code which has not been subject
to a release vote, so you should not assume consensus (just the lazy
variant). Given the massive amount of discussions surrounding this
stuff, I think it is safe to assume there isn't consensus.
If extensions are voted down, avalon is going to drop support for them.
That would mean you would have to do your support for them elsewhere.
>> I understand your position, but in order to get a release RSN I
>> suggest going with the least radical path towards adoption.
>
> I'm tempted to say that this strategy will backfire.
why?
> Even we are
> releasing the lifecycle package or not. If we release it we should do
> it properly.
why is releasing it as an independent package "improper"?
> Currently the avalon CVS contains the framework. This does not mean
> that framework is the only project at this level. We have already
> discussed the need to start work on the seperation of framework imp and
> interfaces which means we will rapidly being seeing the emergence of at
> least two projects in framework. The lifecycle extension simply belong
> at this level. I am not suggesting that the extension interfaces be
> included in framework - only that that the extension package belongs in
> the avalon cvs - not excalibur.
I suggest we deal with cvs (re)structuring after "Excalibur phase III"
and phoenix 4.1 have been released, at least. Right now more moving of
packages will just cause further delays. We need to get to "release
early release often".
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-excalibur/lifecycle/src
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>
> bloritsch@apache.org wrote:
>
>> bloritsch 2003/03/11 05:29:30
>>
>> avalon-excalibur/lifecycle/src - New directory
>>
>>
>
> Berin:
>
> This should be under the avalon CVS, not excalibur. It not a utility -
> it's a couple of interfaces that define extensions to the framework
> contract.
:/ I don't think you are going to get consensus on that. Esp. since
by the time we are done with handling these things, they might go
away. Peter's interceptor ideas have merit, and with the advent of
utilities like CGLib, it makes it really easy to use interceptors.
I understand your position, but in order to get a release RSN I
suggest going with the least radical path towards adoption.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
avalon-excalibur/lifecycle/src
Posted by Stephen McConnell <mc...@apache.org>.
bloritsch@apache.org wrote:
>bloritsch 2003/03/11 05:29:30
>
> avalon-excalibur/lifecycle/src - New directory
>
>
Berin:
This should be under the avalon CVS, not excalibur. It not a utility -
it's a couple of interfaces that define extensions to the framework
contract.
Cheers, Steve.
--
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