You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2002/06/20 20:37:30 UTC
RE: Fake parade--NOT!
> From: Stephen McConnell [mailto:mcconnell@osm.net]
>
> Freedom is not being removed. Let get that strait. Assume
> for the purpose of this discourse that a framework is
> released without "remove".
My point being that such an operation should not be taken
without providing an alternative solution that is
1) better
2) easier to use
> It is
> simply
> the ratraction of an abstact operation that cannot be
> supported at the framework's level. Nothing more - nothing
> less. I'm not promoting or
> opposing
> that position here - what I am doing is directly challenging
> the the assumptions you are implying about A4 and its
> evolution. In reality, this email is a fake parade that
> argues for the value of something we don't have.
I don't get the fake parade thing at all.
Stephen, the removal of ComponentSelector and the need for
a lookup(name, hint) is possible with the addition of the
meta info. The meta info resolution is an entriguing idea.
I want to go forward with that idea. However, I want to keep
an eye on complexity--both on the container's side and on the
component/client's side.
Any move that would require more work for the client is a
*bad* move. Hense the XXXXManager solution proposed a while
back would be a *bad* move.
Do not remove a feature without providing a solid replacement.
That will help the discussions from getting stuck on "sacred
cows" which has repeatedly happening.
Too much PFM, and people get nervous (does it really do it
*every* time?). BTW, PFM = Pure F***ing Magic. Not enough
and people get aggitated (you mean I have to do this again
and again?).
We have to strike the balance.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Make your stand now - Is Avalon for more than ReUse ?
Posted by Peter Donald <pe...@apache.org>.
At 02:46 PM 6/20/2002 -0500, you wrote:
>Submitted this question within <flamebait/> earlier, but it got ignored.
>It needs to be answered.
>
>Is Avalon for ANY other purpose than *Component Re-Use* or not? That is
>certainly my only interest. It is arguably what attracts most people to
>it? True or false?
My main draw card for me is that it gives me a ready-made template for
application. However the template does not enforce any domain specific
constraints or structure. Thus I can rapidly prototype applications and
know I will be able to evolve them in the future with relative ease. So
what I like is the quick initial implementation and the ability to scale up
with minimal pain.
Reuse would be fantastic. There are large chunks of cocoon I would love to
reuse in myrmidon but I can't as they are littered with Cocoon specific
assumptions.
The main motivation for containerKit/metainfo stuff is that I will be able
to cleanly reuse these things without effecting cocoons current usage.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Make your stand now - Is Avalon for more than ReUse ?
Posted by Stephen McConnell <mc...@osm.net>.
Pete Carapetyan wrote:
> Submitted this question within <flamebait/> earlier, but it got
> ignored. It needs to be answered.
>
> Is Avalon for ANY other purpose than *Component Re-Use* or not? That
> is certainly my only interest. It is arguably what attracts most
> people to it? True or false?
Form the point of view of the internal architecture of our (OSM)
devleopment, Avalon component *resuse* is not an absolute factor. There
are many situations where I am dealing with families of components
within which I'm introducing behaviours that our outside of classic
resuable components. There are other cases - components intended to be
*reused* as standalone services - but my usage of the work standalone is
in the context of a formal component model - one in which "standalone*
allows me to formally declare dependecies - formally declare services -
in effect to formally declare how my component will successfull work
with other formally declared components.
I do want reusable component from Avalon and I think this is
fundimentally important. I also believe that the framework can provide
much more than this - but if I had to back one single objective it would
be reuse.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Make your stand now - Is Avalon for more than ReUse ?
Posted by Michael Stanley <ms...@mitre.org>.
My quick 2 cents ->
I've followed the Avalon project (quitely) for some time. I've
experienced its use with projects like James and Cocoon, both of which
I'm very familiar with. I recently read all there is to read about
Avalon (as I plan to use it on my new work project), including the
source. Let me say first off that I'm very impressed with the project,
its goals, and its overall design.
To me Avalon is much more that Component Re-Use. Avalon is a prime
example of good software engineer and good OO practice. It is a great
patterns reference, and model for all component oriented programming.
Component Re-use is just an added benefit.
<Mike/>
Pete Carapetyan wrote:
> Submitted this question within <flamebait/> earlier, but it got ignored.
> It needs to be answered.
>
> Is Avalon for ANY other purpose than *Component Re-Use* or not? That is
> certainly my only interest. It is arguably what attracts most people to
> it? True or false?
>
> If it is, then Berin's excellent viewpoints on simplicity and ease of
> use may still be valid, and it seems much more likely that an easy to
> learn, easy to code version of Avalon is still quite possible, or at
> least that a ratched complexity model of behaviour is attainable.
>
> If not, then what other purposes does Avalon serve? For example, if a
> component was NOT going to be re-used on another project, is there any
> reason whatsoever to Avalon it or should it just be instantiated as any
> other OO object ? Is Avalon then becoming complex and difficult to learn
> and use because of the inherently complex objectives, or is because it's
> objectives aren't clear, so a shotgun approach is required to make sure
> that every avenue is accounted for? What a nightmare.
>
> Without a very clear objective, solving it keeps appearing to be
> possible, but then evaporates as the details are discussed, not because
> of the details themselves, but because the participants are trying to
> solve different problems. It's a pot of gold at the end of a rainbow -
> closer you get..... Hence Stefano's commentary on Cocoon using Avalon
> where it shouldn't be used in the first place.
>
> Mark Shepard, a suit from TI was credited with the saying that "More
> than two objectives is no objectives at all".
>
> If you don't know where you are going, any road will get you there.
> Someone else said that.
>
> *Component Re-Use*. Is that the only objective or not? True or False.
> Make your stand now, and then stick to it.
>
> Not fair to cite SoC or IoC or Separation of Interface and
> Implementation. They still make sense, but only because the objective is
> assumed as common sense.
>
>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
<Mike/>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Make your stand now - Is Avalon for more than ReUse ?
Posted by Peter Donald <pe...@apache.org>.
At 10:29 PM 6/22/2002 -0400, you wrote:
> > Anyone can make something awkward and complex. It is true art to make it
> > simple again. (don't look at me, I'm no artist either.).
>
>To draw inspiration from the French writer Antoine de Saint-Exupery:
>
> La perfection est atteinte non quand il ne reste rien a ajouter,
> mais quand il ne reste rien a enlever.
>
> Perfection is achieved, not when there is nothing more to add,
> but when there is nothing left to take away.
I like. I do believe I just aquired a new email sig ;)
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Make your stand now - Is Avalon for more than ReUse ?
Posted by Berin Loritsch <bl...@apache.org>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> The core framework Avalon promotes and facilitates is
> appropriate wherever you write java software. It would also
> be appropriate in C#,
> C++ (if it were feasible, which it is probably not).
It is feasible, but it is also more difficult. You have to worry
about shared library support, name mangling, etc. The way out
of the Interface issue is to use pure virtual classes. There are
other sticking points, but they are resolvable.
One thing that C++ has going for it is algorithmic programming
(templates/generics), which Java does not do well at all.
However, that is neither here nor there. You do need a modern
C++ compiler with proper support for Exceptions and RunTime Type
Identification (RTTI).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Make your stand now - Is Avalon for more than ReUse ?
Posted by Leo Simons <le...@apache.org>.
On Fri, 2002-06-21 at 00:08, Pete Carapetyan wrote:
> >>What are the objectives, if they are more than re-use? Can you identify
> >>them?
> >>
> >>
> >
> >stuff like:
> >
> >- clean code
> >- common program flow in code
> >- instant well-designed architecture
> >- speed
> >
> True, but hardly unique to the goals of Avalon. These are goals of any
> good software. Non COP coders claim these objectives as well, and the
> 2nd and 3rd are also attributes of Re-Use as well as mutually exclusive
> objectives.
the difference: we accomplish them better ;)
> Berin is on the money. The use cases are the key. What are the use cases
> for Avalon? What are use cases where Avalon is not appropriate? What is
> the common thread for each.
The core framework Avalon promotes and facilitates is appropriate
wherever you write java software. It would also be appropriate in C#,
C++ (if it were feasible, which it is probably not).
AspectJ has gone down the route of providing an extension to the core
java language. Avalon could have been implemented that way as well;
which we haven't done for obvious reasons.
use cases for avalon framework: any software
use cases for avalon excalibur: any server-like software
use cases for avalon phoenix: server software, server software
frameworks
use cases for avalon fortress: server software
Hence the extreme difficulty in coming up with the framework interfaces
and contracts. All use cases are valid, the only thing that can be bad
is how to satisfy the use cases.
Only when you talk about more specific bits than you are hinting at (for
example, valid use cases for the Composable interface), can a little
more concrete discussion take place.
regards,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Make your stand now - Is Avalon for more than ReUse ?
Posted by "Gonzalo A. Diethelm" <go...@vtr.net>.
> Anyone can make something awkward and complex. It is true art to make it
> simple again. (don't look at me, I'm no artist either.).
To draw inspiration from the French writer Antoine de Saint-Exupery:
La perfection est atteinte non quand il ne reste rien a ajouter,
mais quand il ne reste rien a enlever.
Perfection is achieved, not when there is nothing more to add,
but when there is nothing left to take away.
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Make your stand now - Is Avalon for more than ReUse ?
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
Leo Simons wrote:
>>What are the objectives, if they are more than re-use? Can you identify
>>them?
>>
>>
>
>stuff like:
>
>- clean code
>- common program flow in code
>- instant well-designed architecture
>- speed
>
True, but hardly unique to the goals of Avalon. These are goals of any
good software. Non COP coders claim these objectives as well, and the
2nd and 3rd are also attributes of Re-Use as well as mutually exclusive
objectives.
><snip/>
>
>What you ask thus is "what are the objects of software architecture
>design?" and "what are the benefits of component libraries?" The answers
>are all over the place; many apply to avalon.
>
I guess I keep trying to differentiate between atttributes of good
design, and specific objectives that differentiate the Avalon Framework
from OO design. Most of these things, including all the patterns in use
throughout the industry are all fantastic patterns and Avalon should
have them too, as great attributes. But they are not the primary unique
objective, as can be observed by viewing the defined by use cases, and
by the fact that they apply equally to straight OO as to Avalon, which
is anything but straight OO.
Berin is on the money. The use cases are the key. What are the use cases
for Avalon? What are use cases where Avalon is not appropriate? What is
the common thread for each.
If Peter Donald says that xxx is a stupid thing, and Stefano says yeah,
that was pretty stupid, I agree, and he was the only one using xxxx,
then it is a bad use case and attempting to accomodate it into the
pattern at the expense of making the entire framework un-necessarily
complex is pretty stupid. At least from that viewpoint. So you dumb it
back down and quit trying to do something that is not the primary
objective anyway. Seems something that Spock would +1 for.
Simplification is not just a silly excercise, because what Berin has
vocalized very well is the possibility for clean, well articulated
design that can be adopted by less than geniuses. It may piss the
geniuses off, they may want to be the only ones who understand it, but
that's not the goal. What has been said here about "pretty soon it
becomes another whole language unto itself" is true. The geniuses may
not want to let their baby out of the lab. So be it. The goal is to get
it down to the essence. Then add each complexity only as needed, and in
direct relation to each value gained. Surely that is a doable deal.
Doesn't mean there would be plenty of chances for fun arguments and lots
of brandishing of very fancy swordsmanship. It is a belief that the
framework can be reduced to it's essence first, and made understandable
and syntactically secure, and then the swordsmanship can happen at the
edges where it doesn't keep the core of A5 from the 99% of programmers
who would love to share components if it were reduced to it's essence
first, but won't because it isn't yet.
Anyone can make something awkward and complex. It is true art to make it
simple again. (don't look at me, I'm no artist either.).
I've said it before. I'll say it again. Current Avalon developers have
much much more of a cool thing here than they appear to grok. If you can
make the move that Berin has hinted at, it could be a lot of fun for
more than just you, and not at your expense either. But someone has to
want it. I guess that would have to include me, because I would like to
see this thing settle down into that very place. It can be done.
Re: Make your stand now - Is Avalon for more than ReUse ?
Posted by Leo Simons <le...@apache.org>.
> What are the objectives, if they are more than re-use? Can you identify
> them?
stuff like:
- clean code
- common program flow in code
- instant well-designed architecture
- speed
etc etc. I doesn't matter that much to me whether you reuse stuff I
write at all. I care about well-designed software. Reuse is an added
benefit.
The benefits of using avalon are partially the same as those of reuse,
RAD, etc. Partially, they are the same as those of Design Patterns.
Basically, avalon is about (a common) java server software architecture
(like all frameworks are about defining a common architecture) on the
one hand, and about providing specific parts of that server architecture
on the other hand (like all component libraries).
What you ask thus is "what are the objects of software architecture
design?" and "what are the benefits of component libraries?" The answers
are all over the place; many apply to avalon.
- Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Make your stand now - Is Avalon for more than ReUse ?
Posted by Stephen McConnell <mc...@osm.net>.
Nicola Ken Barozzi wrote:
>
>
> Pete Carapetyan wrote:
>
>> Leo Simons wrote:
>>
>>>> Not fair to cite SoC or IoC or Separation of Interface and
>>>> Implementation. They still make sense, but only because the
>>>> objective is assumed as common sense.
>>>>
>>>
>>>
>>>
>>> that's your stance on it.
>>>
>>>
>> Not much of a stance, as stance implies that I believe in what I am
>> saying. More like a tentative viewpoint looking for opposing
>> clarifications.
>>
>> I must an attempt to separate what from how. I get lost in the how,
>> fried my brain in a previous life. So now I have to be very careful
>> to separate what from how, otherwise I get stuck in how and lose
>> track of what. Happens to others also, I've noticed.
>>
>> Berin is right on. He keeps trying to bring it back to the use cases.
>> They all seem like re-use to me. But my handicap has already been
>> identified, maybe brighter folks can point out other objectives than
>> I am seeing.
>>
>> What are the objectives, if they are more than re-use? Can you
>> identify them?
>
>
> Avalon is an API that, correctly implemented and used, makes better,
> cleaner, easier and more manageable software.
>
> -Better: it enforces good programming practices: IOC, SOC, etc---
> -Cleaner: COP
> -Easier: intuitive and clean APIS
> -Manageable: Component-Container
>
> It has reference implementation of components that help implement it
> (Excalibur), and a reference implementation of a server (since we're
> at Apache, let's not forget it ;-)
>
> I started using Avalon API in an app of mine that din't use it at
> first, and in 2 days I found myself, without understanding really why,
> with a really cool system. The API really enforced good practices!
>
> The power of Avalon is in the API.
> That's why we fight (we are knights) over the API, rarely over the
> implementations.
>
+1
You can post this!
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Make your stand now - Is Avalon for more than ReUse ?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Pete Carapetyan wrote:
> Leo Simons wrote:
>
>>> Not fair to cite SoC or IoC or Separation of Interface and
>>> Implementation. They still make sense, but only because the objective
>>> is assumed as common sense.
>>>
>>
>>
>> that's your stance on it.
>>
>>
> Not much of a stance, as stance implies that I believe in what I am
> saying. More like a tentative viewpoint looking for opposing
> clarifications.
>
> I must an attempt to separate what from how. I get lost in the how,
> fried my brain in a previous life. So now I have to be very careful to
> separate what from how, otherwise I get stuck in how and lose track of
> what. Happens to others also, I've noticed.
>
> Berin is right on. He keeps trying to bring it back to the use cases.
> They all seem like re-use to me. But my handicap has already been
> identified, maybe brighter folks can point out other objectives than I
> am seeing.
>
> What are the objectives, if they are more than re-use? Can you identify
> them?
Avalon is an API that, correctly implemented and used, makes better,
cleaner, easier and more manageable software.
-Better: it enforces good programming practices: IOC, SOC, etc---
-Cleaner: COP
-Easier: intuitive and clean APIS
-Manageable: Component-Container
It has reference implementation of components that help implement it
(Excalibur), and a reference implementation of a server (since we're at
Apache, let's not forget it ;-)
I started using Avalon API in an app of mine that din't use it at first,
and in 2 days I found myself, without understanding really why, with a
really cool system. The API really enforced good practices!
The power of Avalon is in the API.
That's why we fight (we are knights) over the API, rarely over the
implementations.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Make your stand now - Is Avalon for more than ReUse ?
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
Leo Simons wrote:
>>Not fair to cite SoC or IoC or Separation of Interface and
>>Implementation. They still make sense, but only because the objective is
>>assumed as common sense.
>>
>>
>
>that's your stance on it.
>
>
Not much of a stance, as stance implies that I believe in what I am
saying. More like a tentative viewpoint looking for opposing
clarifications.
I must an attempt to separate what from how. I get lost in the how,
fried my brain in a previous life. So now I have to be very careful to
separate what from how, otherwise I get stuck in how and lose track of
what. Happens to others also, I've noticed.
Berin is right on. He keeps trying to bring it back to the use cases.
They all seem like re-use to me. But my handicap has already been
identified, maybe brighter folks can point out other objectives than I
am seeing.
What are the objectives, if they are more than re-use? Can you identify
them?
Re: Make your stand now - Is Avalon for more than ReUse ?
Posted by Leo Simons <ls...@multimia.com>.
> Is Avalon for ANY other purpose than *Component Re-Use* or not?
yes!
Avalon Framework: facilitate COP by promoting some very good patterns
and meta patterns
Avalon Excalibur: provide reusable components
Avalon Phoenix: run reusable components and services, decorate them with
extra security, facilitate multiple applications running in a the same
VM, IOW: general server kernel
etc etc. All this is in the docs.
> *Component Re-Use*. Is that the only objective or not? True or False.
> Make your stand now, and then stick to it.
False. See docs, see charter.
> Not fair to cite SoC or IoC or Separation of Interface and
> Implementation. They still make sense, but only because the objective is
> assumed as common sense.
that's your stance on it.
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Make your stand now - Is Avalon for more than ReUse ?
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Pete Carapetyan [mailto:pete@datafundamentals.com]
>
> Is Avalon for ANY other purpose than *Component Re-Use* or
> not?
Yes.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Make your stand now - Is Avalon for more than ReUse ?
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
Submitted this question within <flamebait/> earlier, but it got ignored.
It needs to be answered.
Is Avalon for ANY other purpose than *Component Re-Use* or not? That is
certainly my only interest. It is arguably what attracts most people to
it? True or false?
If it is, then Berin's excellent viewpoints on simplicity and ease of
use may still be valid, and it seems much more likely that an easy to
learn, easy to code version of Avalon is still quite possible, or at
least that a ratched complexity model of behaviour is attainable.
If not, then what other purposes does Avalon serve? For example, if a
component was NOT going to be re-used on another project, is there any
reason whatsoever to Avalon it or should it just be instantiated as any
other OO object ? Is Avalon then becoming complex and difficult to learn
and use because of the inherently complex objectives, or is because it's
objectives aren't clear, so a shotgun approach is required to make sure
that every avenue is accounted for? What a nightmare.
Without a very clear objective, solving it keeps appearing to be
possible, but then evaporates as the details are discussed, not because
of the details themselves, but because the participants are trying to
solve different problems. It's a pot of gold at the end of a rainbow -
closer you get..... Hence Stefano's commentary on Cocoon using Avalon
where it shouldn't be used in the first place.
Mark Shepard, a suit from TI was credited with the saying that "More
than two objectives is no objectives at all".
If you don't know where you are going, any road will get you there.
Someone else said that.
*Component Re-Use*. Is that the only objective or not? True or False.
Make your stand now, and then stick to it.
Not fair to cite SoC or IoC or Separation of Interface and
Implementation. They still make sense, but only because the objective is
assumed as common sense.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Fake parade--NOT!
Posted by Berin Loritsch <bl...@apache.org>.
> From: Stephen McConnell [mailto:mcconnell@osm.net]
>
> This is the framework reference implementation of release.
> Yes - it is
> easy to understand, yes - its easy to use. Could we come up with
> something that is better? Yes - remove it and delivery
> something better
> in the right level of abstraction. But the big point is that
> your email
> is making assertions that are only rational if your understanding of
> Avalon Framework is Avalon Framework + ECM conventions and
> implementation.
+ Fortress.
The ECM is used by a great many of our users. There is a smooth
(or relatively smooth) migration from ECM to Fortress. There are
also benefits that Fortress provides which ECM doen't such as
higher scalability due to offloading management functions into
asynchronous functions.
However, I haven't *removed* existing functionality.
If we ignore our existing users we will piss them off royally.
We need to think of them.
Another important thing is that assumptions held by a large number
of people (which include many of our users) in themselves become
contracts. To ignore that fact because we didn't explicitly
state the contract is really bad.
I have been working at the possibility of removing pooled support
for a while now. There are simply some ways that the ECM/Fortress
is used that doesn't permit that yet.
We are getting closer, but you can't remove expected functionality
without providing a better substitute--which is what we are doing
if we remove the release() method at this time.
The fact is, ECM, Fortress, Merlin, and Phoenix all implement the
contracts as they are laid out for containers at this moment.
However, they are only *partially* compatible. We need you and
Peter to finish the meta-data so that they can be even more
compatible. Fortress will follow suite, and ECM will die.
There are things that I need to explore with Fortress that may
provide a better solution to explicit pooling, making it impossibly
easy to create threadsafe components. Until they exist, the
release() method needs to stay. Which is why I am suggesting
to temporarily table A5.
> >> It is
> >>simply
> >>the ratraction of an abstact operation that cannot be
> >>supported at the framework's level. Nothing more - nothing
> >>less. I'm not promoting or
> >>opposing
> >>that position here - what I am doing is directly challenging
> >>the the assumptions you are implying about A4 and its
> >>evolution. In reality, this email is a fake parade that
> >>argues for the value of something we don't have.
> >>
> >
> >I don't get the fake parade thing at all.
> >
>
> Too much implied in beteen the lines. Positioning the containerkit as
> overly complex - why - have you used it - have your tried to develop
> something with it? I have - it is simple to use - took no
> more that a
> couple of days to get something operation in place. Containerkit is
> simple - what's not simple is what containerkit implies. But
> the iussue
> here is that containkit is implying the defintion of what a component
> really is - and that is much more of a concrete issue. My
> fake-parade
> comment is specifically addressing the issue of "lets ignore whats
> really happenning" - "lets imagine that what we have is
> perfect" - what
> we have today is really great - but when we are discussing
> evolution and
> forward looking development - we cannot - must not - ignore our
> functional limitations (e.g. the amazingly complex release
> operation imp
> described above - or the responsibilities we have when
> defining what a
> component really is).
Restating my *intended* message:
Let's not hide a complex problem with software if there is a simpler
approach.
I assert that J2EE's ServiceManager concept is flawed because it is
an additional layer overtop a monster that Sun has created. Instead
of fixing the underlying problems associated with resolving EJBs and
other J2EE components, they add another software layer overtop. Even
more specious is the fact that they expect every company to develop
the same fundamental solution themselves instead of providing the
abstraction.
Let's simplify as much as possible, and then use the software to make
it dirt easy.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Fake parade--NOT!
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@osm.net]
> Berin Loritsch wrote:
>
> Ok, lets take the DefaultComponentManager.release() operation - the
> implementation currently is the following:
>
> public void release( final Component component )
> {
> }
>
> This is the framework reference implementation of release.
> Yes - it is
> easy to understand, yes - its easy to use.
(Just noticed: It is dead wrong as well. The dispose() method is
not called for SingleThreaded components.)
> Could we come up with something that is better?
> Yes - remove it and delivery something better in
> the right level of abstraction.
Well, what would that be?
If you claim to want a grounded debate, then for the love of God,
can you come up with something better that *is* at the right level
of abstraction and at the same time *is* easy for our users?
All proposals so far to that effect have either been:
1) not workable
2) pushing way too much responsibility on to
the component writer
3) too complex to be understood
You can argue that "easy" means "just like ECM" and you'd be
partially right. But whether your reference point is ECM or not,
ECM has some very good features that many people have found useful
and that would be removed if release() is removed.
You can argue for removal of those features from the framework,
but then I'd like you to give me a replacement for those features.
I'm with Berin on this one.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Fake parade--NOT!
Posted by Stephen McConnell <mc...@osm.net>.
Berin Loritsch wrote:
>>From: Stephen McConnell [mailto:mcconnell@osm.net]
>>
>>Freedom is not being removed. Let get that strait. Assume
>>for the purpose of this discourse that a framework is
>>released without "remove".
>>
>
>My point being that such an operation should not be taken
>without providing an alternative solution that is
>
>1) better
>2) easier to use
>
Ok, lets take the DefaultComponentManager.release() operation - the
implementation currently is the following:
public void release( final Component component )
{
}
This is the framework reference implementation of release. Yes - it is
easy to understand, yes - its easy to use. Could we come up with
something that is better? Yes - remove it and delivery something better
in the right level of abstraction. But the big point is that your email
is making assertions that are only rational if your understanding of
Avalon Framework is Avalon Framework + ECM conventions and implementation.
>
>> It is
>>simply
>>the ratraction of an abstact operation that cannot be
>>supported at the framework's level. Nothing more - nothing
>>less. I'm not promoting or
>>opposing
>>that position here - what I am doing is directly challenging
>>the the assumptions you are implying about A4 and its
>>evolution. In reality, this email is a fake parade that
>>argues for the value of something we don't have.
>>
>
>I don't get the fake parade thing at all.
>
Too much implied in beteen the lines. Positioning the containerkit as
overly complex - why - have you used it - have your tried to develop
something with it? I have - it is simple to use - took no more that a
couple of days to get something operation in place. Containerkit is
simple - what's not simple is what containerkit implies. But the iussue
here is that containkit is implying the defintion of what a component
really is - and that is much more of a concrete issue. My fake-parade
comment is specifically addressing the issue of "lets ignore whats
really happenning" - "lets imagine that what we have is perfect" - what
we have today is really great - but when we are discussing evolution and
forward looking development - we cannot - must not - ignore our
functional limitations (e.g. the amazingly complex release operation imp
described above - or the responsibilities we have when defining what a
component really is).
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>