> From: Leo Sutic [mailto:[EMAIL PROTECTED]]
>
> > From: Leo Simons [mailto:[EMAIL PROTECTED]]
> >
> > > Leo Sutic wrote:
> > > > Carsten,
> > > >
> > > > you are right - everything gets a little bit more complicated.
> > > >
> > > Yes, and this is the thing that worries me - I know a lot
> of people
> > > saying "Avalon is too complicated" and this makes it even a
> > little bit
> > > more complicated,
> >
> > hmm. Is it more complicated?
>
> As Vadim said in a comparison of Cocoon and Struts: Cocoon
> developers come from the "pattern hell" school of thought.
> (That was a point against Cocoon, if anyone missed it.)
>
> Worth thinking about, as I have seen some people here
> accusing Cocoon of not following patterns cleanly enough.
In Cocoon, there is a mixture of a number of styles and patterns,
etc. It does not necessarily translate to all Avalon applications.
Cocoon has a lot of work to do to simplify the component model.
> As a matter of fact, I think we scare the shit out of most
> people with the complexity of the framework already. Patterns within
> patterns... It is not whether there are patterns or not - it is
> the fact that you have patterns of patterns, and you must
> somehow grasp them all.
The CORE framework only specifies a minimalist set of patterns.
* All components are managed in containers
* Those containers are responsible for the lifecycle and lifestyle
of the components.
* The ComponentManager (should it be ComponentDirectory?) is used
by a client to gain access to other components.
We also have semantics regarding Avalon primitives like Configuration/
Parameters/Context.
The thing that is most confusing about Avalon is that the containers
do things differently--and we need to unify the approach. This is
a _simplification_, not anything more complex. Currently the way
we represent meta-data is all over the place. Fortress/ECM use a
RoleManager, Phoenix uses component info (.xinfo) files, etc.
That is because we have not yet specified anything more to the container
contract than the three bullets above.
Not supporting explicitly pooled components is a _simplification_,
not anything more complex. No other component framework I know of
places the concern of releasing pooled resources on the client, why
should we be any different.
What we need to do is provide alternatives to what the previous
generation of avalon users were able to do, and reasons or tradeoffs
for each approach.
> So I completely understand Carsten. We will lose users. I see
> before me someone saying "F*** it. (1) They are obviously not
> committed to API stability, (2) just about when we've finally
> learned to use the framework (given how complex it is that
> may be a while), the next
> change will come along, (3) the cost of maintenance and keeping up
> with that will kill us. Let's roll our own framework."
A large percentage of the changes can be worked around with a
compatibility layer. By including an Avalon 4 compatibility
jar, client projects can upgrade at their own pace--as they explore
which approach to pooled components they prefer.
> If it is more complicated or not does not matter - what
> matters is what it is *percieved* as.
A design goal of A5 should be to make it so that the component
developer doesn't really care if the component is pooled, created
fresh every time, has one instance per thread, or is threadsafe.
We should encourage them to write threadsafe code, but we do want
to simplify things, and make it look simpler--addressing your
perception problem.
So far the thing I don't like about the XXXXManager solution is
that it places the responsibility of pooling semantics on the
XXXXManager developer. The usage of the XXXXManager is not really
an issue as it is easier to use than
lookup(ROLE).select(hint).release().
I would prefer to make it so that it doesn't really matter if
something is pooled or not. However we do need to work out how
to hide it from the user in the best way.
>
> For all its faults, A4 is *easy* to *use*. (Although I
> confess I never ever understood the RoleManager.)
Leo, the RoleManager is not a Framework thing--it is used in both
ECM and Fortress.
It is their tool to map convenient shorthand names to your components.
In other words it is only meant to be a way for the container to
interpret a user friendly config file without hardcoding names in the
container.
For example, which is easier for a *user* to understand?
<component role="org.apache.excalibur.sourceresolve.SourceResolver"
class="org.apache.excalibur.sourceresolve.SourceResolverImpl"
handler="org.apache.excalibur.fortress.handlers.ThreadsafeHandler">
<my-config>My configuration element</my-config>
</component>
or
<source-resolver>
<my-config>My configuration element</my-config>
</source-resolver>
The role, class, handler information is container information--not user
information, and they take up a lot of space. By putting it in a
RoleManager,
the container can read "source-resolver" and know that it means the
role,class,handler combination above.
The configuration file becomes cleaner, while still general purpose.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
