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/11/22 05:07:37 UTC
Tiered Container Hierarchy
I would like to propose set of tiered containers and the appropriate
compliance
test suites. The approach requires all of us to work together (building
community
as Stefano wants), and satisfies the real need for more than one
container in
Avalon. It would work something like this:
1) Micro Container--a Tweety like container that can operate in J2ME.
It requires
that only threadsafe components be used because it is unlikely that
multithreading
will be used in that environment. It is severly limited, and
identifies the minimum
requirements for Avalon compliance.
2) Standard Container--the result of merging Merlin and Fortress. It
will be able to
support embedding in a larger container (like J2EE) as well as the
more robust
component handling (pooling, thread-local, etc.).
3) Server Container--Phoenix. It identifies the requirements for a root
level container
that hosts server applications. It will not be embeddable because it
is the kernel.
I think that this approach will satisfy the community needs as well as
the needs for
different types of containers. It is also important to focus on
container/component
contracts in each of these--all the while providing a reasonable default
implementation.
---------------------------------------------
Introducing NetZero Long Distance
1st month Free!
Sign up today at: www.netzerolongdistance.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tiered Container Hierarchy
Posted by Peter Donald <pe...@apache.org>.
On Fri, 22 Nov 2002 22:11, Peter Donald wrote:
> I would prefer to wait to see what the XDoclet/qdox/commons teams produce.
> If it does not suit us then we can create our own (I already did most of it
> with MetaClass codebase and another guy Doug has taken up development of
> it).
Thinking about it - it may be best to recreate it ourselves anyway as that
would allow us to abstract the underlying mechanics and also be forward
compatible with jdk1.5
--
Cheers,
Peter Donald
---------------------------------------------------
"Therefore it can be said that victorious warriors
win first, and then go to battle, while defeated
warriors go to battle first, and then seek to win."
- Sun Tzu, the Art Of War
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tiered Container Hierarchy
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Fri, 22 Nov 2002 19:29, Nicola Ken Barozzi wrote:
>
>
>>That's why I started the info-meta merge discussion, and see clazz as a
>>good solution.
>>
>>
>
>Clazz is far from good for our purposes because it also tries to be a
>reflection based mechanism. We need to load things without classes being
>resolvable and so forth.
>
In the clazz package there is the basic framework in the
org.apache.commons.clazz.* package. This package defines the Clazz
class and its structure of clazz level properties and operations. The
org.apache.commons.clazz.reflection.* is one implementation approach and
I agree that this does not meet our requirements. I don't think that
the existence of the .reflection package negates the value of using
meta-meta structures defined in the clazz.* package.
If you put aside the reflection package, and assume instead something
based on the clazz.* package - do you seen anything that is inconsistent
or problematic?
I think it would be interesting to kick of a joint Avalon/clazz
initiative from which we (Avalon) work with the clazz guys to (a)
deliver a open meta model for an Avalon component, (b) contribute to the
development of the clazz package in the process, and (c) ensure that the
result is a complete and succinct definition of the "component" contract.
Cheers, Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tiered Container Hierarchy
Posted by Peter Donald <pe...@apache.org>.
On Fri, 22 Nov 2002 19:29, Nicola Ken Barozzi wrote:
> That's why I started the info-meta merge discussion, and see clazz as a
> good solution.
Clazz is far from good for our purposes because it also tries to be a
reflection based mechanism. We need to load things without classes being
resolvable and so forth. The commons-attribute codebase (or whatever it was)
is a better solution but not perfect (too many dependencies, too hard to use,
etc).
However currently XDoclet is finally starting to go towards XDoclet2. They
look like they are going to integrate with qdox peeps and produce a runtime
attribute retrieval in conjunction with some commons people.
I would prefer to wait to see what the XDoclet/qdox/commons teams produce. If
it does not suit us then we can create our own (I already did most of it with
MetaClass codebase and another guy Doug has taken up development of it).
--
Cheers,
Peter Donald
------------------------------------------------
| We shall not cease from exploration, and the |
| end of all our exploring will be to arrive |
| where we started and know the place for the |
| first time -- T.S. Eliot |
------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tiered Container Hierarchy
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
> Berin Loritsch wrote:
>
>> I would like to propose set of tiered containers and the appropriate
>> compliance
>> test suites. The approach requires all of us to work together
>> (building community
>> as Stefano wants), and satisfies the real need for more than one
>> container in
>> Avalon. It would work something like this:
>>
>> 1) Micro Container--a Tweety like container that can operate in J2ME.
>> It requires
>> that only threadsafe components be used because it is unlikely that
>> multithreading
>> will be used in that environment. It is severly limited, and
>> identifies the minimum
>> requirements for Avalon compliance.
>>
>> 2) Standard Container--the result of merging Merlin and Fortress. It
>> will be able to
>> support embedding in a larger container (like J2EE) as well as the
>> more robust
>> component handling (pooling, thread-local, etc.).
>>
>> 3) Server Container--Phoenix. It identifies the requirements for a
>> root level container
>> that hosts server applications. It will not be embeddable because
>> it is the kernel.
>>
>> I think that this approach will satisfy the community needs as well as
>> the needs for
>> different types of containers. It is also important to focus on
>> container/component
>> contracts in each of these--all the while providing a reasonable
>> default implementation.
>
>
> You would see me happy on this only if each container used the
> underlying one.
>
> That is: Merlin's Fortress is based on Tweety and Phoenix is based on
> Merlin's Fortress (can we come up with a better name for this, please?)
>
> That would solve all my concerns and would force people to work together
> and create a community because they would share not only the syntax and
> the semantics but also the behavior. And would force all containers to
> keep in synch.
Something between these lines had been proposed in the past months and
probably also before. Look in the CVS dirs and there is a microcontainer
somewhere.
Currently the picture is a bit different: we have Excalibur that keeps
common stuff for all these containers, that pick what they prefer.
,---------- Tweety
|
Xcalibur -------------- Merlin
|
|----------- Fortress
|
'---------- Phoenix
In fact IMHO it can be done with what we have now.
Phoenix
|
Owl (Merlin's Fortress)
|
Tweety
There is no need to merge the excalibur packages in each container, but
we could make the featureset be layered and have each container just
enhance from the previous.
That's why I started the info-meta merge discussion, and see clazz as a
good solution. That's also why I would like that Phoenix developers and
Merlin-Fortress ones work closely to create a common metamodel, since
Phoenix, in this view, would inherit from "Owl".
> [note that this reflects the inheritance model of OOP which this very
> community seems to have forgotten since Avalon doesn't make extensive
> use of it]
--
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: Tiered Container Hierarchy
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
On Thu, Nov 21, 2002 at 11:28:12PM -0800, Stefano Mazzocchi wrote:
> >1) Micro Container--a Tweety like container that can operate in J2ME. It..
> >2) Standard Container--the result of merging Merlin and Fortress. It..
> >3) Server Container--Phoenix. It identifies the requirements for a root..
+1, this is what Nicola also proposed a while back.
> You would see me happy on this only if each container used the
> underlying one.
>
> That is: Merlin's Fortress is based on Tweety and Phoenix is based on
> Merlin's Fortress (can we come up with a better name for this, please?)
>
> That would solve all my concerns and would force people to work together
> and create a community because they would share not only the syntax and
> the semantics but also the behavior. And would force all containers to
> keep in synch.
One possible approach at achieving more reuse could be something
what PeterD and I spoke about a few weeks back archived at:
http://marc.theaimsgroup.com/?l=avalon-dev&m=103719498600580&w=2
or some variation of it.
Essentially the idea was to create a common underlying 'container'
model that could be reused inside container implementations.
The thread was more directed at providing backwards compatibility,
but could be applied to increase reuse - albeit more using a
composition approach rather than inheritance.
PeterD had some good comments in the thread though, I still have to
get back to him about them. Anyway, just thought I'd bring it up.
On the topic of having a single container, I'm all for it - I think
what Berin/Stefano describe above could actually be considered a single
container, just layered upon each other to extend the container's
target scope (ie. small -> mid/embedded -> large/server scale).
Just my 2c AUS :)
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tiered Container Hierarchy
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
> On Fri, 22 Nov 2002 20:35, Stefano Mazzocchi wrote:
>
>>Peter Donald wrote:
>>
>>>On Fri, 22 Nov 2002 18:28, Stefano Mazzocchi wrote:
>>>
>>>>[note that this reflects the inheritance model of OOP which this very
>>>>community seems to have forgotten since Avalon doesn't make extensive
>>>>use of it]
>>>
>>>Thats because most of us think OOP sucks. Give me COP or Modular
>>>programming over OOP any day.
>>
>>Interesting. I wonder who entitles you to speak for the rest of the
>>crowd here.
>
>
> errr .. nice. You are here to help right?
yep, that's the plan
> If you look at our code guidelines we specifically recomend against the
> artefacts of OO and recomend delegation where possible. I don't recall much
> discussion on OOP practices but it is quite common to discuss COP.
Great, let's do so.
> Modular is just my approach to things - it is also the same approach used by
> "enterprise" level frameworks ala EJB / DNA (or whatever it is called
> nowadays).
I think that Avalon would gain a lot in using inheritance at a
containment level.
If containers extend one another:
1) it increases interoperability (because they share common code and
behavior)
2) it reduces maintenance costs (if code is extended, bugfixes applied
to an extended container will apply to all containers that extend)
There is also one major difference in what has been done until today
around here:
1) development must be done over consensus between the developers that
work on the different containers
I must state that I consider all three points to be positive for the
Avalon community and for the perceived solidity of Avalon from the outside.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Tiered Container Hierarchy
Posted by "Noel J. Bergman" <no...@devtech.com>.
> If you look at our code guidelines we specifically recomend against the
> artefacts of OO and recomend delegation where possible.
Delegation is an Object Programming pattern. There are all sorts of
patterns used in Object Programming. Saying that you recommend against the
"artefacts[sic] of OO" is not particularly contentful, other than to suggest
that you have a fuzzy prejudice against something you don't fully
understand. Since I believe that you are more talented that the comment
implies, I suggest that IF you deem it necessary to engage in this
discussion, that you be far more specific and clear about what you mean.
Now, if you mean to say that you don't believe that code sharing is
isomorphic with inheritance, then I agree with you. Inheritance is only one
aspect of Object Programming, and a generally poorly applied one at that,
IME. There are other means of code sharing within the Object Programming
paradigm.
Personally, I suggest that the rhetoric (and sarcasm from all sides) be
dropped, and that the focus be placed on what people ARE willing to do
constructively. From what I can see, most people are starting to do just
that: they are expressing what IS important to them, and what they ARE
willing to do, and the community is starting to jell around those common
points.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tiered Container Hierarchy
Posted by Peter Donald <pe...@apache.org>.
On Fri, 22 Nov 2002 20:35, Stefano Mazzocchi wrote:
> Peter Donald wrote:
> > On Fri, 22 Nov 2002 18:28, Stefano Mazzocchi wrote:
> >>[note that this reflects the inheritance model of OOP which this very
> >>community seems to have forgotten since Avalon doesn't make extensive
> >>use of it]
> >
> > Thats because most of us think OOP sucks. Give me COP or Modular
> > programming over OOP any day.
>
> Interesting. I wonder who entitles you to speak for the rest of the
> crowd here.
errr .. nice. You are here to help right?
If you look at our code guidelines we specifically recomend against the
artefacts of OO and recomend delegation where possible. I don't recall much
discussion on OOP practices but it is quite common to discuss COP.
Modular is just my approach to things - it is also the same approach used by
"enterprise" level frameworks ala EJB / DNA (or whatever it is called
nowadays).
--
Cheers,
Peter Donald
----------------------------------------------
Money is how people with no talent keep score.
----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tiered Container Hierarchy
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
> On Fri, 22 Nov 2002 18:28, Stefano Mazzocchi wrote:
>
>>[note that this reflects the inheritance model of OOP which this very
>>community seems to have forgotten since Avalon doesn't make extensive
>>use of it]
>
>
> Thats because most of us think OOP sucks. Give me COP or Modular programming
> over OOP any day.
Interesting. I wonder who entitles you to speak for the rest of the
crowd here.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tiered Container Hierarchy
Posted by Peter Donald <pe...@apache.org>.
On Fri, 22 Nov 2002 18:28, Stefano Mazzocchi wrote:
> [note that this reflects the inheritance model of OOP which this very
> community seems to have forgotten since Avalon doesn't make extensive
> use of it]
Thats because most of us think OOP sucks. Give me COP or Modular programming
over OOP any day.
--
Cheers,
Peter Donald
----------------------------------------
Whatever you do will be insignificant,
but it is very important that you do it.
--Gandhi
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Tiered Container Hierarchy
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Gonzalo Diethelm [mailto:gonzalo.diethelm@aditiva.com]
>
> > That is: Merlin's Fortress is based on Tweety and Phoenix
> is based on
> > Merlin's Fortress (can we come up with a better name for
> this, please?)
>
> How about "Forlin"? It has a nice sindarin-ish twist to it... ;-)
What about something not as glamorous like "Standard Edition"...
There are many things you can call it, however it is a *new*
effort so there needs to be a new name.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Tiered Container Hierarchy
Posted by Gonzalo Diethelm <go...@aditiva.com>.
> That is: Merlin's Fortress is based on Tweety and Phoenix is based on
> Merlin's Fortress (can we come up with a better name for this, please?)
How about "Forlin"? It has a nice sindarin-ish twist to it... ;-)
--
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: Tiered Container Hierarchy
Posted by Stefano Mazzocchi <st...@apache.org>.
Berin Loritsch wrote:
> I would like to propose set of tiered containers and the appropriate
> compliance
> test suites. The approach requires all of us to work together (building
> community
> as Stefano wants), and satisfies the real need for more than one
> container in
> Avalon. It would work something like this:
>
> 1) Micro Container--a Tweety like container that can operate in J2ME. It
> requires
> that only threadsafe components be used because it is unlikely that
> multithreading
> will be used in that environment. It is severly limited, and
> identifies the minimum
> requirements for Avalon compliance.
>
> 2) Standard Container--the result of merging Merlin and Fortress. It
> will be able to
> support embedding in a larger container (like J2EE) as well as the
> more robust
> component handling (pooling, thread-local, etc.).
>
> 3) Server Container--Phoenix. It identifies the requirements for a root
> level container
> that hosts server applications. It will not be embeddable because it
> is the kernel.
>
> I think that this approach will satisfy the community needs as well as
> the needs for
> different types of containers. It is also important to focus on
> container/component
> contracts in each of these--all the while providing a reasonable default
> implementation.
You would see me happy on this only if each container used the
underlying one.
That is: Merlin's Fortress is based on Tweety and Phoenix is based on
Merlin's Fortress (can we come up with a better name for this, please?)
That would solve all my concerns and would force people to work together
and create a community because they would share not only the syntax and
the semantics but also the behavior. And would force all containers to
keep in synch.
[note that this reflects the inheritance model of OOP which this very
community seems to have forgotten since Avalon doesn't make extensive
use of it]
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tiered Container Hierarchy
Posted by Paul Hammant <Pa...@yahoo.com>.
Berin,
I've said before that I like the idea of Tweety moving to
Avalon-Framework as the 'example container'. People can download one
zip and 'get' Avalon (one of out biggest problems). A Tweety-like
container hardened for J2ME would be cool too.
2,3 - sounds good. Continue finding commonality of packages as and when.
Make sure that A-F interfaces are the client API for all. Be ready for
other containers in the 2,3 space by other teams (Turbine). Cool.
- Paul H
> I would like to propose set of tiered containers and the appropriate
> compliance
> test suites. The approach requires all of us to work together
> (building community
> as Stefano wants), and satisfies the real need for more than one
> container in
> Avalon. It would work something like this:
>
> 1) Micro Container--a Tweety like container that can operate in J2ME.
> It requires
> that only threadsafe components be used because it is unlikely that
> multithreading
> will be used in that environment. It is severly limited, and
> identifies the minimum
> requirements for Avalon compliance.
>
> 2) Standard Container--the result of merging Merlin and Fortress. It
> will be able to
> support embedding in a larger container (like J2EE) as well as the
> more robust
> component handling (pooling, thread-local, etc.).
>
> 3) Server Container--Phoenix. It identifies the requirements for a
> root level container
> that hosts server applications. It will not be embeddable because
> it is the kernel.
>
> I think that this approach will satisfy the community needs as well as
> the needs for
> different types of containers. It is also important to focus on
> container/component
> contracts in each of these--all the while providing a reasonable
> default implementation.
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tiered Container Hierarchy
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> I would like to propose set of tiered containers and the appropriate
> compliance
> test suites. The approach requires all of us to work together
> (building community
> as Stefano wants), and satisfies the real need for more than one
> container in
> Avalon. It would work something like this:
+1
>
> 1) Micro Container--a Tweety like container that can operate in J2ME.
> It requires
> that only threadsafe components be used because it is unlikely that
> multithreading
> will be used in that environment. It is severly limited, and
> identifies the minimum
> requirements for Avalon compliance.
>
> 2) Standard Container--the result of merging Merlin and Fortress. It
> will be able to
> support embedding in a larger container (like J2EE) as well as the
> more robust
> component handling (pooling, thread-local, etc.).
>
> 3) Server Container--Phoenix. It identifies the requirements for a
> root level container
> that hosts server applications. It will not be embeddable because
> it is the kernel.
>
> I think that this approach will satisfy the community needs as well as
> the needs for
> different types of containers. It is also important to focus on
> container/component
> contracts in each of these--all the while providing a reasonable
> default implementation.
This is do-able. I also agree with Stafano that this has to be
approached with reuse of facilities across products. I see that comming
from a common Avalon Container API of which the client side is in place
today (the existing framework package). While Excalibur contains
several shared resources between existing approaches - I do think we
need a framework/container package into which we excalate some of these
common services, and a proposal/container for interim work on common
solutions.
Cheers, Steve.
>
>
> ---------------------------------------------
> Introducing NetZero Long Distance
> 1st month Free!
> Sign up today at: www.netzerolongdistance.com
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
--
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: Tiered Container Hierarchy
Posted by "Noel J. Bergman" <no...@devtech.com>.
Berin:
> 1) Micro Container--a Tweety like container that can operate in J2ME.
> It requires that only threadsafe components be used because it is
> unlikely that multithreading will be used in that environment.
As possibly one of the few people around here actually using J2ME (and a
book on the subject in my lap), my only amendment here is that
multi-threading does need to be permitted, just not required. It is
optional in J2ME CDC, and supported in J2ME CLDC.
As for the plan by which these containers arrive, I think that Stephen
McConnell and Peter Donald have each posted ideas that could be woven into a
community roadmap upon which to start the journey.
PaulH:
> Be ready for other containers [by] other teams (Turbine).
And they'll benefit, too, from the development of a true framework for
containers. They will be able to reuse the code and patterns developed for
building the container tier.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>