avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Future of Fortress
Date Tue, 13 Apr 2004 04:12:57 GMT
Niclas Hedhman wrote:
> Noel J. Bergman wrote:
> > > A component developed against a set of (one or more) specifications
> > > WILL work unmodified in all applications that understand/"complies
> > > with" suc specification(s).
> >
> > That is like saying that a J2EE component will run on every J2EE app
> > server. Very nice, but doesn't do much for J2SE or J2ME.  Essentially,
> > you are saying that only an Avalon "J2EE" can/should exist.

> Not at all. I have probably not been good at communicating my findings.

I did not mean J2EE in the sense that it is necessarily heavyweight.  J2EE
is a superset of the other platform specifications, and you are raising the
bar for the minimum platform specification.

That isn't necessarily a bad thing.  I thought that your comments in this
most recent message were fairly measured and balanced.  It would be
interesting to see how people in the Fortress community feel about them.  I
thought I saw some earlier comments that were positive about the general
idea, so long as it doesn't break compatibility with existing code, but
responses from Stephen indicated that developing Fortress to support such
things is out of the question, because Merlin shall be the only Avalon
container.  This appears to conflict with what others want, and does not
appear to be required by your desire to ...

> [establish] the existing formal contracts (pluralis) that do exist
> (by implementation coincidence) in ECM, Fortress and Merlin.  Each
> container being developed then has a fairly straight forward task
> when encountering a component [...]

> that brings me to a much tougher nut to crack, since noone think
> it is an issue; How do you "Identify" a component? Or a service
> for that matter?  I have no definate answers here yet, but I am
> actually leaning towards using a URN

I think you need to elaborate, but all in all, I think your ideas seem

> Here the problems of consensus would start big time. Some would be
> in favour of sticking to a Java only solution, others to files in
> JAR or entries in Manifest, and perhaps another group would like to
> see an RDF solution.  Are they mutually exclusive? No, but the more
> schemes the harder for everyone.

I keep thinking that this is a representation issue, and multiple forms
could be supported.  A container could detect which, if any, representations
that it understands is present, and act accordingly.  If it did not find
any, that would mean, in your words, that "the component doesn't work with
that container."

However, with respect to consensus, it seems to me that although we
sometimes get a reasonable and workable message like yours, from which
people could try to build a consensus, we are increasingly seeing dug in
positions of absolutes that leave no room.

	--- Noel

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

View raw message