You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2002/11/20 10:19:46 UTC
Single Avalon Implementation yes/no/why/how ( Re: CVS organization
)
Carsten Ziegeler wrote:
> Nicola Ken Barozzi wrote:
>
[...]
>> 3) The containers that are in the works, as cool as they seem to be,
>>are still scratchpad stuff, and thus should be clearly put in a place
>>where it's clear to all. Current structure is really confusing, and
>>releases are a very important part of our system.
>>
>
> And personally I'm still wondering if we really need different
> implementations
> with different features. But this is another topic, we should discuss
> when it is time.
Actually, I think it's time, and as for the topic, I've made a new one ;-)
It can be that we will eventually come to a single design, and in fact
Merlin and Fortress developers have worked well on this. It seems to be
doable, and probably it hasn't been so near.
But it has to be agreed on by everyone, and everyone has to work on that
codebase.
Phoenix is released, proved and really stable. Think that someone has
even gotten James working on a C# based JVM (ok, technically it doesn't
mean much but it's amusing that he tried it on James).
Merlin and Fortress are new promising designs, that actually have been
collaborating and partially converging.
Technically it seems sensible that there be one framework and more
possible implementations. Community-wise, I'm not so sure.
Think for example about a Cocoon framework and multiple implementations.
It's even hard to immagine.
I still don't see major needs of having different implementations. Maybe
different running environments, different profiles, but one
implementation, as Cocoon has Serlet, CLI, etc running modes.
But I also don't have a solution at hand; if we cannot come to a single
implementation, probably it's because we still don't know how to do it.
In this case, I'm not sure we should even release an implementation (not
talking about Phoenix).
Comments?
--
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: Single Avalon Implementation yes/no/why/how ( Re: CVS organization )
Posted by Peter Donald <pe...@apache.org>.
On Thu, 21 Nov 2002 02:25, Federico Barbieri wrote:
> In a perfect world of course. But during development implementing a
> feature may get in others people way and this is bad.
> Moreover some feature are really just experiments and you need to leave
> some freedom for experimenting.
+1
> At last there are cases where you can implement the same feature in
> different incompatible ways and it's very hard to chose on a technical
> base. instead of forcing people in endless frustrating discussions just
> let them go. Hopefully people will be wise, give up their pride and find
> a compromise.
>
> Microforks are natural and quite productive if they take place with a
> constructive attitude.
+1
--
Cheers,
Peter Donald
Doubt is not a pleasant condition, but certainty is absurd.
-- Voltaire
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Single Avalon Implementation yes/no/why/how ( Re: CVS organization )
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Federico Barbieri wrote:
> >>
> >Ok, as I tried to express, I agree on having different implementations
> >because of scalability and performance, but not on features.
> >
> In a perfect world of course. But during development implementing a
> feature may get in others people way and this is bad.
> Moreover some feature are really just experiments and you need to leave
> some freedom for experimenting.
> At last there are cases where you can implement the same feature in
> different incompatible ways and it's very hard to chose on a technical
> base. instead of forcing people in endless frustrating discussions just
> let them go. Hopefully people will be wise, give up their pride and find
> a compromise.
>
> Microforks are natural and quite productive if they take place with a
> constructive attitude.
>
Of course, that's true - most time, microforks are required to keep the
development running.
And I don't want to force anyone (even if I wanted it wouldn't work anyway).
So I will see what's happening and try to help as best as I can.
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Single Avalon Implementation yes/no/why/how ( Re: CVS organization
)
Posted by Federico Barbieri <fe...@betaversion.org>.
Carsten Ziegeler wrote:
>Federico Barbieri wrote:
>
>
>>>Paul Hammant wrote:
>>>
>>>
>>>
>>>
>>>>(Vote) -1
>>>>
>>>>
>>>>
>>(strong opinion) -0.99
>>
>>two reasons:
>>first there is been tension and flames, if you force everyone into the
>>same room you'll get more. Let the dust settle first.
>>second IMHO avalon scope is wide enough to justify more than one
>>implementation (not many but more than one).
>>I may want to *focus* on performances, scalability, user friendlness,
>>resource usage etc.
>>
>>
>>
>Ok, as I tried to express, I agree on having different implementations
>because of scalability and performance, but not on features.
>
In a perfect world of course. But during development implementing a
feature may get in others people way and this is bad.
Moreover some feature are really just experiments and you need to leave
some freedom for experimenting.
At last there are cases where you can implement the same feature in
different incompatible ways and it's very hard to chose on a technical
base. instead of forcing people in endless frustrating discussions just
let them go. Hopefully people will be wise, give up their pride and find
a compromise.
Microforks are natural and quite productive if they take place with a
constructive attitude.
>But perhaps it's really better to see the development of the current
>implementations grow nad have a look then at what we have.
>
>
>Carsten
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Single Avalon Implementation yes/no/why/how ( Re: CVS organization )
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Federico Barbieri wrote:
>
> >Paul Hammant wrote:
> >
> >
> >>(Vote) -1
> >>
> (strong opinion) -0.99
>
> two reasons:
> first there is been tension and flames, if you force everyone into the
> same room you'll get more. Let the dust settle first.
> second IMHO avalon scope is wide enough to justify more than one
> implementation (not many but more than one).
> I may want to *focus* on performances, scalability, user friendlness,
> resource usage etc.
>
Ok, as I tried to express, I agree on having different implementations
because of scalability and performance, but not on features.
But perhaps it's really better to see the development of the current
implementations grow nad have a look then at what we have.
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Single Avalon Implementation yes/no/why/how ( Re: CVS organization
)
Posted by Federico Barbieri <fe...@betaversion.org>.
Carsten Ziegeler wrote:
>Paul Hammant wrote:
>
>
>>(Vote) -1
>>
(strong opinion) -0.99
two reasons:
first there is been tension and flames, if you force everyone into the
same room you'll get more. Let the dust settle first.
second IMHO avalon scope is wide enough to justify more than one
implementation (not many but more than one).
I may want to *focus* on performances, scalability, user friendlness,
resource usage etc.
>And what can I do, if I want to combine to open source projects,
>the first one using container implementation A and the second
>one container implementation B? Hmmm.
>
The idea is they should both been Afalon framework compatible and so in
an idel world component should be container independent. Whenever this
is not going to happend it will be time to work together.
My vision is that AF is the Java language specification and each
container is a different vm implementation.
Component should be 100% pure avalon.
fede
>
>Carsten
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Single Avalon Implementation yes/no/why/how ( Re: CVS organization )
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Mailet container (apols to JAMES lurkers for rehashing old topics)
LOL ... someone still owes us a sample to demonstrate what that would mean.
;-) And we'll be dealing with Mailet API v2 discussions, probably starting
in December.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Single Avalon Implementation yes/no/why/how ( Re: CVS organization )
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Paul Hammant wrote:
>
> Carsten,
>
> > Perhaps I had a wrong understanding of the different implementations
> > we currently have - I thought, it's not only the way how to
> > configure the components but also that there are some difference
> > in the features provided to implement components.
>
> Implementation is one thing. Lacing (lookup & assembly) and
> configuration are another.
>
> Imagine these abstract ideas :
>
> 1) Servlet container (one design along A-F lines rather
> than Sun's established javax.servlet standard)
> 2) Bean container (as above)
> 3) Mailet container (apols to JAMES lurkers for rehashing old topics)
> 4) Newslet container
> 5) Gopherlet container
> 6) Portlet container
>
> These comps all honor the usual interfaces - Startable,
> Initializable .. i.e. our principal art.
>
> Imagine that these comps come in their own packaging - WAR, EAR,
> JAR with their own assembly
> manifests (web.xml, ejb-jar.xml etc).
>
> Imagine that these comps all have subtle differences in context -
> BeanContext (as EOB does),
> ServletContext, MailetContext, GopherletContext.
> Contextualizable passes in Context. The comp
> casts it to the suitable sub-interface and uses its special features.
>
> That's all for container-in-contrainer scenarios though.
>
Hmmm, ok I understand this - and I (now) totally agree with you
here. But (sorry it's in my nature to write each second sentence
a 'but') these are containers for different purposes. You can't
use the newslet container implementation for portlets, e.g.
At this point I agree with you, but I would not agree if you
would have two portlet container implementations which are
configured (or their components) in different ways.
> <snip>
>
> A-F interfaces make them compatible. I have some workside
> projects that use multiple containers
> (like those above) in one CVS tree for different run scenarios.
> I assure you that A-F is the
> magic, not comp-lacing. And it is magic.
>
It is, definitly! And I agree from a components implementor view
that's a very good solution (or better, the best solution).
Now, perhaps we are talking about the same things. Let's have a
look at an example: I want to develop the coolest web publishing
framework in the work and of course I want to use A-F.
So far, no problems - now I choose to use Implementation A for this
which is configured via a configuration XML with format A.dtd.
After some time, I figure out that A does not scale under
some circumstances.
Now I want to replace A with Implementation B. Unfortunately B
uses B.dtd for configuration and I have to rewrite my whole
configuration - so implementations are not easily exchangeable.
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Single Avalon Implementation yes/no/why/how ( Re: CVS organization )
Posted by Paul Hammant <pa...@yahoo.com>.
Carsten,
> Perhaps I had a wrong understanding of the different implementations
> we currently have - I thought, it's not only the way how to
> configure the components but also that there are some difference
> in the features provided to implement components.
Implementation is one thing. Lacing (lookup & assembly) and configuration are another.
Imagine these abstract ideas :
1) Servlet container (one design along A-F lines rather
than Sun's established javax.servlet standard)
2) Bean container (as above)
3) Mailet container (apols to JAMES lurkers for rehashing old topics)
4) Newslet container
5) Gopherlet container
6) Portlet container
These comps all honor the usual interfaces - Startable, Initializable .. i.e. our principal art.
Imagine that these comps come in their own packaging - WAR, EAR, JAR with their own assembly
manifests (web.xml, ejb-jar.xml etc).
Imagine that these comps all have subtle differences in context - BeanContext (as EOB does),
ServletContext, MailetContext, GopherletContext. Contextualizable passes in Context. The comp
casts it to the suitable sub-interface and uses its special features.
That's all for container-in-contrainer scenarios though.
---
How about the coarse-grained server of server apps. Merlin and Phoenix today, others tomorrow.
OK, Lets talk over 'the others' ...
Imagine...
1) 'Diamond' - It uses some run-time optimizing lookup mechanism for services and LDAP for
configuration/meta.
2) 'Nano' - A single-class component-bootstrap server that uses can bring up components in teh
right order from a properties file or command line args.
3) 'Wolfstream' - A container that only ever operates in a federation of servers and that some
primary/secondary master servers indicate comp lacing (and whether those impls are local or remote
- it uses AltRMI don't ye know). I.e. the local comps have no meta.
4) 'Adapterver' Some container that prifiles the codebase and laces components dynamically without
any instruction
5) 'Redunderver' As (4) but invokes all impls of the same server with the same method requests for
some sort of Spaceshuttle/failsafe behaviour.
Phew! Comps are just implementors of A-F interfaces. Their original writers may be amazed where
they are used or how they are laced together. So what if 'Redunderver' coders have to write some
more manifests.
- Paul
> Hmm, is there a rough explanation of the differences available?
> > Embrace the multi-container world!!
> >
> And what can I do, if I want to combine to open source projects,
> the first one using container implementation A and the second
> one container implementation B? Hmmm.
A-F interfaces make them compatible. I have some workside projects that use multiple containers
(like those above) in one CVS tree for different run scenarios. I assure you that A-F is the
magic, not comp-lacing. And it is magic.
- Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Single Avalon Implementation yes/no/why/how ( Re: CVS organization )
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Paul Hammant wrote:
>
> (Vote) -1
>
This is not a vote, it's an RT ;) (just kidding)
> I do not believe it is necessary to make the containers we have
> compatible at anything other than
> Avalon-Framework-Interface level.
Ok.
> If we strive for compatibility
> on component-lacing (XML,
> properties, whatever) we will find some other team does not honor
> the chosen lacing team an
> delivers a container with a twist. This could be BEA, Pramati,
> JBoss, Catalina, OpenEJB, Lutris.
> It could be some University in Bangalore or Manila. We cannot
> contain the container landscape;
> we'd be foolish to try. There are thing people are imagining now
> that will impress the socks off
> us when released.
>
Perhaps I had a wrong understanding of the different implementations
we currently have - I thought, it's not only the way how to
configure the components but also that there are some difference
in the features provided to implement components.
Hmm, is there a rough explanation of the differences available?
I think, there was a discussion about this some months ago in
the mailing list, right. So I can look up there.
Anyway, different implementations mean different code bases for
the same tasks. An alternative might be (and it's nothing more
than a loud thought) to have a common core and several "plugins"
for the different purposes.
> Better to concentrate on our core product -> Avalon Framework's
> interfaces.
>
It's correct, that this is the first part to do.
> Embrace the multi-container world!!
>
And what can I do, if I want to combine to open source projects,
the first one using container implementation A and the second
one container implementation B? Hmmm.
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Single Avalon Implementation yes/no/why/how ( Re: CVS organization )
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Paul,
> I'm still -1 on the "massive hierarchy of Context interfaces", however
> you are right to point out that as a user, you are right to rase you
> concerns. You inport is more relevant that <apologies> partisan
fighters
> on from this list.
Why you envision a massive hierarchy of Context interfaces is somewhat
confusing to me. I would not expect the set of Context interfaces to be
massive, or necessarily a hierarchy.
> There are specialist containers like James which would probably go the
> strongly typed route for it's hosted components (Mailets,
> ForwardingMailets, ConsumingMailets, FilteringMailets,
DivertingMailets
> etc.). A rude assumption that you folks rejoin the A-F believer's
camp ;-
> )
Uh...James is not an Avalon container. Mailets have zero to do with
this discussion. Even if mailets adopt some of the Avalon lifecycle
interfaces, there appears to be no belief that mailets need to be full
Avalon components.
> Maybe for general containers we do have some extended Context defined
in
> the A-F package (I will not vote in favor of some other package
> Meta/Info/Uber/X for standard inclusion for A-F contact). What I am
> floating for idea is
>
> public interface Context {
> Object get( Object key ) throws ContextException;
> }
>
> public interface ContainerInstructableContext {
> void requestShutdown();
> }
>
> public interface ClassLoaderQueryingContext {
> ClassLoader getClassLoader(String name);
> }
>
> These are a single dimensional list of interfaces that could be usable
> to a number of containers (general or bespoke). There is deliberatedly
> no inheritance here. The hierarchy would be a fallasy. Container
> writers choose which of the interfaces they support. Specialist
> container writers (say JAMES) support a couple of these, but largely
> push ahead with their own context, which is *definatly* not bound into
> the A-F interface structure.
>
The above is (at least in structure) the syntactic sugar version of what
I suggested in the previous email. Not sure that each interface needs
to have just a single method, but whatever. So obviously the structure
doesn't bother me.
Couldn't care less whether it's a hierarchy or not. Some context
interfaces might naturally extend, others might not. Certainly wouldn't
include random packages - every interface would be within the standard
framework hierarchy.
As I said in my previous email, custom contexts would be permissible.
If eventually those contexts were desirable to a larger community, they
could be repackaged and voted into the framework.
Why do you keep referring to James as a container? James is not an
Avalon container. It is an Avalon consumer. It's a mailet container.
Big difference.
> e.g. for JAMES (and in James's CVS)
>
> public interface BaseMailetContext extends Context {
> Blah getSomeCommonJamesThing();
> }
>
>
> public interface ForwardingMailetContext extends BaseMailetContext {
> void forward(MailItem mailItem, String mailRecipient);
> }
>
> public interface ComsumingMailetContext extends BaseMailetContext {
> void consume(MailItem mailItem);
> }
This is not what we're talking about. There has been no interest on the
James mailing list of becoming a full fledged container. As I'm one of
the most pro-Avalon folks on the list, and I don't think it's a good
idea, I doubt it's going to fly. Feel free to post the suggestion to
james-dev though...
> It does not address a declaration mechanism. The container could
simply
> catch NoClassDefFound or some simple (please god) mechanism could be
> found. Given that is meta info, I am going to push for Container
> writer's choosing their own lacing mechanism.
Agreed. I have never pushed for a one fits all declaration mechanism.
All I'm asking is that declaration be possible. If Merlin wants to use
some automagic declaration and dependency discovery system, that's
great. If Phoenix wants to publish a list of interfaces implemented by
its implementation of Context, that's also great. Don't care. Just as
long as I can figure out by perusing the docs whether a given app will
run in a given container. It should not be necessary to "try it and
see".
>From a consumer approach, this is what matters. IMHO the Avalon
community has gotten into a bit of container-centric navel gazing.
Consider the following question. What is the ratio of J2EE applications
in production to J2EE containers used in production systems? If that
ratio is under 1000 I'd be absolutely shocked. So as framework authors
the focus should be on the consumer, not the container.
As an Avalon consumer, here is what I would like to be possible:
i) It is possible to write a non-trivial application that takes
advantage of all phases of the lifecycle and runs in any Avalon
container that meets the Avalon Framework spec. Not all applications
will be portable, as some applications may take advantage of
container-specific features.
ii) Migration of this portable application from one container to another
should involve changing no Java code. It may or may not require
addition/modification/removal of deployment descriptor files.
iii) Containers should be able to document their levels of support and
compatibility in a meaningful way that doesn't reference any
"uber-container". That is, compatibility definitions should reside in
the common area and not be in the bailiwick of any one container. By
reading the docs for the container and component (assuming a properly
documented component) it should be possible for me to determine if the
component will run properly on the container.
> >This approach would allow containers to declare simply in their
> >documentation what context contracts they support. Component
developers
> >could declare what context contracts they require. Component
deployers
> >would know immediately whether a container was sufficient to run
their
> >component.
> >
> Covered I think.
Certainly not covered in the current implementation. Covered by the
changes above.
> >For example, James could put something in the docs that states "Any
> >Avalon container that supports the File context contract is
sufficient
> >to run the James server.". If there were a container designed to run
on
> >an embedded platform that didn't expose a file system, it would be
> >immediately obvious from the docs that James wouldn't function.
> >
> >
> Covered, apart from the declaration.
Ditto to my above comment.
> >This approach would maintain the flexibility that people clearly want
> >(i.e. Noel's suggestion of J2ME support, 31 containers of different
> >flavors) while allowing component developer/deployers to have a more
> >efficient approach to application deployment than "try it and see".
> >
> >Moreover, nothing in the above prevents container developers from
> >rolling out their own "custom" context contracts.
> >
> Agree.
>
> >It's just that any
> >component that uses such a contract will be tied to that container
and
> >that container alone. That's ok, because the dependencies will be
clear
> >to the component developers and deployers. As container/framework
> >versions iterate, context interfaces/contracts that are seen as
> >generally useful could be moved into the framework.
> >
> Agree, but without the hierarchy (a fallacy).
There's a priori no hierarchy. Whether the community wants to make one
interface inherit from another is up to the community. I couldn't care
less.
> >>tiny Phoenix-Client jar in it's client API classloader and honors
> >>BlockContext as is (if it wanted to be compatible with Phoenix).
> >>
> >>
> >
> >And that's exactly the problem we're trying to resolve. This
approach
> >makes Phoenix first among all containers. I like Phoenix, and I have
> >suppored using Phoenix for James' standard distribution, but you
can't
> >simultaneously argue that all containers are equal, while stating
that
> >some containers are more equal than others. Last I checked, Animal
Farm
> >wasn't on any university's computer science reading list. :)
> >
> >
> A good point. We'll disagree though
Again, I don't see how you maintain a consistent POV. And quite
honestly, I think this is the nub of the problem. By espousing the
"first among equals" position, Phoenix evangelists simply tick other
people off.
> >Phoenix is a very good container. I'm impressed by Phoenix, but this
> >sort of single container-centric view is detrimental to the
> >multi-container world view you seem to want to espouse. Personally,
I
> >don't see how you can resolve the two.
> >
> Yup.
Uh...?
> >We (specifically some of the Avalon consumers) keep trying to make
clear
> >that the line needs to be drawn between what is common and what is
not.
> >General components should only need to be aware of the details of the
> >commons (framework, Apache commons, Jakarta commons). They shouldn't
> >need to know anything about a particular container - not even its
name.
> >
> True, but as third and fourth coarse containers enter the fray, they
> will seek to emulate first and second. Perhaps wrong, I accept.
Wrong. And contrary to observed facts.
I think the recent discussion makes clear that the Merlin folks don't
want to emulate Phoenix. I don't see any reason why new container
implementers would emulate pre-existing containers. Generally new
containers will arise precisely when developers believe there is an
inadequacy or flaw in the pre-existing containers. That's how
innovation works.
Common is common. Per-container is per-container. There's no reason to
blur the line. When you do, it just turns into a "my container is
better than your container" fight. Let the market determine which
containers find the most use - it shouldn't be the decision of any small
group of developers.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Single Avalon Implementation yes/no/why/how ( Re: CVS organization )
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I'm happy with the interfaces themselves. To all intents and purposes
> they hae been stable for years. Docs being incomplete is where I'll
> meet you on definition.
> True, but as third and fourth coarse containers enter the fray, they
> will seek to emulate first and second. Perhaps wrong, I accept.
This appears to reflect a fundamental disconnect that Peter, I and other
users seek to eliminate. It should never be the case that a justification
is given that "Well, container A doesn't work like container B therefore
..." This is not contract by prototype. I just want that point to be
crystal clear, all by itself.
-------------
So what to do about it? The semantic contracts need to be well-defined and
documented as part of the Framework. It is said that the only guarantee of
portability is through the Frameworks. We agree, and in wanting to enforce
that notion are pointing out that the Framework's semantic contracts need to
be more fully rendered. If there is a portable semantic, that contract
needs to be part of the Frameworks.
Specifically how that happens is certainly TBD. But is there any
disagreement with the basic goal?
> > As container/framework versions iterate, context
> > interfaces/contracts that are seen as generally
> > useful could be moved into the framework.
> Agree, but without the hierarchy (a fallacy).
Who was promoting it as a hierarchy?
> Only if you are interested in component/container interoperability.
> If you were a commercial company that had chosen one container over
> another, strongy typed context is an advantage.
This tension can be resolved.
As for the mechanisms, I agree that a mechanism should be simple (and
elegant). As for what is must be common, and what needn't be, I think the
current approach is that where there is client access, the interface needs
to come from Frameworks, but that doesn't mandate any particular
implementation.
By the way, I'm probably the person most willing to investigate an Avalon
Container model for James Mailets, and I am fairly sure that it will not
happen in the major redesign for James v3.0/Mailet API v2. For a number of
reasons: (1) we're still waiting to see what that would entail; (2) the
current instability within Avalon; (3) others (including Peter) are not in
favor of it, and I'm not likely to champion that approach given #2 with #1
still outstanding; (4) we have other design considerations to resolve. But
I will keep it in mind.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Single Avalon Implementation yes/no/why/how ( Re: CVS organization
)
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>We do have a definition :-
>>
>>
>>
>http://jakarta.apache.org/avalon/framework/reference-the-lifecycle.html
>
>
>>I do accept that docs could be improved.
>>
>>
>
>The definition is incomplete. That's not a big deal - it's a typical
>situation for a framework in development. I'm just saying that it needs
>a little work. And that the work would be best served if contributors
>to a number of containers chimed in and the points of commonality are
>properly identified.
>
I'm happy with the interfaces themselves. To all intents and purposes
they hae been stable for years. Docs being incomplete is where I'll
meet you on definition.
>>This is because Context is a base for ServletContext (the A-F design
>>
>>
>not
>
>
>>yet written), MailetContext, BeanContext (written for EOB),
>>
>>
>BlahContext.
>
>
>> Some of them may offer a 'get root dir' feature, some may not. Do we
>>encode all permutations for Servlets, Mailets, Beans, Blocks,
>>
>>
>MerlinApps
>
>
>>in the same file? I think not. Anyone can code a component that can
>>implements one or all of the A-F interfaces, and is extended by say
>>
>>
>two
>
>
>>subclasses (also comps). e.g.
>>
>> abstract class FooDaemon implements Startable, Runnable,
>>Contextualizable {
>> Thread thread;
>> File rootDir;
>> // from A-F Startable
>> void start() {
>> thread = new Thread(this);
>> thread.start();
>> }
>> // from A-F Startable
>> void stop() {
>> thread.stop();
>> }
>> }
>>
>> class PhoenixFooDaemon extends FooDaemon {
>> // from A-F Contextualizable
>> void contextualize(Context context) {
>> rootDir = ((BlockContext) context).getRootDir();
>> }
>> }
>>
>> class EOBFooDaemon extends FooDaemon {
>> // from A-F Contextualizable
>> void contextualize(Context context) {
>> rootDir = ((BeanContext) context).getRootDir();
>> }
>> }
>>
>>With the above design, you interoperability with Phoenix and EOB (a
>>
>>
>.Net
>
>
>>Remoting inspired app server I work on). Replace the word 'EOB' with
>>JAMES (one day?), or Merlin, or Catalina's internals (one day?).
>>Containers are all different. They use differnet cop-lacing, config
>>
>>
>and
>
>
>>context.
>>
>>The point is that Context is deliberately vague. Either we define a
>>massive hierarchy of Context interfaces in the A-F package (and curse
>>ourselves at our liesure over the years), or we leave the context to
>>
>>
>the
>
>
>>container in question. Phoenix and Merlin are just two containers.
>> They are not going to be the last 'coarse grained application server'
>>containers.
>>
>>
>
>I don't really agree with the above. :) Which, of course, is why I
>asked for discussion on the topic. The subclassing you suggest is
>interesting, but i) making it necessary for the components to be aware
>of specific context implementations and ii) placing those
>implementations in container space as opposed to common space seem to
>kill the proposal for me as an Avalon consumer.
>
Only if you are interested in component/container interoperability. If
you were a commercial company that had chosen one container over
another, strongy typed context is an advantage. If you change your mind
on container, then refactoring from FooContext to BarContext is cheap.
If you are a generic provider of comps then you'll err towards weak
typing I guess. * More later.
>Context, as currently designed, is useless. It requires Avalon
>components that wish to use elements out of the context to be aware of
>container level details that are not specified in the framework. For
>clarity on this issue, see the org.apache.james.context package in the
>James source code. But the long and the short of it is that the
>vagueness of the Context contract makes it impossible for a consumer to
>write a container-independent component that uses the Context.
>
>I think your suggestion of a "massive hierarchy of Context interfaces",
>despite the clear negative connotation, is the most sensible suggestion
>in the above.
>
I'm still -1 on the "massive hierarchy of Context interfaces", however
you are right to point out that as a user, you are right to rase you
concerns. You inport is more relevant that <apologies> partisan fighters
on from this list.
There are specialist containers like James which would probably go the
strongly typed route for it's hosted components (Mailets,
ForwardingMailets, ConsumingMailets, FilteringMailets, DivertingMailets
etc.). A rude assumption that you folks rejoin the A-F believer's camp ;-)
Maybe for general containers we do have some extended Context defined in
the A-F package (I will not vote in favor of some other package
Meta/Info/Uber/X for standard inclusion for A-F contact). What I am
floating for idea is
public interface Context {
Object get( Object key ) throws ContextException;
}
public interface ContainerInstructableContext {
void requestShutdown();
}
public interface ClassLoaderQueryingContext {
ClassLoader getClassLoader(String name);
}
These are a single dimensional list of interfaces that could be usable
to a number of containers (general or bespoke). There is deliberatedly
no inheritance here. The hierarchy would be a fallasy. Container
writers choose which of the interfaces they support. Specialist
container writers (say JAMES) support a couple of these, but largely
push ahead with their own context, which is *definatly* not bound into
the A-F interface structure.
e.g. for JAMES (and in James's CVS)
public interface BaseMailetContext extends Context {
Blah getSomeCommonJamesThing();
}
public interface ForwardingMailetContext extends BaseMailetContext {
void forward(MailItem mailItem, String mailRecipient);
}
public interface ComsumingMailetContext extends BaseMailetContext {
void consume(MailItem mailItem);
}
It does not address a declaration mechanism. The container could simply
catch NoClassDefFound or some simple (please god) mechanism could be
found. Given that is meta info, I am going to push for Container
writer's choosing their own lacing mechanism.
Similarly Jesktop (a comtainer I need to update soon) could have ...
public interface DesktopContext extends Context {
void someDesktopInteraction(String blah);
}
... but that clearly has no place in the A-F set.
The point is that the set is small. More later!
>Each of the Context related interfaces would be p
>
>
>art of
>the definition of a contract that would be part of the framework. They
>could be simple marker interfaces with associated key/object pairs
>guaranteed by the contract, or they could have substantial syntactic
>sugar (a la Phoenix's BlockContext class). By using lightweight,
>tightly defined interfaces that basically provide keys for the get() or
>provide syntactic sugar that wraps the get, we ensure that we don't
>overly restrict containers. Context doesn't care how the container
>provides the object in the contract, only that it provides it.
>
>This approach would allow containers to declare simply in their
>documentation what context contracts they support. Component developers
>could declare what context contracts they require. Component deployers
>would know immediately whether a container was sufficient to run their
>component.
>
Covered I think.
>For example, James could put something in the docs that states "Any
>Avalon container that supports the File context contract is sufficient
>to run the James server.". If there were a container designed to run on
>an embedded platform that didn't expose a file system, it would be
>immediately obvious from the docs that James wouldn't function.
>
>
Covered, apart from the declaration.
>This approach would maintain the flexibility that people clearly want
>(i.e. Noel's suggestion of J2ME support, 31 containers of different
>flavors) while allowing component developer/deployers to have a more
>efficient approach to application deployment than "try it and see".
>
>Moreover, nothing in the above prevents container developers from
>rolling out their own "custom" context contracts.
>
Agree.
>It's just that any
>component that uses such a contract will be tied to that container and
>that container alone. That's ok, because the dependencies will be clear
>to the component developers and deployers. As container/framework
>versions iterate, context interfaces/contracts that are seen as
>generally useful could be moved into the framework.
>
Agree, but without the hierarchy (a fallacy).
>This is a standard
>paradigm of framework and API development.
>
>This discussion is a standard extensibility/usability trade-off. By
>making Context essentially infinitely extensible (it's nothing more than
>a glorified HashMap) it's been made totally useless. This can be
>resolved by giving the component deployers narrow contracts defined in
>the common code base (i.e. framework) that they can check and validate
>their components against. How we do this is really the question.
>
>
>
>>Apart from anything else, it was voted on before that Merlin include
>>
>>
>the
>
>
>>tiny Phoenix-Client jar in it's client API classloader and honors
>>BlockContext as is (if it wanted to be compatible with Phoenix).
>>
>>
>
>And that's exactly the problem we're trying to resolve. This approach
>makes Phoenix first among all containers. I like Phoenix, and I have
>suppored using Phoenix for James' standard distribution, but you can't
>simultaneously argue that all containers are equal, while stating that
>some containers are more equal than others. Last I checked, Animal Farm
>wasn't on any university's computer science reading list. :)
>
>
A good point. We'll disagree though
>Phoenix is a very good container. I'm impressed by Phoenix, but this
>sort of single container-centric view is detrimental to the
>multi-container world view you seem to want to espouse. Personally, I
>don't see how you can resolve the two.
>
Yup.
>
>
>
>>>I'd argue that a standard, minimal set of keys/object should be part
>>>
>>>
>of
>
>
>>>the Context contract. Otherwise the Context interface is fairly
>>>
>>>
>useless
>
>
>>>as part of framework since every container would provide a purely
>>>
>>>
>custom
>
>
>>>set of keys/values. Thus any code written that implemented
>>>Contextualizable would be implicitly container dependent.
>>>
>>>
>>You can go for that if you like. Code something that is adaptive and
>>used the primitive get() mechanism.
>>
>>
>
>That would be fine. See my comments above.
>
>
>
>>Maybe we should have a single additional context method called
>>getContainer(). It returns "Phoenix 4.0.2" where that were true. Or
>>maybe a method called isCompatibleWith("Phoenix 4.x")
>>
>>
>
>Ugh. Typing containers via strings? Requiring components to be
>knowledgeable of container names which aren't defined in the framework?
>Double ugh.
>
I'm perhaps eluding to a more elegent discovery mechanism. Perhaps wrong.
>We (specifically some of the Avalon consumers) keep trying to make clear
>that the line needs to be drawn between what is common and what is not.
>General components should only need to be aware of the details of the
>commons (framework, Apache commons, Jakarta commons). They shouldn't
>need to know anything about a particular container - not even its name.
>
True, but as third and fourth coarse containers enter the fray, they
will seek to emulate first and second. Perhaps wrong, I accept.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Single Avalon Implementation yes/no/why/how ( Re: CVS organization )
Posted by "Noel J. Bergman" <no...@devtech.com>.
Peter,
I think that when it comes down to it, you are looking for a defined way to
address the idea that if a particular semantic is present in the
environment, that it is present in the same way in all implementations.
Depending upon the approach one wants to take, this can be via a text based
interface, a reflection based interface, or some combination. But the goal
is the same. No?
You are saying that regardless of which direction is chosen for
implementation, that as new important Contexts come up, they should be
well-defined so that implementors and consumers have the guidance necessary
to make reuse real, and in a container-independent fashion.
Am I correct that we agree on the concept, although the implementation is
unspecified?
> the vagueness of the Context contract makes it
> impossible for a consumer to write a container-
> independent component that uses the Context.
AIUI, what you mean is that without better contracts, even if the Context
interface is properly implemented, the concrete context handed to a
component may be semantically broken from the perspective of that component.
And you expect that by documenting well-defined specific contracts, that it
will enhance compatibility between contextualizable components and context
providers because both sides will know what is expected in a given semantic
domain.
I like your ideas for expressing such contracts, but I think that it helps
to also represent the concepts at an abstract level so that someone who
doesn't agree with your implementation still understands the perceived value
and goals. And I thought that you presented those quite well, too.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Single Avalon Implementation yes/no/why/how ( Re: CVS organization )
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Paul,
> We do have a definition :-
>
http://jakarta.apache.org/avalon/framework/reference-the-lifecycle.html
>
> I do accept that docs could be improved.
The definition is incomplete. That's not a big deal - it's a typical
situation for a framework in development. I'm just saying that it needs
a little work. And that the work would be best served if contributors
to a number of containers chimed in and the points of commonality are
properly identified.
> This is because Context is a base for ServletContext (the A-F design
not
> yet written), MailetContext, BeanContext (written for EOB),
BlahContext.
> Some of them may offer a 'get root dir' feature, some may not. Do we
> encode all permutations for Servlets, Mailets, Beans, Blocks,
MerlinApps
> in the same file? I think not. Anyone can code a component that can
> implements one or all of the A-F interfaces, and is extended by say
two
> subclasses (also comps). e.g.
>
> abstract class FooDaemon implements Startable, Runnable,
> Contextualizable {
> Thread thread;
> File rootDir;
> // from A-F Startable
> void start() {
> thread = new Thread(this);
> thread.start();
> }
> // from A-F Startable
> void stop() {
> thread.stop();
> }
> }
>
> class PhoenixFooDaemon extends FooDaemon {
> // from A-F Contextualizable
> void contextualize(Context context) {
> rootDir = ((BlockContext) context).getRootDir();
> }
> }
>
> class EOBFooDaemon extends FooDaemon {
> // from A-F Contextualizable
> void contextualize(Context context) {
> rootDir = ((BeanContext) context).getRootDir();
> }
> }
>
> With the above design, you interoperability with Phoenix and EOB (a
.Net
> Remoting inspired app server I work on). Replace the word 'EOB' with
> JAMES (one day?), or Merlin, or Catalina's internals (one day?).
> Containers are all different. They use differnet cop-lacing, config
and
> context.
>
> The point is that Context is deliberately vague. Either we define a
> massive hierarchy of Context interfaces in the A-F package (and curse
> ourselves at our liesure over the years), or we leave the context to
the
> container in question. Phoenix and Merlin are just two containers.
> They are not going to be the last 'coarse grained application server'
> containers.
I don't really agree with the above. :) Which, of course, is why I
asked for discussion on the topic. The subclassing you suggest is
interesting, but i) making it necessary for the components to be aware
of specific context implementations and ii) placing those
implementations in container space as opposed to common space seem to
kill the proposal for me as an Avalon consumer.
Context, as currently designed, is useless. It requires Avalon
components that wish to use elements out of the context to be aware of
container level details that are not specified in the framework. For
clarity on this issue, see the org.apache.james.context package in the
James source code. But the long and the short of it is that the
vagueness of the Context contract makes it impossible for a consumer to
write a container-independent component that uses the Context.
I think your suggestion of a "massive hierarchy of Context interfaces",
despite the clear negative connotation, is the most sensible suggestion
in the above. Each of the Context related interfaces would be part of
the definition of a contract that would be part of the framework. They
could be simple marker interfaces with associated key/object pairs
guaranteed by the contract, or they could have substantial syntactic
sugar (a la Phoenix's BlockContext class). By using lightweight,
tightly defined interfaces that basically provide keys for the get() or
provide syntactic sugar that wraps the get, we ensure that we don't
overly restrict containers. Context doesn't care how the container
provides the object in the contract, only that it provides it.
This approach would allow containers to declare simply in their
documentation what context contracts they support. Component developers
could declare what context contracts they require. Component deployers
would know immediately whether a container was sufficient to run their
component.
For example, James could put something in the docs that states "Any
Avalon container that supports the File context contract is sufficient
to run the James server.". If there were a container designed to run on
an embedded platform that didn't expose a file system, it would be
immediately obvious from the docs that James wouldn't function.
This approach would maintain the flexibility that people clearly want
(i.e. Noel's suggestion of J2ME support, 31 containers of different
flavors) while allowing component developer/deployers to have a more
efficient approach to application deployment than "try it and see".
Moreover, nothing in the above prevents container developers from
rolling out their own "custom" context contracts. It's just that any
component that uses such a contract will be tied to that container and
that container alone. That's ok, because the dependencies will be clear
to the component developers and deployers. As container/framework
versions iterate, context interfaces/contracts that are seen as
generally useful could be moved into the framework. This is a standard
paradigm of framework and API development.
This discussion is a standard extensibility/usability trade-off. By
making Context essentially infinitely extensible (it's nothing more than
a glorified HashMap) it's been made totally useless. This can be
resolved by giving the component deployers narrow contracts defined in
the common code base (i.e. framework) that they can check and validate
their components against. How we do this is really the question.
> Apart from anything else, it was voted on before that Merlin include
the
> tiny Phoenix-Client jar in it's client API classloader and honors
> BlockContext as is (if it wanted to be compatible with Phoenix).
And that's exactly the problem we're trying to resolve. This approach
makes Phoenix first among all containers. I like Phoenix, and I have
suppored using Phoenix for James' standard distribution, but you can't
simultaneously argue that all containers are equal, while stating that
some containers are more equal than others. Last I checked, Animal Farm
wasn't on any university's computer science reading list. :)
Phoenix is a very good container. I'm impressed by Phoenix, but this
sort of single container-centric view is detrimental to the
multi-container world view you seem to want to espouse. Personally, I
don't see how you can resolve the two.
> >I'd argue that a standard, minimal set of keys/object should be part
of
> >the Context contract. Otherwise the Context interface is fairly
useless
> >as part of framework since every container would provide a purely
custom
> >set of keys/values. Thus any code written that implemented
> >Contextualizable would be implicitly container dependent.
>
> You can go for that if you like. Code something that is adaptive and
> used the primitive get() mechanism.
That would be fine. See my comments above.
> Maybe we should have a single additional context method called
> getContainer(). It returns "Phoenix 4.0.2" where that were true. Or
> maybe a method called isCompatibleWith("Phoenix 4.x")
Ugh. Typing containers via strings? Requiring components to be
knowledgeable of container names which aren't defined in the framework?
Double ugh.
We (specifically some of the Avalon consumers) keep trying to make clear
that the line needs to be drawn between what is common and what is not.
General components should only need to be aware of the details of the
commons (framework, Apache commons, Jakarta commons). They shouldn't
need to know anything about a particular container - not even its name.
> >The only way to get a truly multi-container world is precisely to be
> >crystal clear about what the Avalon Framework does and does not
> >guarantee. I very much support multiple containers - and the ability
of
> >Avalon Framework consumers to write functional, container-independent
> >applications.
> >
> Sentence #1, I believe we are clear. We may not have commuicated it
well
> :-)
> Sentence #2, agree.
I don't believe we are clear. I think the confusion on the list over
these issues (and simply the divergent opinions expressed in replies to
this email) make it clear that there is quite a lack of clarity on the
component/container contract. This should be clarified and documented.
That's not horrible - it's the standard process of software design.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Single Avalon Implementation yes/no/why/how ( Re: CVS organization )
Posted by "Noel J. Bergman" <no...@devtech.com>.
> We do have a definition :-
> http://jakarta.apache.org/avalon/framework/reference-the-lifecycle.html
> I do accept that docs could be improved.
I believe that is Peter's point: a recognition that Java interfaces alone do
not define the entirety of the programming contract. So as people begin to
focus again on cleaning things up, the contract needs to be (more) fully
documented for the benefit both of container users and container authors.
> > However the [Context] contract is clearly incomplete -
> > without some sort of definition of container-common
> > context objects and their keys no one can use the
> > Context in a container independent way.
> Context is a base for [ServletContext], MailetContext,
> BeanContext (written for EOB), BlahContext. Some of
> them may offer a 'get root dir' feature, some may not.
> Do we encode all permutations for Servlets, Mailets,
> Beans, Blocks, MerlinApps in the same file?
> The point is that Context is deliberately vague.
> Maybe we should have a single additional context method called
> getContainer().
Does it make sense to have some notion of a "context domain", such that we
can find out what domains are supported by a Context? And even documenting
that some things are not part of a contract is valuable. What is not useful
is just leaving everything undefined.
I look at it this way. Context is a fairly abstract base class. But due to
the design of the Frameworks, it is also the access point to the
functionality of its subclasses. So we look for design patterns that can
help us out with this seeming conflict. We already know what to do when
functionality is statically embodied by extend/implement. In the case of
keyed data, perhaps having keys that tell us about contractually defined
keysets would be helpful.
Do you not see a value to an implementor having guidance for how to publish
a common notion, or a client knowing how to look for a common notion? From
my perspective, the goal is to ensure that if a semantic is provided, it is
provided in a common fashion.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Single Avalon Implementation yes/no/why/how ( Re: CVS organization
)
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>Better to concentrate on our core product -> Avalon Framework's
>>interfaces.
>>
>>Embrace the multi-container world!!
>>
>>
>
>The "interfaces define everything" mentality is something that some
>consumers of Avalon (myself included) find troubling. Avalon Framework
>needs to (and in quite a few cases does) include conceptual
>documentation that goes beyond the interfaces.
>
>Interfaces do not define anything save interfaces. It's the contracts
>behind those interfaces that matter. Without the contracts, the
>interfaces are meaningless.
>
>Consider an Avalon Framework with all the lifecycle interfaces, but no
>lifecycle definition. It would be useless - containers would be able to
>implement lifecycle methods in any order they desired. You couldn't
>write a container-independent application using such an Avalon
>Framework. It is the lifecycle contract that is fundamental.
>
We do have a definition :-
http://jakarta.apache.org/avalon/framework/reference-the-lifecycle.html
I do accept that docs could be improved.
>In addition, by focusing on the contract it is most easy to see
>inadequacies in the framework. For example, the Context interface is
>sufficient for the needs of consumer apps. While it might be nice to
>have some syntactic sugar as in the Phoenix Block Context, it isn't
>strictly necessary. However the contract is clearly incomplete -
>without some sort of definition of container-common context objects and
>their keys no one can use the Context in a container independent way.
>
It may be that there are some similarities between Phoenix and Merlin.
But when coarse grained containers #3 thru #8 arrive, we will look
pretty daft having such a constraining single design for component
lacing. People are going to surprise us with containers. We'll look
short sighted if we fix abstractions for miriads of containers now.
>For example, James, which is a pretty simple app from an Avalon
>perspective, would not be able to run in any random Avalon container
>that implemented the current Avalon Framework. That's because James
>needs the application home directory to resolve some of the file URLs.
>But since the key ("app.home") and the semantic meaning associated with
>the value returned (the application home as a File object) are not
>defined as part of the contract, a random container doesn't need to
>provide this. As I understand it Phoenix and Merlin both provide this,
>but it is not laid out explicitly in the Framework.
>
This is because Context is a base for ServletContext (the A-F design not
yet written), MailetContext, BeanContext (written for EOB), BlahContext.
Some of them may offer a 'get root dir' feature, some may not. Do we
encode all permutations for Servlets, Mailets, Beans, Blocks, MerlinApps
in the same file? I think not. Anyone can code a component that can
implements one or all of the A-F interfaces, and is extended by say two
subclasses (also comps). e.g.
abstract class FooDaemon implements Startable, Runnable,
Contextualizable {
Thread thread;
File rootDir;
// from A-F Startable
void start() {
thread = new Thread(this);
thread.start();
}
// from A-F Startable
void stop() {
thread.stop();
}
}
class PhoenixFooDaemon extends FooDaemon {
// from A-F Contextualizable
void contextualize(Context context) {
rootDir = ((BlockContext) context).getRootDir();
}
}
class EOBFooDaemon extends FooDaemon {
// from A-F Contextualizable
void contextualize(Context context) {
rootDir = ((BeanContext) context).getRootDir();
}
}
With the above design, you interoperability with Phoenix and EOB (a .Net
Remoting inspired app server I work on). Replace the word 'EOB' with
JAMES (one day?), or Merlin, or Catalina's internals (one day?).
Containers are all different. They use differnet cop-lacing, config and
context.
The point is that Context is deliberately vague. Either we define a
massive hierarchy of Context interfaces in the A-F package (and curse
ourselves at our liesure over the years), or we leave the context to the
container in question. Phoenix and Merlin are just two containers.
They are not going to be the last 'coarse grained application server'
containers.
Apart from anything else, it was voted on before that Merlin include the
tiny Phoenix-Client jar in it's client API classloader and honors
BlockContext as is (if it wanted to be compatible with Phoenix).
>I'd argue that a standard, minimal set of keys/object should be part of
>the Context contract. Otherwise the Context interface is fairly useless
>as part of framework since every container would provide a purely custom
>set of keys/values. Thus any code written that implemented
>Contextualizable would be implicitly container dependent.
>
You can go for that if you like. Code something that is adaptive and
used the primitive get() mechanism.
Maybe we should have a single additional context method called
getContainer(). It returns "Phoenix 4.0.2" where that were true. Or
maybe a method called isCompatibleWith("Phoenix 4.x")
The point is that deciding
>The only way to get a truly multi-container world is precisely to be
>crystal clear about what the Avalon Framework does and does not
>guarantee. I very much support multiple containers - and the ability of
>Avalon Framework consumers to write functional, container-independent
>applications.
>
Sentence #1, I believe we are clear. We may not have commuicated it well :-)
Sentence #2, agree.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Single Avalon Implementation yes/no/why/how ( Re: CVS organization
)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Very well said.
We had already started defining these keys, but somehow it just stopped
IIRC. It's time now that we soon restart that discussion and come to a
definition.
And eventually define the metadata stuff, that really can be a good
contract, and decide on the container testsuite for framework contract
conformance check.
Peter M. Goldstein wrote:
> All,
>
>
>>I do not believe it is necessary to make the containers we have
>
> compatible
>
>>at anything other than
>>Avalon-Framework-Interface level. If we strive for compatibility on
>>component-lacing (XML,
>>properties, whatever) we will find some other team does not honor the
>>chosen lacing team an
>>delivers a container with a twist. This could be BEA, Pramati, JBoss,
>>Catalina, OpenEJB, Lutris.
>>It could be some University in Bangalore or Manila. We cannot contain
>
> the
>
>>container landscape;
>>we'd be foolish to try. There are thing people are imagining now that
>>will impress the socks off
>>us when released.
>>
>>Better to concentrate on our core product -> Avalon Framework's
>>interfaces.
>>
>>Embrace the multi-container world!!
>
>
> The "interfaces define everything" mentality is something that some
> consumers of Avalon (myself included) find troubling. Avalon Framework
> needs to (and in quite a few cases does) include conceptual
> documentation that goes beyond the interfaces.
>
> Interfaces do not define anything save interfaces. It's the contracts
> behind those interfaces that matter. Without the contracts, the
> interfaces are meaningless.
>
> Consider an Avalon Framework with all the lifecycle interfaces, but no
> lifecycle definition. It would be useless - containers would be able to
> implement lifecycle methods in any order they desired. You couldn't
> write a container-independent application using such an Avalon
> Framework. It is the lifecycle contract that is fundamental.
>
> In addition, by focusing on the contract it is most easy to see
> inadequacies in the framework. For example, the Context interface is
> sufficient for the needs of consumer apps. While it might be nice to
> have some syntactic sugar as in the Phoenix Block Context, it isn't
> strictly necessary. However the contract is clearly incomplete -
> without some sort of definition of container-common context objects and
> their keys no one can use the Context in a container independent way.
>
> For example, James, which is a pretty simple app from an Avalon
> perspective, would not be able to run in any random Avalon container
> that implemented the current Avalon Framework. That's because James
> needs the application home directory to resolve some of the file URLs.
> But since the key ("app.home") and the semantic meaning associated with
> the value returned (the application home as a File object) are not
> defined as part of the contract, a random container doesn't need to
> provide this. As I understand it Phoenix and Merlin both provide this,
> but it is not laid out explicitly in the Framework.
>
> I'd argue that a standard, minimal set of keys/object should be part of
> the Context contract. Otherwise the Context interface is fairly useless
> as part of framework since every container would provide a purely custom
> set of keys/values. Thus any code written that implemented
> Contextualizable would be implicitly container dependent. There may be
> other ways to address this problem, and that's what I'd like to see
> discussed. This issue is obvious when one thinks about the contract,
> but is invisible when just considering the interface.
>
> This is only one Avalon Framework issue among a number that need to be
> discussed, clarified, and resolved. Clarification of these issues will
> make it easier, not harder, to develop new containers.
>
> The only way to get a truly multi-container world is precisely to be
> crystal clear about what the Avalon Framework does and does not
> guarantee. I very much support multiple containers - and the ability of
> Avalon Framework consumers to write functional, container-independent
> applications.
>
--
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: Framework and Contracts (was RE: Single Avalon Implementation yes/no/why/how ( Re: CVS organization ) )
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Berin,
> > The "interfaces define everything" mentality is something that some
> > consumers of Avalon (myself included) find troubling. Avalon
> > Framework
> > needs to (and in quite a few cases does) include conceptual
> > documentation that goes beyond the interfaces.
>
> Does the "Developing with Avalon" documentation fall short in this
> respect?
It's a really good start. It was very helpful to me personally when I
first got into Avalon. But some niggling details still need to be
worked out and added to the framework and then added to the docs. I'd
also like to see contracts defined more formally, rather than in what is
an essentially teaching-focused document.
> > Interfaces do not define anything save interfaces. It's the
contracts
> > behind those interfaces that matter. Without the contracts, the
> > interfaces are meaningless.
>
> The interfaces are the points of contract that can be represented in
> code. So it is *part* of the contract, but not the full contract.
> Your point on contracts is well taken, and I have put forth much
> effort to make the contracts explicit.
Yep. I wasn't implying that there hasn't been any focus on contracts.
I just wanted to draw the current discussion back to the fundamentals
and ensure that everyone understood the crucial point (interface <<
contract).
> > Consider an Avalon Framework with all the lifecycle interfaces, but
no
> > lifecycle definition. It would be useless - containers would
> > be able to
> > implement lifecycle methods in any order they desired. You couldn't
> > write a container-independent application using such an Avalon
> > Framework. It is the lifecycle contract that is fundamental.
>
> That is the way that Avalon *used* to be. The only contract was that
> initialize() was the last method called. I took the time to work
> with Fede to define the contracts we have now.
I didn't know that. :) I'm much happier with how things are today.
> > This is only one Avalon Framework issue among a number that need to
be
> > discussed, clarified, and resolved. Clarification of these
> > issues will
> > make it easier, not harder, to develop new containers.
>
> Right. Keep in mind the chicken and the egg issue. How do we know
what
> needs to be commonly implemented unless we have multiple containers
> to work with.
Agreed. This is an iterative process. Right now we have a few
containers. We can focus on these containers and talk about their
commonalities and divergences. Other containers can also be considered.
The developers can turn their attention to these issues and start a
productive discussion.
> > The only way to get a truly multi-container world is precisely to be
> > crystal clear about what the Avalon Framework does and does not
> > guarantee. I very much support multiple containers - and the
> > ability of
> > Avalon Framework consumers to write functional,
container-independent
> > applications.
>
> Exactly. What I proposed in another thread is the creation of
> a Container test suite that will work a container to determine if
> it meets the minimum requirements for Avalon container compliance.
> Again, remember the chicken and the egg issue. Now that we have
> three robust containers, we can shore up the weaknesses in the
> contracts.
Yep, sounds like a good plan.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Framework and Contracts (was RE: Single Avalon Implementation yes/no/why/how ( Re: CVS organization ) )
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Peter M. Goldstein [mailto:peter_m_goldstein@yahoo.com]
>
> All,
>
> The "interfaces define everything" mentality is something that some
> consumers of Avalon (myself included) find troubling. Avalon
> Framework
> needs to (and in quite a few cases does) include conceptual
> documentation that goes beyond the interfaces.
Does the "Developing with Avalon" documentation fall short in this
respect?
> Interfaces do not define anything save interfaces. It's the contracts
> behind those interfaces that matter. Without the contracts, the
> interfaces are meaningless.
The interfaces are the points of contract that can be represented in
code. So it is *part* of the contract, but not the full contract.
Your point on contracts is well taken, and I have put forth much
effort to make the contracts explicit.
> Consider an Avalon Framework with all the lifecycle interfaces, but no
> lifecycle definition. It would be useless - containers would
> be able to
> implement lifecycle methods in any order they desired. You couldn't
> write a container-independent application using such an Avalon
> Framework. It is the lifecycle contract that is fundamental.
That is the way that Avalon *used* to be. The only contract was that
initialize() was the last method called. I took the time to work
with Fede to define the contracts we have now.
> In addition, by focusing on the contract it is most easy to see
> inadequacies in the framework. For example, the Context interface is
> sufficient for the needs of consumer apps. While it might be nice to
> have some syntactic sugar as in the Phoenix Block Context, it isn't
> strictly necessary. However the contract is clearly incomplete -
> without some sort of definition of container-common context
> objects and
> their keys no one can use the Context in a container independent way.
Agreed. We had some discussion on this a while back. We need
to formalize and write down the results of our conversations.
> For example, James, which is a pretty simple app from an Avalon
> perspective, would not be able to run in any random Avalon container
> that implemented the current Avalon Framework. That's because James
> needs the application home directory to resolve some of the file URLs.
> But since the key ("app.home") and the semantic meaning
> associated with
> the value returned (the application home as a File object) are not
> defined as part of the contract, a random container doesn't need to
> provide this. As I understand it Phoenix and Merlin both
> provide this,
> but it is not laid out explicitly in the Framework.
Right. Fortress also supports this if I recall correctly. That would
be one of the values.
> I'd argue that a standard, minimal set of keys/object should
> be part of
> the Context contract. Otherwise the Context interface is
> fairly useless
> as part of framework since every container would provide a
> purely custom
> set of keys/values. Thus any code written that implemented
> Contextualizable would be implicitly container dependent.
> There may be
> other ways to address this problem, and that's what I'd like to see
> discussed. This issue is obvious when one thinks about the contract,
> but is invisible when just considering the interface.
Right.
> This is only one Avalon Framework issue among a number that need to be
> discussed, clarified, and resolved. Clarification of these
> issues will
> make it easier, not harder, to develop new containers.
Right. Keep in mind the chicken and the egg issue. How do we know what
needs to be commonly implemented unless we have multiple containers
to work with.
> The only way to get a truly multi-container world is precisely to be
> crystal clear about what the Avalon Framework does and does not
> guarantee. I very much support multiple containers - and the
> ability of
> Avalon Framework consumers to write functional, container-independent
> applications.
Exactly. What I proposed in another thread is the creation of
a Container test suite that will work a container to determine if
it meets the minimum requirements for Avalon container compliance.
Again, remember the chicken and the egg issue. Now that we have
three robust containers, we can shore up the weaknesses in the
contracts.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Single Avalon Implementation yes/no/why/how ( Re: CVS organization )
Posted by "Noel J. Bergman" <no...@devtech.com>.
Peter,
I agree with you that the mere presence and shape of an Java interface is
not a sufficient contract. That provides syntax, not semantics. So the
documentation should be expanded to document necessary behavior. And I
don't think that Paul really meant to say that just the shape of the
interface was sufficient. I suspect that he implicitly includes semantics
that are documented for that interface. You just want to make sure that
there are a lot more documented semantics. And I agree with you that
semantics cannot be left undefined within the Framework contracts if they
are to be portable.
You and I ran into a specific problem having to do with undocumented
semantics involving thread pooling. I am pleased that JSR 166 has agreed to
document the semantics in that forthcoming standard. Which is not to say
that thread pooling should be mandated, but I simply point out another
aspect of documenting interface semantics.
I suggest that nothing be mandated for ALL containers that cannot be
expressed within J2ME. If one wants to talk about adding sets that must be
supported IF the environment is J2SE or J2EE, that's fine. But I think that
at a minimum, J2ME containers must be permitted. I haven't looked at its
code, but following up on your thought that Tweety compliance should be part
of the test case, is Tweety J2ME compliant?
Along related lines, I am still unsure of everyone's intentions regarding
meta-info. I'd like more clarity there, especially on what it requires from
a container. I think that it is necessary to allow lightweight container
implementations, even if heavyweight containers turn out to be the most
useful. So if meta-info content must be honored by container authors,
that's one thing. In that role it is basically expanded Javadocs. But I
would be leery about imposing a requirement that containers must machine
process the information. It might be nice in a heavyweight application
platform, but not mandated. Some things are just going to be container
specific, and they should be, because they are not part of the common
contract.
And, of course, we need to understand what all of this would mean in terms
of any required changes to existing client code. In the eagerness to move
forward, there is all of the existing client code to keep in mind. Needless
to say, I feel that existing client code should be supported, as a normative
statement.
> The only way to get a truly multi-container world is precisely to be
> crystal clear about what the Avalon Framework does and does not
> guarantee.
:-)
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Single Avalon Implementation yes/no/why/how ( Re: CVS organization )
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
All,
> I do not believe it is necessary to make the containers we have
compatible
> at anything other than
> Avalon-Framework-Interface level. If we strive for compatibility on
> component-lacing (XML,
> properties, whatever) we will find some other team does not honor the
> chosen lacing team an
> delivers a container with a twist. This could be BEA, Pramati, JBoss,
> Catalina, OpenEJB, Lutris.
> It could be some University in Bangalore or Manila. We cannot contain
the
> container landscape;
> we'd be foolish to try. There are thing people are imagining now that
> will impress the socks off
> us when released.
>
> Better to concentrate on our core product -> Avalon Framework's
> interfaces.
>
> Embrace the multi-container world!!
The "interfaces define everything" mentality is something that some
consumers of Avalon (myself included) find troubling. Avalon Framework
needs to (and in quite a few cases does) include conceptual
documentation that goes beyond the interfaces.
Interfaces do not define anything save interfaces. It's the contracts
behind those interfaces that matter. Without the contracts, the
interfaces are meaningless.
Consider an Avalon Framework with all the lifecycle interfaces, but no
lifecycle definition. It would be useless - containers would be able to
implement lifecycle methods in any order they desired. You couldn't
write a container-independent application using such an Avalon
Framework. It is the lifecycle contract that is fundamental.
In addition, by focusing on the contract it is most easy to see
inadequacies in the framework. For example, the Context interface is
sufficient for the needs of consumer apps. While it might be nice to
have some syntactic sugar as in the Phoenix Block Context, it isn't
strictly necessary. However the contract is clearly incomplete -
without some sort of definition of container-common context objects and
their keys no one can use the Context in a container independent way.
For example, James, which is a pretty simple app from an Avalon
perspective, would not be able to run in any random Avalon container
that implemented the current Avalon Framework. That's because James
needs the application home directory to resolve some of the file URLs.
But since the key ("app.home") and the semantic meaning associated with
the value returned (the application home as a File object) are not
defined as part of the contract, a random container doesn't need to
provide this. As I understand it Phoenix and Merlin both provide this,
but it is not laid out explicitly in the Framework.
I'd argue that a standard, minimal set of keys/object should be part of
the Context contract. Otherwise the Context interface is fairly useless
as part of framework since every container would provide a purely custom
set of keys/values. Thus any code written that implemented
Contextualizable would be implicitly container dependent. There may be
other ways to address this problem, and that's what I'd like to see
discussed. This issue is obvious when one thinks about the contract,
but is invisible when just considering the interface.
This is only one Avalon Framework issue among a number that need to be
discussed, clarified, and resolved. Clarification of these issues will
make it easier, not harder, to develop new containers.
The only way to get a truly multi-container world is precisely to be
crystal clear about what the Avalon Framework does and does not
guarantee. I very much support multiple containers - and the ability of
Avalon Framework consumers to write functional, container-independent
applications.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Single Avalon Implementation yes/no/why/how ( Re: CVS organization )
Posted by Paul Hammant <pa...@yahoo.com>.
> > But I also don't have a solution at hand; if we cannot come to a single
> > implementation, probably it's because we still don't know how to do it.
>
> Yes, that's possible.
> Now, we could try to make a single implementation where all agree on
> and only if this does not work - we can start several ones.
> My perception is, that it is possible to reach a wide consensus on
> this.
(Vote) -1
I do not believe it is necessary to make the containers we have compatible at anything other than
Avalon-Framework-Interface level. If we strive for compatibility on component-lacing (XML,
properties, whatever) we will find some other team does not honor the chosen lacing team an
delivers a container with a twist. This could be BEA, Pramati, JBoss, Catalina, OpenEJB, Lutris.
It could be some University in Bangalore or Manila. We cannot contain the container landscape;
we'd be foolish to try. There are thing people are imagining now that will impress the socks off
us when released.
Better to concentrate on our core product -> Avalon Framework's interfaces.
Embrace the multi-container world!!
- Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Single Avalon Implementation yes/no/why/how ( Re: CVS organization )
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi wrote:
>
> Carsten Ziegeler wrote:
> > Nicola Ken Barozzi wrote:
> >
> [...]
> >> 3) The containers that are in the works, as cool as they seem to be,
> >>are still scratchpad stuff, and thus should be clearly put in a place
> >>where it's clear to all. Current structure is really confusing, and
> >>releases are a very important part of our system.
> >>
> >
> > And personally I'm still wondering if we really need different
> > implementations
> > with different features. But this is another topic, we should discuss
> > when it is time.
>
> Actually, I think it's time, and as for the topic, I've made a new one ;-)
>
Great :)
> It can be that we will eventually come to a single design, and in fact
> Merlin and Fortress developers have worked well on this. It seems to be
> doable, and probably it hasn't been so near.
>
> But it has to be agreed on by everyone, and everyone has to work on that
> codebase.
Ok.
>
> Phoenix is released, proved and really stable. Think that someone has
> even gotten James working on a C# based JVM (ok, technically it doesn't
> mean much but it's amusing that he tried it on James).
> Merlin and Fortress are new promising designs, that actually have been
> collaborating and partially converging.
>
> Technically it seems sensible that there be one framework and more
> possible implementations. Community-wise, I'm not so sure.
> Think for example about a Cocoon framework and multiple implementations.
> It's even hard to immagine.
>
Yes, this is exactly the point I'm also thinking about. Of course, the
concepts of Avalon are "generic" so that it is possible to have different
implementations for a framework. But personally, I doubt that this
is a good idea *if* the implementations offer different features.
If the implementations would only differ in performance, memory usage
etc - I would say, ok this makes sense and I can choose the
implementation which fits best my enironment (server application,
desktop application etc.)
> I still don't see major needs of having different implementations. Maybe
> different running environments, different profiles, but one
> implementation, as Cocoon has Serlet, CLI, etc running modes.
>
> But I also don't have a solution at hand; if we cannot come to a single
> implementation, probably it's because we still don't know how to do it.
Yes, that's possible.
Now, we could try to make a single implementation where all agree on
and only if this does not work - we can start several ones.
My perception is, that it is possible to reach a wide consensus on
this.
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Project Hierarchy
Posted by Leif Mortenson <le...@tanukisoftware.com>.
>
>
>>> - It can probably be argued that Instrument might make an
>>>
>>>
>>excellent
>>
>>
>>> candidate for Avalon Commons. It is some top notch code.
>>>
>>>
>>What is Avalon Commons in your view?
>>
>>
>
>Umm, I meant Apache Commons. I.e. Instrument gets a more broad
>audience than just Avalon. I don't want to loose Leif, though ;).
>
instrument is basically dependency free. There is the exception of the
AbstractLogEnabledInstrumentable class. The other two packages contain
dependencies. But could be reworked a bit to live over there. How would
that work? Would I need to change the dependencies to use commons
jars. Or make use of released versions of the Avalon jars?
Instrument-Manager just uses framework, instrument and altrmi.
Instrument-Client is stand alone, so its dependencies are not so
critical. What
it uses can be reworked without affecting existing users.
But overall, I like Avalon. :-) And would still stay. Trying to keep
up over on commons
in addition would also end up taking more more of my time. So if it
makes sense,
leaving them here would be nice :-)
>>> - We may want to make the core Instrument library part of Avalon
>>> framework (discussion must occur first).
>>>
>>>
>>+1
>>
>>
>
>Let's see the feelings on the list. before we go too far in this
>direction. If we move Instrument to Apache Commons, then we would
>have a dependency of Framework on Instrument, or an understanding
>that Instrument is a supported option for components. The nice
>thing about Instrument is that if a component uses Instrument but
>the container does not support it, then the component is not broken.
>
I had thought about moving instrument into framework before. I view the
core classes
as being on the same level as the logging classes. Kind of a set of
base utility classes.
Like logging, the actual implementation is separated out and exists
right now in the
instrument-manager classes. A different implementation could be written
at any time
and all of the components using the instrument classes would still work
with the new
manager implementation.
I think it would be simpler for users to add instrument to framework
than to add a
dependency to framework on instrument. The drawback is that instrument
would lose
the ability to be used outside of avalon. I doubt that is an issue with
any users right now
however as the instrument-manager requires avalon classes.
Note that components always require the core instrument classes to be
present. They
will work whether or not they are registered with an instrument-manager
however.
This was done to ease the implementation into a world with lots of
existing containers.
Of course I think that any good container should have the goal of supporting
instrumentation :-)
Cheers,
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Project Hierarchy
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Noel J. Bergman wrote:
> Nicola,
>
> OK. So what you are saying is that Excalibur, in being "eliminated" as an
> individual entity, has its Avalon-specific classes divided into two areas:
> Container and Components, depending upon the type of class.
Correct.
Also, since Excalibur contains also non-Avalon specific stuff, that will
go in some Commons.
> That's the entirety of our disconnect?
I think we really agree, it's just a terminology-understanding thing.
> --- Noel
>
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Thursday, November 21, 2002 16:08
> To: Avalon Developers List
> Subject: Re: Avalon Project Hierarchy
>
> Noel J. Bergman wrote:
>
>>>The only thing that could change is the placement of Excalibur stuff in
>>>Commons, avalon-components or scratchpad.
>>
>>I'm sorry, Nicola. I know I raised this question yesterday, and I'm still
>>not understanding this particular change.
>
>
> No, I'm sorry I was not able to explain it clearly enough.
> Hmmm, I'm seeing some ASCII art, cool!
>
>
>>Looking at a "layered" view of Avalon:
>>
>> Model Current Sub-Project Proposed
>
> Sub-Project
>
> +---------------------------+ ------------------- --------------------
>
>> | Avalon Applications | Applications Components
>> +------------------------+--+
>> | Avalon Components | | Components Components
>> +=====================+--| |
>> | Avalon Container | | | Phoenix, et al Container
>> +---------------------+ | |
>> | Avalon ContainerKit | | | Excalibur Container
>> +=====================+-----|
>> | Avalon Frameworks | Frameworks Frameworks
>> +---------------------------+
>>
>>This terrible ASCII graphic
>
>
> I like it :-)
>
> Just change it to
>
> Model Current Sub-Project Proposed Sub-Project
> +---------------------------+ ----------------- --------------------
> | Avalon Applications | Applications Components or Apps
> +------------------------+--+
> | | | Excalibur stuff Components
> | Avalon Components | | +Cornerstone
> | | | ^^^^^^^^^^^^^^^^^^^^^
> +=====================+--| |
> | | | | Phoenix, et al
> | Avalon Container | | | (Excalibur) Container
> | | | | ^^^^^^^^^^^^^^^^^^^^^
> +=====================+-----|
> | Avalon Framework | Framework Framework
> +---------------------------+
>
>
>
>>is intended to show that everything sees
>>interfaces published by Avalon Frameworks, but (ideally) Components see
>
> only
>
>>Frameworks (and other Components) as exposed through the Container, and
>>Applications are (sets of) Components & configuration.
>>
>>I could see Avanon-specific Excalibur code rolled into the Container
>>sub-project that Stefano proposes, which is what I've illustrated above.
>
>
> --
> 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>
>
>
>
--
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: Avalon Project Hierarchy
Posted by "Noel J. Bergman" <no...@devtech.com>.
Nicola,
OK. So what you are saying is that Excalibur, in being "eliminated" as an
individual entity, has its Avalon-specific classes divided into two areas:
Container and Components, depending upon the type of class.
That's the entirety of our disconnect?
--- Noel
-----Original Message-----
From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
Sent: Thursday, November 21, 2002 16:08
To: Avalon Developers List
Subject: Re: Avalon Project Hierarchy
Noel J. Bergman wrote:
>>The only thing that could change is the placement of Excalibur stuff in
>>Commons, avalon-components or scratchpad.
>
> I'm sorry, Nicola. I know I raised this question yesterday, and I'm still
> not understanding this particular change.
No, I'm sorry I was not able to explain it clearly enough.
Hmmm, I'm seeing some ASCII art, cool!
> Looking at a "layered" view of Avalon:
>
> Model Current Sub-Project Proposed
Sub-Project
>
+---------------------------+ ------------------- --------------------
> | Avalon Applications | Applications Components
> +------------------------+--+
> | Avalon Components | | Components Components
> +=====================+--| |
> | Avalon Container | | | Phoenix, et al Container
> +---------------------+ | |
> | Avalon ContainerKit | | | Excalibur Container
> +=====================+-----|
> | Avalon Frameworks | Frameworks Frameworks
> +---------------------------+
>
> This terrible ASCII graphic
I like it :-)
Just change it to
Model Current Sub-Project Proposed Sub-Project
+---------------------------+ ----------------- --------------------
| Avalon Applications | Applications Components or Apps
+------------------------+--+
| | | Excalibur stuff Components
| Avalon Components | | +Cornerstone
| | | ^^^^^^^^^^^^^^^^^^^^^
+=====================+--| |
| | | | Phoenix, et al
| Avalon Container | | | (Excalibur) Container
| | | | ^^^^^^^^^^^^^^^^^^^^^
+=====================+-----|
| Avalon Framework | Framework Framework
+---------------------------+
> is intended to show that everything sees
> interfaces published by Avalon Frameworks, but (ideally) Components see
only
> Frameworks (and other Components) as exposed through the Container, and
> Applications are (sets of) Components & configuration.
>
> I could see Avanon-specific Excalibur code rolled into the Container
> sub-project that Stefano proposes, which is what I've illustrated above.
--
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: Avalon Project Hierarchy
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Noel J. Bergman wrote:
>>The only thing that could change is the placement of Excalibur stuff in
>>Commons, avalon-components or scratchpad.
>
> I'm sorry, Nicola. I know I raised this question yesterday, and I'm still
> not understanding this particular change.
No, I'm sorry I was not able to explain it clearly enough.
Hmmm, I'm seeing some ASCII art, cool!
> Looking at a "layered" view of Avalon:
>
> Model Current Sub-Project Proposed Sub-Project
> +---------------------------+ ------------------- --------------------
> | Avalon Applications | Applications Components
> +------------------------+--+
> | Avalon Components | | Components Components
> +=====================+--| |
> | Avalon Container | | | Phoenix, et al Container
> +---------------------+ | |
> | Avalon ContainerKit | | | Excalibur Container
> +=====================+-----|
> | Avalon Frameworks | Frameworks Frameworks
> +---------------------------+
>
> This terrible ASCII graphic
I like it :-)
Just change it to
Model Current Sub-Project Proposed Sub-Project
+---------------------------+ ----------------- --------------------
| Avalon Applications | Applications Components or Apps
+------------------------+--+
| | | Excalibur stuff Components
| Avalon Components | | +Cornerstone
| | | ^^^^^^^^^^^^^^^^^^^^^
+=====================+--| |
| | | | Phoenix, et al
| Avalon Container | | | (Excalibur) Container
| | | | ^^^^^^^^^^^^^^^^^^^^^
+=====================+-----|
| Avalon Framework | Framework Framework
+---------------------------+
> is intended to show that everything sees
> interfaces published by Avalon Frameworks, but (ideally) Components see only
> Frameworks (and other Components) as exposed through the Container, and
> Applications are (sets of) Components & configuration.
>
> I could see Avanon-specific Excalibur code rolled into the Container
> sub-project that Stefano proposes, which is what I've illustrated above.
--
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: Avalon Project Hierarchy
Posted by "Noel J. Bergman" <no...@devtech.com>.
> The only thing that could change is the placement of Excalibur stuff in
> Commons, avalon-components or scratchpad.
I'm sorry, Nicola. I know I raised this question yesterday, and I'm still
not understanding this particular change.
Looking at a "layered" view of Avalon:
Model Current Sub-Project Proposed Sub-Project
+---------------------------+ ------------------- --------------------
| Avalon Applications | Applications Components
+------------------------+--+
| Avalon Components | | Components Components
+=====================+--| |
| Avalon Container | | | Phoenix, et al Container
+---------------------+ | |
| Avalon ContainerKit | | | Excalibur Container
+=====================+-----|
| Avalon Frameworks | Frameworks Frameworks
+---------------------------+
This terrible ASCII graphic is intended to show that everything sees
interfaces published by Avalon Frameworks, but (ideally) Components see only
Frameworks (and other Components) as exposed through the Container, and
Applications are (sets of) Components & configuration.
I could see Avanon-specific Excalibur code rolled into the Container
sub-project that Stefano proposes, which is what I've illustrated above.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Project Hierarchy
Posted by Paul Hammant <pa...@yahoo.com>.
>
> > I also object to the word "new" in any product name. I also object to the word "stable" in
> product
> > names.
> >
> > Call it ZContainer or something...
>
> Paul, are you being serious?!?
Ahh "avalon-newstablecontainer" is a place holder for another name. I see.
- Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Project Hierarchy
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote:
> -1 (vote) for me.
>
> This is too much revolution when code is being used by real people in real companies...
* framework is already there
* components is already there, and it's called Cornerstone
* scratchpad has nothing to do with production code
* phoenix is still there
The only thing that could change is the placement of Excalibur stuff in
Commons, avalon-components or scratchpad.
What revolution are you talking about?
> I also object to the word "new" in any product name. I also object to the word "stable" in product
> names.
>
> Call it ZContainer or something...
Paul, are you being serious?!?
> - Paul
>
> --- Carsten Ziegeler <cz...@s-und-n.de> wrote: >
>
>>Nicola Ken Barozzi:
>>
>>>So we will have
>>>
>>> * avalon-framework
>>> * avalon-components
>>> * avalon-scratchpad
>>> * avalon-phoenix
>>> * avalon-newstablecontainer
>>>
>>
>>+1 for this and all the implications mentioned in the mail
>>as well (I don't want to include all of the mail here only
>>to say, I agree).
>>
>>Carsten
--
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: Avalon Project Hierarchy
Posted by "Noel J. Bergman" <no...@devtech.com>.
> -1 (vote) for me.
> This is too much revolution when code is being used by real people in real
companies...
Paul,
I agree with your concern, and raised it earlier. Somehow Nicola thinks
that he can resolve the packaging issues. I suggest that proposals for
re-factoring include information related to compatibility with existing
systems.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Project Hierarchy
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Paul Hammant wrote:
...
> And each container would continue to distribute what the hack it wants?
^^^^^^
heck
> Please, let's not stumble on details, and let's be constructive.
--
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: Avalon Project Hierarchy
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote:
>>We use the code in a real company and I don't see any real
>>impact for us by these changes directly.
>
>
> Kew;
>
>
>>Of course, there
>>should be some "compatibility packaging", when it comes
>>to the distribution, so that you don't have to download
>>35 different jars to get the same as you now get by downloading
>>one package.
>
> Nobody downloads 35 different jars to begin a project. They download one container (which bundles
> some jars), then add others as and when. We're all doing Agilesque development these days? If
> yes, then it is possible we do not even start with the container.
Wawawawait... where did we start this 35 different jars issue?
Avalon Components would package each component separately *exactly* like
Exaclibur components for example.
And each container would continue to distribute what the hack it wants?
Please, let's not stumble on details, and let's be constructive.
--
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: Avalon Project Hierarchy
Posted by "Noel J. Bergman" <no...@devtech.com>.
There is clearly a tension between wanting to evolve and dance nimbly, and
needing to support the installed base. However, solutions to problems are
not binary and mutually exclusive. If there are multiple conflicting
interests, then the constructive thing is to look for solutions that
accommodate all of those interests as best as possible. Such solutions
should, IMO, be as simple and elegant as possible.
>From what I have seen from archived discussions, one of the things that
everyone needs to bring to the table now is a willingness to look for viable
solutions to problems, not just raise objections to a particular proposal.
If someone sees a proposed solution that they don't like, great. But it is
important to recognize the problems that the possible flawed solution was
proposed to address, and propose alternative solutions.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon Project Hierarchy
Posted by Paul Hammant <pa...@yahoo.com>.
> We use the code in a real company and I don't see any real
> impact for us by these changes directly.
Kew;
> Of course, there
> should be some "compatibility packaging", when it comes
> to the distribution, so that you don't have to download
> 35 different jars to get the same as you now get by downloading
> one package.
Nobody downloads 35 different jars to begin a project. They download one container (which bundles
some jars), then add others as and when. We're all doing Agilesque development these days? If
yes, then it is possible we do not even start with the container.
- Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon Project Hierarchy
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Paul Hammant wrote:
>
> -1 (vote) for me.
>
> This is too much revolution when code is being used by real
> people in real companies...
We use the code in a real company and I don't see any real
impact for us by these changes directly. Of course, there
should be some "compatibility packaging", when it comes
to the distribution, so that you don't have to download
35 different jars to get the same as you now get by downloading
one package.
But that's IMHO a different issue which can be solved later on.
>
> I also object to the word "new" in any product name. I also
> object to the word "stable" in product
> names.
>
Ehm, if you refer to avalon-newstablecontainer than this is
not ment to be the real name, replace "newstablecontainer"
with a name for it, like perhaps merlin or whatever.
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon Project Hierarchy
Posted by Paul Hammant <pa...@yahoo.com>.
-1 (vote) for me.
This is too much revolution when code is being used by real people in real companies...
I also object to the word "new" in any product name. I also object to the word "stable" in product
names.
Call it ZContainer or something...
- Paul
--- Carsten Ziegeler <cz...@s-und-n.de> wrote: >
>
> Nicola Ken Barozzi:
> > So we will have
> >
> > * avalon-framework
> > * avalon-components
> > * avalon-scratchpad
> > * avalon-phoenix
> > * avalon-newstablecontainer
> >
> +1 for this and all the implications mentioned in the mail
> as well (I don't want to include all of the mail here only
> to say, I agree).
>
> Carsten
>
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon Project Hierarchy
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi:
> So we will have
>
> * avalon-framework
> * avalon-components
> * avalon-scratchpad
> * avalon-phoenix
> * avalon-newstablecontainer
>
+1 for this and all the implications mentioned in the mail
as well (I don't want to include all of the mail here only
to say, I agree).
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Project Hierarchy
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>
>>
>>>* Avalon Excalibur gets repurposed to strictly a location
>>
>>for Components.
>>
>>> All support code gets moved to commons (unless the move is already
>>> done with Jakarta commons like in the case of Collections
>>
>>or replaced
>>
>>> by a more robust library like Concurrent).
>>
>>+1 This /could/ become in the future a repository where also outer
>>projects can put components, dunno, but for now it's the only
>>workable
>>solution.
>>I'd call it "Avalon Components", because all these fancy
>>names have some
>>people confused; and when a fancy name project changes what
>>it contains,
>>we are ready for pretty serious misunderstandings. IMHO that is.
>
>
> Ok. Sounds good.
>
>
>>> - It can probably be argued that Instrument might make an
>>> excellent candidate for Avalon Commons. It is some top notch code.
>>
>>What is Avalon Commons in your view?
>
> Umm, I meant Apache Commons. I.e. Instrument gets a more broad
> audience than just Avalon. I don't want to loose Leif, though ;).
;-)
I understand your point.
>>> - We may want to make the core Instrument library part of Avalon
>>> framework (discussion must occur first).
>>
>>+1
>
>
> Let's see the feelings on the list. before we go too far in this
> direction. If we move Instrument to Apache Commons, then we would
> have a dependency of Framework on Instrument, or an understanding
> that Instrument is a supported option for components. The nice
> thing about Instrument is that if a component uses Instrument but
> the container does not support it, then the component is not broken.
Yes, +1 for the discussion on it.
>>>* Avalon Scratchpad is a location for maturing subprojects to grow.
>>
>>+1 the concept, +0 for a separate repository for it.
>
> Think of how Jakarta Commons works. We have "jakarta-commons" and
> "jakarta-commons-scratchpad". It seems to work pretty well for them.
> We should follow their lead as much as possible on that approach.
roger
So we will have
* avalon-framework
* avalon-components
* avalon-scratchpad
* avalon-phoenix
* avalon-newstablecontainer
Seems ok.
>>>* As containers become mature, they move out of Avalon
>>> scratchpad and
>>> become a top level sub-project. I.e. Avalon Fortress and
>>>Avalon Merlin
>>
>>> at the same level as Avalon Phoenix when they are released.
>>
>>+0 Not sure about the direct road: scratchpad -> top level subproject
>> But I have no alternative viable solution.
>
>
> My thing is that we don't want the "Official Container" connotation,
> esp. if a container falls out of favor (i.e. ECM). We want the
> containers to follow the specs, so we might want to come up with
> a container specification test suite to ensure any published
> container follows the core Avalon specifications.
+1000 Works like a charm :-)
--
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: Avalon Project Hierarchy
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> > * Avalon Excalibur gets repurposed to strictly a location
> for Components.
> > All support code gets moved to commons (unless the move is already
> > done with Jakarta commons like in the case of Collections
> or replaced
> > by a more robust library like Concurrent).
>
> +1 This /could/ become in the future a repository where also outer
> projects can put components, dunno, but for now it's the only
> workable
> solution.
> I'd call it "Avalon Components", because all these fancy
> names have some
> people confused; and when a fancy name project changes what
> it contains,
> we are ready for pretty serious misunderstandings. IMHO that is.
Ok. Sounds good.
> > - It can probably be argued that Instrument might make an
> excellent
> > candidate for Avalon Commons. It is some top notch code.
>
> What is Avalon Commons in your view?
Umm, I meant Apache Commons. I.e. Instrument gets a more broad
audience than just Avalon. I don't want to loose Leif, though ;).
> > - We may want to make the core Instrument library part of Avalon
> > framework (discussion must occur first).
>
> +1
Let's see the feelings on the list. before we go too far in this
direction. If we move Instrument to Apache Commons, then we would
have a dependency of Framework on Instrument, or an understanding
that Instrument is a supported option for components. The nice
thing about Instrument is that if a component uses Instrument but
the container does not support it, then the component is not broken.
> > * Avalon Scratchpad is a location for maturing subprojects to grow.
>
> +1 the concept, +0 for a separate repository for it.
Think of how Jakarta Commons works. We have "jakarta-commons" and
"jakarta-commons-scratchpad". It seems to work pretty well for them.
We should follow their lead as much as possible on that approach.
> > * As containers become mature, they move out of Avalon
> scratchpad and
> > become a top level sub-project. I.e. Avalon Fortress and
> Avalon Merlin
> > at the same level as Avalon Phoenix when they are released.
>
> +0 Not sure about the direct road: scratchpad -> top level subproject
> But I have no alternative viable solution.
My thing is that we don't want the "Official Container" connotation,
esp. if a container falls out of favor (i.e. ECM). We want the
containers to follow the specs, so we might want to come up with
a container specification test suite to ensure any published
container follows the core Avalon specifications.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Project Hierarchy
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
> The Avalon project hierarchy has a concept that works, but
> the implementation that doesn't.
roger
<nice-summary/>
> As of right now, everyone seems to be in agreement that Framework is
> at the core. It is by itself. Where the differences in ideas/oppinions
> come is where components and containers go. For that reason, I would
> like to propose the following solution.
>
> * Avalon Framework remains as is. We can look at Avalon 5 later after
> the dust has settled.
+1
> * Avalon Excalibur gets repurposed to strictly a location for Components.
> All support code gets moved to commons (unless the move is already
> done with Jakarta commons like in the case of Collections or replaced
> by a more robust library like Concurrent).
+1 This /could/ become in the future a repository where also outer
projects can put components, dunno, but for now it's the only workable
solution.
I'd call it "Avalon Components", because all these fancy names have some
people confused; and when a fancy name project changes what it contains,
we are ready for pretty serious misunderstandings. IMHO that is.
> - The TestCase and Instrument projects need to be handled as they are
> specific to Avalon.
+1
> - It can probably be argued that Instrument might make an excellent
> candidate for Avalon Commons. It is some top notch code.
What is Avalon Commons in your view?
> - We may want to make the core Instrument library part of Avalon
> framework (discussion must occur first).
+1
> * Avalon Scratchpad is a location for maturing subprojects to grow.
+1 the concept, +0 for a separate repository for it.
> * As containers become mature, they move out of Avalon scratchpad and
> become a top level sub-project. I.e. Avalon Fortress and Avalon Merlin
> at the same level as Avalon Phoenix when they are released.
+0 Not sure about the direct road: scratchpad -> top level subproject
But I have no alternative viable solution.
> * All components in Avalon Cornerstone get merged into Excalibur. This
> means we have to come up with some standard Context name/value pairs
> that always exist--as this is the only reason why most cornerstone
> components require Phoenix.
+1 definately.
> * I am not sure what to do with Avalon Apps. We need to look at the
> possibility of moving them out of Avalon's sphere of responsibility.
> I would have a hard time justifying their existence in an Avalon charter.
> But we may also want to follow the same rules as containers for the
> applications.
Same feeling here.
Thanks Berin, this is good stuff! :-)
--
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: Avalon Project Hierarchy
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Noel J. Bergman wrote:
>>The Avalon project hierarchy has a concept that works, but
>>the implementation that doesn't.
>
> I think I agree with that in concept, but I don't think that there was
> actually disagreement between Nicola and myself at all.
From a conceptual view, we seem to agree, yes.
>>For instance, from the thread "Single Avalon Implementation
>
> yes/no/why/how",
>
>>we have Noel writing:
>
>
>>> * Avalon Excalibur - a major implementation of the
>>> the Frameworks. But not the only possible one.
>>
>
>>And Nicola responding:
>
>
>>>* Excalibur is not a major implementation of the the Framework. It
>>>contains utility stuff to create containers and some
>>>containers itself.
>>
>
>>Which represents some conceptual friction.
>
>
> Nicola's correction / clarification *is* better. Nicola's correction is
> that Excalibur isn't the implementation, but is rather a collection of
> useful code used to implement containers, which (from the perspective of a
> component) is the implementation of Frameworks. And if that isn't what
> Nicola meant, then I apologize and need to re-read his message. :-)
In fact Excalibur -now- is such a module, and it contains also some
container too (it's basically a big bag ;-).
> My understanding of Nicola's approach is:
>
> - Avalon is a repository containing Framework and
> Avalon-specific utilities
>
> - There is a area for container development
>
> - There is an area for pluggable components
Yes
> I might re-cast that as:
>
> - A repository containing Framework, which
> is the Avalon contract definition. This
> is what you can count on to be present,
> or optionally present with a guaranteed
> interface, in any compliant container.
>
> - Containers, and container-specific
> components.
>
> - Portable components.
>
> - Container development. Those classes
> that are provided to aid in developing
> new containers.
Yes
> When I then look at your solution:
>
>
>>* Avalon Framework remains as is. We can look
>> at Avalon 5 later after the dust has settled.
>
>
> Agreed.
>
>
>>* Avalon Excalibur gets repurposed to strictly a
>> location for Components. All support code gets
>> moved to commons (unless the move is already done
>> with Jakarta commons like in the case of
>> Collections or replaced by a more robust library
>> like Concurrent).
>
>
>>* All components in Avalon Cornerstone get merged into Excalibur. This
>> means we have to come up with some standard Context name/value pairs
>> that always exist--as this is the only reason why most cornerstone
>> components require Phoenix.
>
>
> I see that you and Nicola agree on this approach, but it confuses me. Why
> merge projects that seem to be at different levels within the model?
> One is
> a set of common classes used to implement containers, and the other is a set
> of components that are intended to run inside of containers. They appear,
> to me, to be two completely different categories.
Yes.
IIUC Berin wasn't thinking of merging them, but simply making Excalibur
a place for a set of components that are intended to run inside of
containers.
Thus my request to change the name to avalon-components.
> Basically, I see these categories:
>
> (1) contract exposed to components,
> (2) containers
> (3) components
>
> and common, Avalon-specific, code that can be used to develop new
> containers. This seems to be conceptually in keeping with both the current
> project notions and the various plans being proposed. Am I missing
> something?
IMHO no, this is a correct summary.
> I do agree with Nicola that using descriptive names in these
> discussions is best, regardless of what brand names may be applied to the
> projects, so maybe I am responding to a naming change, but I don't think
> that's it.
It's a radical change for Excalibur; well, effectively we are killing
it, as well as Cornerstone.
Now:
Cornerstone keeps some Components.
After:
"avalon-components" will keep them, and we should make them as
cross-container as possible
Now:
Excalibur keeps generic utility classes, Avalon utility classes,
components, containers and scratchpad stuff. Seems strange, but it is.
After:
- generic utility classes -> Jakarta or Apache Commons
- Avalon utility classes -> not sure, but they are components or
go in framework as utilities
- containers -> toplevel Avalon subprojects
- scratchpad stuff -> avalon-scratchpad
> By the way, speaking of naming changes, whatever changes occur, don't forget
> that those of us with projects already built on these technologies have both
> dependencies and inertia. Avalon is a platform. Because you have outside
> client code, you can't dance as nimbly as you might want. Packaging for
> outside consumption is an issue.
I don't want to see java package name changes just for this.
If an excalibur project will go for example to avalon-components, or a
cornerstone one, it can/should retain his package name.
It's just a matter of being clear about the Avalon projects. Package
names are not necessarily to follow suit.
--
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: Avalon Project Hierarchy
Posted by "Noel J. Bergman" <no...@devtech.com>.
> The Avalon project hierarchy has a concept that works, but
> the implementation that doesn't.
I think I agree with that in concept, but I don't think that there was
actually disagreement between Nicola and myself at all.
> For instance, from the thread "Single Avalon Implementation
yes/no/why/how",
> we have Noel writing:
> > * Avalon Excalibur - a major implementation of the
> > the Frameworks. But not the only possible one.
> And Nicola responding:
> > * Excalibur is not a major implementation of the the Framework. It
> > contains utility stuff to create containers and some
> > containers itself.
> Which represents some conceptual friction.
Nicola's correction / clarification *is* better. Nicola's correction is
that Excalibur isn't the implementation, but is rather a collection of
useful code used to implement containers, which (from the perspective of a
component) is the implementation of Frameworks. And if that isn't what
Nicola meant, then I apologize and need to re-read his message. :-)
My understanding of Nicola's approach is:
- Avalon is a repository containing Framework and
Avalon-specific utilities
- There is a area for container development
- There is an area for pluggable components
I might re-cast that as:
- A repository containing Framework, which
is the Avalon contract definition. This
is what you can count on to be present,
or optionally present with a guaranteed
interface, in any compliant container.
- Containers, and container-specific
components.
- Portable components.
- Container development. Those classes
that are provided to aid in developing
new containers.
When I then look at your solution:
> * Avalon Framework remains as is. We can look
> at Avalon 5 later after the dust has settled.
Agreed.
> * Avalon Excalibur gets repurposed to strictly a
> location for Components. All support code gets
> moved to commons (unless the move is already done
> with Jakarta commons like in the case of
> Collections or replaced by a more robust library
> like Concurrent).
> * All components in Avalon Cornerstone get merged into Excalibur. This
> means we have to come up with some standard Context name/value pairs
> that always exist--as this is the only reason why most cornerstone
> components require Phoenix.
I see that you and Nicola agree on this approach, but it confuses me. Why
merge projects that seem to be at different levels within the model? One is
a set of common classes used to implement containers, and the other is a set
of components that are intended to run inside of containers. They appear,
to me, to be two completely different categories.
Basically, I see these categories:
(1) contract exposed to components,
(2) containers
(3) components
and common, Avalon-specific, code that can be used to develop new
containers. This seems to be conceptually in keeping with both the current
project notions and the various plans being proposed. Am I missing
something? I do agree with Nicola that using descriptive names in these
discussions is best, regardless of what brand names may be applied to the
projects, so maybe I am responding to a naming change, but I don't think
that's it.
By the way, speaking of naming changes, whatever changes occur, don't forget
that those of us with projects already built on these technologies have both
dependencies and inertia. Avalon is a platform. Because you have outside
client code, you can't dance as nimbly as you might want. Packaging for
outside consumption is an issue.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Project Hierarchy
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>> * Avalon Framework remains as is. We can look at Avalon 5 later after
>> the dust has settled.
>
>
> this *MUST NOT CHANGE*. i realize the impetus that was behind the move
> to Serviceable and the dropping of the Component interface. IMHO, in
> hindsight, this was a VERY BAD idea. Not conceptually, but
> practically, because now everyone must move over or face massive
> deprecation warnings, which is not good. The empty marker interface
> could easily be provided by dynamic proxies. But what is done is done.
> we need to leave the A-F interfaces *SET IN STONE* so we have a
> foundation to build upon.
I'd agree to the extent of saying "as little as possible", or "nothing
that breaks back-compat". However at the time of the servicable change,
nobody knew that the the faking of Component was possible. It was a
revaltion to me on the JAMES list when Peter pointed out that he had
wrapped all components (small c) with Component makers in Phoenix 4.0.
It is imperfect though.
>> * Avalon Excalibur gets repurposed to strictly a location for
>> Components.
>> All support code gets moved to commons (unless the move is already
>> done with Jakarta commons like in the case of Collections or replaced
>> by a more robust library like Concurrent).
>
Given Excalibur (ignoring Merlin which should get a more prominent
position at Apache) is largely a set of beans, I see that as a massive
change to its remit.
> I'd like to see Excalibur either
>
> a) move to Apache Commons
Where the beans are very reusable, yes.
> or
>
> b) have a separate committer list, so individuals from A-F consumer
> projects could be involved in the component library. Basically opening
> it wide up for wider involvement.
+1
>> * As containers become mature, they move out of Avalon scratchpad and
>> become a top level sub-project. I.e. Avalon Fortress and Avalon
>> Merlin
>> at the same level as Avalon Phoenix when they are released.
>
>
> +1
+1
>> * All components in Avalon Cornerstone get merged into Excalibur. This
>> means we have to come up with some standard Context name/value pairs
>> that always exist--as this is the only reason why most cornerstone
>> components require Phoenix.
>
>
> +1
being disucssed elsewhere.
>> * I am not sure what to do with Avalon Apps. We need to look at the
>> possibility of moving them out of Avalon's sphere of responsibility.
>> I would have a hard time justifying their existence in an Avalon
>> charter.
>> But we may also want to follow the same rules as containers for the
>> applications.
>
We have agreed to eliminate many of these. Many more are very good
demos of component design.
> Agreed. Some things can go to the scratchpad (phyre, for one... kinda
> shelved for the moment unfortunately, but it will rise again!)
I'm guilty of this too.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Project Hierarchy
Posted by Peter Royal <pr...@apache.org>.
On Wednesday, November 20, 2002, at 09:55 AM, Berin Loritsch wrote:
> * Avalon Framework remains as is. We can look at Avalon 5 later after
> the dust has settled.
this *MUST NOT CHANGE*. i realize the impetus that was behind the move
to Serviceable and the dropping of the Component interface. IMHO, in
hindsight, this was a VERY BAD idea. Not conceptually, but practically,
because now everyone must move over or face massive deprecation
warnings, which is not good. The empty marker interface could easily be
provided by dynamic proxies. But what is done is done. we need to leave
the A-F interfaces *SET IN STONE* so we have a foundation to build upon.
> * Avalon Excalibur gets repurposed to strictly a location for
> Components.
> All support code gets moved to commons (unless the move is already
> done with Jakarta commons like in the case of Collections or replaced
> by a more robust library like Concurrent).
I'd like to see Excalibur either
a) move to Apache Commons
or
b) have a separate committer list, so individuals from A-F consumer
projects could be involved in the component library. Basically opening
it wide up for wider involvement.
> * As containers become mature, they move out of Avalon scratchpad and
> become a top level sub-project. I.e. Avalon Fortress and Avalon
> Merlin
> at the same level as Avalon Phoenix when they are released.
+1
> * All components in Avalon Cornerstone get merged into Excalibur. This
> means we have to come up with some standard Context name/value pairs
> that always exist--as this is the only reason why most cornerstone
> components require Phoenix.
+1
> * I am not sure what to do with Avalon Apps. We need to look at the
> possibility of moving them out of Avalon's sphere of responsibility.
> I would have a hard time justifying their existence in an Avalon
> charter.
> But we may also want to follow the same rules as containers for the
> applications.
Agreed. Some things can go to the scratchpad (phyre, for one... kinda
shelved for the moment unfortunately, but it will rise again!)
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Avalon Project Hierarchy
Posted by Berin Loritsch <bl...@citi-us.com>.
The Avalon project hierarchy has a concept that works, but
the implementation that doesn't. For instance, from the
thread "Single Avalon Implementation yes/no/why/how", we
have Noel writing:
> > Please be specific about what you mean? As I see it, the
> current division
> > of Avalon technologies makes sense to me:
> >
> > * Avalon Frameworks - these are the basic contracts that
> > authors can expect to be guaranteed in all platforms,
> > plus some simple utilities.
> >
> > * Avalon Excalibur - a major implementation of the
> > the Frameworks. But not the only possible one.
> >
> > * Avalon Containers - container implementations.
> > Guaranteed to support Avalon Frameworks, and
> > typically written using Excalibur classes.
> >
> > * Avalon Cornerstone - common pluggable services.
> > Best case says that they should run in any
> > proper container.
> >
> > * Avalon Applications - a repository for "demo"
> > applications that don't have their own place.
And Nicola responding:
> Basically it makes sense.
> There are some issues though:
>
> * Excalibur is not a major implementation of the the Framework. It
> contains utility stuff to create containers and some
> containers itself.
>
> * Avalon Containers is not there, and containers have been growing in
> Excalibur.
>
> * Avalon Cornerstone has components that cannot yet run in all
> containers. We should ensure that it can happen or that it's properly
> labeled where really impossible to make it cross-container.
Which represents some conceptual friction.
Nicola's solution includes:
> 1) Avalon becomes a single repository with framework and
> utilities. All
> utilities that are not Avalon-specific move to J-Commons- or Commons.
> This has already been started.
>
> 2) There is a place where to breed containers. Can be Avalon
> scratchpad
> or container scratchpad.
>
> 3) there is a place to keep containers. In my proposal it's in a
> ./containers subdir of the Avalon CVS. If the container becomes big
> enough, like Phoenix, it becomes an Avalon subproject in its
> own right.
>
> 4) Avalon Cornerstone and Avalon Applications are placed in a
> repository
> where multiple parties can collaborate. So it can be Apache Avalon
> Commons ot Apache Commons Avalon, but the concept remains.
As of right now, everyone seems to be in agreement that Framework is
at the core. It is by itself. Where the differences in ideas/oppinions
come is where components and containers go. For that reason, I would
like to propose the following solution.
* Avalon Framework remains as is. We can look at Avalon 5 later after
the dust has settled.
* Avalon Excalibur gets repurposed to strictly a location for Components.
All support code gets moved to commons (unless the move is already
done with Jakarta commons like in the case of Collections or replaced
by a more robust library like Concurrent).
- The TestCase and Instrument projects need to be handled as they are
specific to Avalon.
- It can probably be argued that Instrument might make an excellent
candidate for Avalon Commons. It is some top notch code.
- We may want to make the core Instrument library part of Avalon
framework (discussion must occur first).
* Avalon Scratchpad is a location for maturing subprojects to grow.
* As containers become mature, they move out of Avalon scratchpad and
become a top level sub-project. I.e. Avalon Fortress and Avalon Merlin
at the same level as Avalon Phoenix when they are released.
* All components in Avalon Cornerstone get merged into Excalibur. This
means we have to come up with some standard Context name/value pairs
that always exist--as this is the only reason why most cornerstone
components require Phoenix.
* I am not sure what to do with Avalon Apps. We need to look at the
possibility of moving them out of Avalon's sphere of responsibility.
I would have a hard time justifying their existence in an Avalon charter.
But we may also want to follow the same rules as containers for the
applications.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Single Avalon Implementation yes/no/why/how ( Re: CVS organization )
Posted by "Noel J. Bergman" <no...@devtech.com>.
> * Excalibur is not a major implementation of the the Framework. It
> contains utility stuff to create containers and some containers
The fact that it contains stuff to implement containers, and containers
expose the Framework to pluggable components was the sense in which I meant
it, but I see how my overly simple definition was in error. I appreciate
your correction / clarification.
> * Avalon Containers is not there
I didn't mean to label it like a module. :-) More of a conceptual
grouping. But it sounds from your own note that you think it should be a
module.
> 1) Avalon becomes a single repository with framework and utilities. All
utilities that are not Avalon-specific move to J-Commons- or Commons.
Agreed. The only thing that gave me pause is to ensure that there is a
loose coupling between Frameworks and Avalon-specific utilities.
> Yes, as I tried to outline above the conceptual separation emains.
> And yes, we must better define the relations especially with regards to
> component protability.
That's all I was saying. :-) Your comments indicate that you are quite in
agreement.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Single Avalon Implementation yes/no/why/how ( Re: CVS organization
)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Noel J. Bergman wrote:
>>>> 3) The containers that are in the works
>>>
>>>I'm still wondering if we really need different implementations
>>
>>It can be that we will eventually come to a single design
>
>
> Please be specific about what you mean? As I see it, the current division
> of Avalon technologies makes sense to me:
>
> * Avalon Frameworks - these are the basic contracts that
> authors can expect to be guaranteed in all platforms,
> plus some simple utilities.
>
> * Avalon Excalibur - a major implementation of the
> the Frameworks. But not the only possible one.
>
> * Avalon Containers - container implementations.
> Guaranteed to support Avalon Frameworks, and
> typically written using Excalibur classes.
>
> * Avalon Cornerstone - common pluggable services.
> Best case says that they should run in any
> proper container.
>
> * Avalon Applications - a repository for "demo"
> applications that don't have their own place.
>
> Perhaps I am entirely wrong in my understanding of the conceptual division
> of things, so I am open to correction. I am admittedly a little loose in my
> definitions. The actual definition for Cornerstone, from the web site, ties
> it tightly to the Phoenix container.
>
> Doesn't such a division make sense? You have: interfaces, classes that
> implement those interfaces, containers that support pluggable components, a
> reusable library of utility components, and finally pluggable applications.
Basically it makes sense.
There are some issues though:
* Excalibur is not a major implementation of the the Framework. It
contains utility stuff to create containers and some containers itself.
* Avalon Containers is not there, and containers have been growing in
Excalibur.
* Avalon Cornerstone has components that cannot yet run in all
containers. We should ensure that it can happen or that it's properly
labeled where really impossible to make it cross-container.
Basically, expanding my original idea based on your mail:
1) Avalon becomes a single repository with framework and utilities. All
utilities that are not Avalon-specific move to J-Commons- or Commons.
This has already been started.
2) There is a place where to breed containers. Can be Avalon scratchpad
or container scratchpad.
3) there is a place to keep containers. In my proposal it's in a
./containers subdir of the Avalon CVS. If the container becomes big
enough, like Phoenix, it becomes an Avalon subproject in its own right.
4) Avalon Cornerstone and Avalon Applications are placed in a repository
where multiple parties can collaborate. So it can be Apache Avalon
Commons ot Apache Commons Avalon, but the concept remains.
> If I wanted to write a new Avalon container for a real-time environment on a
> PDA, I ought to be dependent only upon the Avalon Frameworks. I could
> CHOOSE to use Excalibur, or not. In a best case scenario, if I implement my
> own container using nothing common EXCEPT for the Avalon Frameworks, I'd
> like to be able to use Avalon Cornerstone components without their having
> dependencies upon Excalibur classes; that may not be possible today - it is
> a normative notion. And third party should not be dependent upon anything
> not specified in Avalon Frameworks.
>
> This is mostly about clean separation, but there are also packaging issues.
Yes. The concept is correct, these things must compile not all together
but following dependencies.
>>Phoenix is released, proved and really stable. Think that someone has
>>even gotten James working on a C# based JVM
>
> That's true! LOL But how did you hear about it?
Blog -> Blog -> Blog...etc ;-)
>>Technically it seems sensible that there be one framework and more
>>possible implementations. Community-wise, I'm not so sure.
>
> Perhaps. But I think that the dependencies should be kept clean to permit
> the option. Also, the cleaner the dependencies, the smaller the surface
> area, and the more flexibility to change in the future.
Yes, dependencies must remain clean.
>>if we cannot come to a single implementation,
>>probably it's because we still don't know how
>>to do it.
>
>
> Single implementation of WHAT, precisely? Frameworks? Absolutely.
> Necessary. By defintion, there must be only a single definition of Avalon
> Frameworks. Other than that, I'd prefer not to see any necessary
> dependencies imposed upon container authors or upon components.
>
> Let me point out that there are new notions coming within Java that effect
> certain patterns of use. Such things as JSR 166 will have an impact, and
> should. The same with java.nio.
>
> Loose coupling is good. Perhaps the coupling areas need to be better
> defined, and the loose coupling better enforced within the current code
> (perhaps even shifting things), but the basic concept of organizing around
> interfaces, classes, containers, and components seems sound to me. No?
Yes, as I tried to outline above the conceptual separation emains.
And yes, we must better define the relations especially with regards to
component protability.
Talking java-wise, we must define the interfaces that these levels use
with the lower ones and stick to them.
--
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: Single Avalon Implementation yes/no/why/how ( Re: CVS organization )
Posted by "Noel J. Bergman" <no...@devtech.com>.
>>> 3) The containers that are in the works
>> I'm still wondering if we really need different implementations
>It can be that we will eventually come to a single design
Please be specific about what you mean? As I see it, the current division
of Avalon technologies makes sense to me:
* Avalon Frameworks - these are the basic contracts that
authors can expect to be guaranteed in all platforms,
plus some simple utilities.
* Avalon Excalibur - a major implementation of the
the Frameworks. But not the only possible one.
* Avalon Containers - container implementations.
Guaranteed to support Avalon Frameworks, and
typically written using Excalibur classes.
* Avalon Cornerstone - common pluggable services.
Best case says that they should run in any
proper container.
* Avalon Applications - a repository for "demo"
applications that don't have their own place.
Perhaps I am entirely wrong in my understanding of the conceptual division
of things, so I am open to correction. I am admittedly a little loose in my
definitions. The actual definition for Cornerstone, from the web site, ties
it tightly to the Phoenix container.
Doesn't such a division make sense? You have: interfaces, classes that
implement those interfaces, containers that support pluggable components, a
reusable library of utility components, and finally pluggable applications.
If I wanted to write a new Avalon container for a real-time environment on a
PDA, I ought to be dependent only upon the Avalon Frameworks. I could
CHOOSE to use Excalibur, or not. In a best case scenario, if I implement my
own container using nothing common EXCEPT for the Avalon Frameworks, I'd
like to be able to use Avalon Cornerstone components without their having
dependencies upon Excalibur classes; that may not be possible today - it is
a normative notion. And third party should not be dependent upon anything
not specified in Avalon Frameworks.
This is mostly about clean separation, but there are also packaging issues.
> Phoenix is released, proved and really stable. Think that someone has
> even gotten James working on a C# based JVM
That's true! LOL But how did you hear about it?
> Technically it seems sensible that there be one framework and more
> possible implementations. Community-wise, I'm not so sure.
Perhaps. But I think that the dependencies should be kept clean to permit
the option. Also, the cleaner the dependencies, the smaller the surface
area, and the more flexibility to change in the future.
> if we cannot come to a single implementation,
> probably it's because we still don't know how
> to do it.
Single implementation of WHAT, precisely? Frameworks? Absolutely.
Necessary. By defintion, there must be only a single definition of Avalon
Frameworks. Other than that, I'd prefer not to see any necessary
dependencies imposed upon container authors or upon components.
Let me point out that there are new notions coming within Java that effect
certain patterns of use. Such things as JSR 166 will have an impact, and
should. The same with java.nio.
Loose coupling is good. Perhaps the coupling areas need to be better
defined, and the loose coupling better enforced within the current code
(perhaps even shifting things), but the basic concept of organizing around
interfaces, classes, containers, and components seems sound to me. No?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>