avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: [desperate plea] RE: The need for 'hints'
Date Fri, 21 Jun 2002 15:23:51 GMT
> Shoking my town :)
> Yep, Avalon composed Blocks. Blocks were the software equivalent of lego
> bricks. Where polymorphic objects.
> Blocks had version, metadata dependencies, they were thread-safe, they
> were big.
> I remember a pretty heated discussion with Peter about the size of
> blocks. That time I even managed to change his mind ;-)
> Components were introduced later and were introduced mostly because the
> block patterns could be used inside the blocks as well, but where
> portability was not an issue anymore.

hmm. But reuse of the smaller pieces is also nice, even if they're not
threadsafe or depedenent on other pieces.

> So, we had the big reusable/sharable pieces called Blocks and the small
> pieces called Components.
> In short, Components were classes++, classes that followed the Avalon
> model. Since in java you want to the ability to instantiate a particular
> class, the need for hints emerged for Components (never for blocks!).
> Result: ComponentSelector.
> At that point I left this community for personal reasons.
> I come back a while after and:
>  1) blocks are deprecated

nah, that's the marker interface.

>  2) components are becoming blocks
>  3) direct component instantiation is considered harmful
> Without even noticing, the pure-COP promoters are going backwards: we
> were there already, you simply changed the name of 'block' to
> 'component'.

I don't think so. A lot more has been changed.

> > In Cocoon, a component can be something very small,
> > and in A5, a component will be something quite big.
> Gosh, things would be easier if you didn't deprecate the concept of
> 'block' and wanted to use the same name for two different things.
>  block -> an avalon-lifecycle-aware polymorphic object, versionned,
> fully reentrant, sharable, not directly referentiable

example: implementation of FTP, POP, ...
why are these "not directly referentiable"? Whole point of stuff like
JMX, SOAP, JNDI is to enable that.

>  component -> an avalon-lifecycle-aware polymorphic object, directly
> referentiable

example: any java object with appropriate lifecycle.

> It's evident why we wan't find agreement on how to lookup components:
>  lookup(role)
> returns a Block, while
>  lookup(role, hint)
> returns a Component.

hmm. You mean we need different lookup mechanisms because at one
granularity (blocks) there is stuff like policy, metainfo, etc, and at
the other one (components), there isn't?

- why would a lookup mechanism be coupled to arbitraty granularity?
- why would a lookup mechanism be coupled to policy?
- why is it that where the metainfo stuff is actually in use, it is
about components instead of blocks?

> Cocoon, being itself block-like, references components. This is why it
> needs the ability to reference them directly.

what? It references components so it needs to reference them directly?

> Phoenix/Merlin, on the other hand, being block containers, don't like
> hints because blocks are not directly referentiable (nor they should
> be!)

why shouldn't they be?

Phoenix couldn't care less if you were to use hints to lookup an
application. It would work just as well (or badly, depending on your
viewpoint) as it does in cocoon.

> *THIS* is, IMO, the biggest design mistake done during my absence: you
> merged two different things into one, without understanding that they
> were totally different and they only thing they shared was
> avalon-lifecycle awareness.

the ComponentManager is part of the avalon lifecycle, isn't it? Are you
saying it shouldn't be?

> > I'm sure we can find something that allows Avalon to scale
> > from small to big stuff.
> Hopefully the above will bring context.

hmm. I'm still sure we can find a lookup mechanism that can be part of
the lifecycle, that can scale from as-tiny-as-possible to

> No, careful. Cocoon is block-like and required special treatment of
> internal components. That pushed more and more pressure on the handling
> on 'components' (using the terminology above, not the current avalon
> one) that twisted the clean design of Avalon.
> Removing the 'block' pillar forced too much pressure on the current
> concept of Component, leading to 'abuse' of patterns and the creation of
> inelegant solutions (like ComponentSelector, for example, which nobody
> ever liked but it was approved for need)

I have this integrated application where everything that is not data is
an avalon component (current definition). Among other things, it
includes a mail server, a database layer, persistence facilities, web
server, etc. Those are avalon blocks (==components, ==.bars), they run
within phoenix, packaged into three layers (backend, middleware,
frontend) and thus three server applications (==blocks, ==components,

Within those blocks are avalon components like MimeMessageBuilder,
QueryBuilder, QueryTransformer, DataSource, TemplateParser. Each of the
blocks uses its own (very simple) container (similar to tweety, but with
pooling and some other stuff) to manage those components.

So basically the separation you ment, not?

The key is, they all happily use the same ComponentManager (no Selector,
no release in use). And they're all versioned and directly

> > Coming and saying "abuse! That's not
> > how we want you to use our framework" has quite a high
> > piss-off factor, migration path or not.
> Unless you clearly show why.

I wonder...


- Leo

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