avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter M. Goldstein" <peter_m_goldst...@yahoo.com>
Subject RE: Single Avalon Implementation yes/no/why/how ( Re: CVS organization )
Date Thu, 21 Nov 2002 20:41:42 GMT


> 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
> 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,
> 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
> 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
> 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

>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
> >could declare what context contracts they require.  Component
> >would know immediately whether a container was sufficient to run
> >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
> >to run the James server.".  If there were a container designed to run
> >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
> >that container alone.  That's ok, because the dependencies will be
> >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

> >>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
> >makes Phoenix first among all containers.  I like Phoenix, and I have
> >suppored using Phoenix for James' standard distribution, but you
> >simultaneously argue that all containers are equal, while stating
> >some containers are more equal than others.  Last I checked, Animal
> >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,
> >don't see how you can resolve the two.
> >
> Yup.


> >We (specifically some of the Avalon consumers) keep trying to make
> >that the line needs to be drawn between what is common and what is
> >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
> >
> 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.


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

View raw message