avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: [ANTI-VOTE] Lifecycle Extension Tags
Date Mon, 28 Jul 2003 18:40:56 GMT
Stephen McConnell wrote:

Social stuff
------------
> The social implications is:
> 
>   * "it's not I the avalon namespace I don't have to worry about it"

you cannot battle negative social implications with code or 
specifications. That's plain dumb.

Here's the important social implication: the fact that you think it 
appropriate to state "I will ignore this group decision made by the 
accepted decision-making process we have put in place as a group because 
I may disagree with the result" over something as silly as a naming 
convention, dragging us all back into long e-mails full of debate about 
bike sheds has hereby led to the end of my involvement in talks about 
and work on implementing a common avalon metadata system. This is not 
how I want to develop stuff.

Have fun writing it on your own.

Contractual stuff
-----------------
> This is complicated by a contractual limitations:
> 
>  * "the avalon namespace model does not support model extension"

avalon does not need a formal namespace model with extension capability. 
Look at how much trouble the XDoclet people have managing their dozens 
of tags (namely: none). We're certainly not likely to have more than them.

Sigh.

You know how much work it is to replace @lifecycle with 
@avalon.lifecycle? It goes a little something like

s/@lifecycle/@avalon\.lifecycle/

in perl. Which is something just about every reasonable editor on this 
planet can do with a few keystrokes or a few mouseclicks. In fact, I can 
do that ASF-wide to all sourcecode in less time than it takes you to 
reply to this e-mail.

Some pointless bickering
------------------------
just for fun, I'll point out some things that are plain wrong:

> if something is not inside Avalon namespace - well - it just does not exist 
> in terms of something standard and recognized.

wrong. java.lang for example is standard and recognized. So is log4j. 
Standards don't need a namespace.

> The @avalon.stage tag does not dictate a mechanisms to a container

the way you're putting it it does: you are stating that all containers 
must have a mechanism in place to parse some kind of data about 
lifecycle extensions and then kick out a component.

> If we retract the @avalon.stage (and the corresponding 
> @avalon.extension) tags from the Avalon namespace, we are stating that 
> the notions of deployment phase (versus classic runtime phase) notions 
> are concepts that can be ignored.

wrong. We are seperating concerns.

> If you remove 
> @avalon.stage from core Avalon - then any component that leverages 
> deployment phase dependencies (i.e. components that fulfill stage 
> execution) will no longer be a valid Avalon components.

wrong. "valid avalon component" is defined by providing a no argument 
constructor, a work interface and following IoC. That won't change.

> The implication 
> of this is that a container could be asked to deploy such a component, 
> and unless the component does its own error checking to validate that in 
> fact its lifecycle stages have been executed, we enter the gray zone of 
> unpredictable components.  This gray zone is components executing on the 
> assumption that they have been fully deployed.  This potential false 
> assumption can lead to failures in security, inconsistency in service 
> delivery behavior, and potential damage by a component simply because it 
> is acting under incorrect assumptions.

indeed. Someone who deploys an application into a container and uses 
advanced features better check they're supported. Just like you should 
deploy a component that uses javax.logging on jdk 1.3.

> Containers outside (and quite probably inside) Avalon will 
> ignore @lifecycle because its not part of a "core" @avalon contract.  

containers inside and outside avalon ignore some parts of 
avalon-framework that have been in place since version 4.0. I would 
argue that ComponentSelector is at the very core of the core of avalon.

> One cannot 
> simply retract this tag from the Avalon namespace without providing a 
> solution.

wrong. No application I have ever written will suffer. No application 
deployed on released avalon code will suffer. No application to deployed 
on to-be-released avalon code will suffer more than a search-and-replace 
incovenience.

> * moving out of core means death to the idea of reliable deployment 
> across containers

FUD.

> * an absence of an extension mechanism in @avalon core makes the 
> proposal technically invalid

wrong.

> Now is not the time for another divergent split in Avalon

very right. Maybe you should dim your tone in order to avoid such 
divergence.

> containers that recognize the full criteria and containers that claim 
> Avalon compliance but ignore the reality of what developers are doing 
> using release Avalon product).

FUD.

g'night!

- Leo



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


Mime
View raw message