avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: [PROPOSAL] lifecycle release
Date Wed, 12 Mar 2003 15:13:42 GMT
Peter Donald wrote:
>> we have discussed moving materials which do not belong at the same
>> level as avalon-framework into the avalon CVS module before.
> And yet it hasn't happened.

twist those words around a bit:

and it hasn't happened yet


>> Can you motivate why you think that is not a good idea?
> Because it is not common to all containers or development strategies.

So you are saying that materials that go into the avalon CVS module 
should be common to all containers and development strategies. Why?

Berin wrote:
> No one has proposed making them part of FRAMEWORK.  It is a question
> of which repository to move to.
> It is a question of whether we want to make the "avalon" CVS
> repository support a framework directory structure and an extension
> directory structure.

to make that even more clear (well maybe), the idea is something like

ssh cvs.apache.org
umask 002
cd /home/cvs/avalon
cp -Rfp * framework
cp -Rfp ../avalon-sandbox/lifecycle .
cd ~/cvs/avalon
cvs rm -Rf *
cvs commit -m 'moving into framework/ subdirectory'
cvs up -P -d

this was talked about before; the idea back then was to move everything
that is not generic utility code (ie meta, containerkit, similar stuff,
but not IO or CLI) into the main avalon cvs (when ready to move out of 
the sandbox). You would end up with


Clearly, neither a meta model nor lifecycle extensions nor interceptors 
nor fortress would be common across containers (anytime soon). Its just 
about organisation.

> The Marker interfaces will probably be deprecated post fortress
> release. The *Selector interfaces can also be considered for
> deprecation. In the future I can see the release() methods also being
> deprecated.

that's quite another (ancient ;) discussion.

>>>> * the release of the avalon-lifecycle package shall be 
>>>> considered as an "optional" extension to the framework 
>>>> contracts
>>> -1
>>> It is the same approach that has been done before and failed and
>>> can't cleanly produce some aspects like delayed activation,
>>> passivation, persistence, transaction demarcation, bifuricating
>>> interception etc.
>> Taking your -1 as a veto rather than an opinion, you should provide
>> a viable alternative for it to be valid, which AFAIK you haven't
>> done.
> Several times before - you even committed one of my emails to CVS.
> Interceptors will solve all these problems (and many more besides).
> Go to Rickard Öbergs blog for a good description. Alternatively go
> through the links I have provided in the past. Several good articles
> are available in msdn these days aswell.

Your -1 applies to "the release of the avalon-lifecycle package shall be 
considered as an "optional" extension to the framework contracts", 
doesn't it? Saying "avalon-lifecycle (c/sh)ould be implemented 
differently using interceptors" is a different story alltogether, innit?

I am all for finding the best implementation. In the meantime, fortress 
doesn't have an interceptor-based architecture, it sounds like a lot of 
work to put it in now, and I think it needs a release.

>> Also, could you please provide more specific information about why
>> the approach in the lifecycle package fails, perhaps with a code
>> example?
> Perhaps you could show me how it succeeds.

sure. Fortress provides support for instrumentation management by using 
the lifecycle and instrument-manager packages. This is, atm, my usecase 
for the lifecycle package, and it succeeds there.

> We have tried it in the
> past and it led to spagetti code.

you think the way fortress does instrumentation is "spaghetti-like"? I 
sorta like it. Its the only time I've tried using lifecycle extensions, 

>> I would also like to point out that IMHO you're "throwing a veto"
>> rather lightly. I think it makes the discussion more productive if
>> you take some more effort to back a -1 before issueing it.
> Get over. I have spent hours upon hours explaining this and wrote up
> several long emails and documents explaining this in the past. I have
> given oodles and oodles of links to both java and dot.net based
> approaches. What is it you find lacking in my previous explanations?

- you didn't mention them when vetoeing;
- it apperas like you haven't bothered to fully digest what the proposal 
was about (see above), and what context it was issued in;

- You've pointed to lots of alternative approaches which look pretty 
promising, but I can remember nor find in the archives any example as to 
why the lifecycle package is so bad it should be dismissed as a "hack". 
Just the fact that something could be implemented differently and is in 
other architectures is not a good enough reason to do it IMO, if the 
other way happens to make sense and accomplish its goals. In fact, I 
have code working just fine in front of my face (fortress) which uses it.

Pete, I think this is not something where we should just say "get over 
it". When we had all the flame fests in august/september, that started 
with some "lightly thrown" vetoes, too.


- Leo

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

View raw message