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
:D
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:
CLARIFICATION:
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 . exit 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
/home/cvs/avalon
README.txt
LICENSE.txt
framework/
lifecycle/
meta/
interceptor/
fortress/
...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, IIRC.
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.
cheers,
- Leo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
