Re: [RT] Serviceable considered harmful (was Re: XSP not working in CVS head?)

[Berin Loritsch <bl...@d-haven.org>]

Ugo Cei wrote:
> Sylvain Wallez wrote:
> 
> Isn't this neater? No need to implement an Avalon interface. The problem 
> is, Serviceable breaks IoC big time. We preach the Hollywood principle 
> and then provide almost _ALL_ our components with a big telephone 
> directory. Component should be injected with all the needed 
> dependencies, not have to look them up through ServiceManager.

see below.

> 
> And while we're at it, since "AbstractLogEnabled" was mentioned by 
> Sylvain, I'll vent my opinion on it too (feel free to spawn a different 
> thread if you want to reply to me on this subject). Well, my 
> (not-so-)humble opinion is that it sucks! It sucks because we are 
> reusing an aspect like "being log-enabled" via concrete *implementation* 
> inheritance. If this doesn't suck, in terms of good OO design, the tell 
> me what does. And we are doing this just to avoid the hassle of 
> declaring a "logger" member, a setter and a getter.

Ok, so LogEnabled is the interface, and AbstractLogEnabled is a way of
taking care of this aspect using inheritance, they are two different
methods of achieving the same thing.

> 
> Oh, by the way, LogicSheet extends AbstractLogEnabled but does not 
> actually log anything. So I removed "extends AbstractLogEnabled" in my 
> local copy and will commit it after the release, if nobody objects.

I remember making a logging XSP logicsheet a while back, is this used/
still included?

OK, now to the topic of IoC, Serviceable, etc.  This is a fundamental
change to the framework that you may are suggesting.  Such a change is
not easy, and can be considered harmful unless you design your container
in a way to support heterogeneous component types.

You might want to take some inspiration from my Dojo project (note I
said inspiration--I am not suggesting you depend on my code unless you
feel it truly merits it).  The concept that I am designing and
evolving Dojo from is one where any one JAR file will have the same
kind of components in it--which is why I have one ComponentFactory per
Dojo.  This also greatly simplifies the design.  The default "budo" or
"framework" is similar to the Spring/JavaBean concept of using setters
and getters.  By default there is no configuration file.  There is no
automatic way to set up the dojo--until you add it as a layer on top.
I have a potential Avalon implementation on top of Dojo, but it is
limited.

Serviceable, and passing in a ServiceManager is technically IoC.
Granted, the default solution of allowing any component to look up
any other component it desires is not the safest--but it is the
easiest--solution for the problem of getting other components in an
Avalon context.  Both Merlin and Phoenix demonstrate that you can
have an Avalon system that only provides the declared dependencies.
There is an inherent complexity in this system, and adds to the code
bloat.  On the other hand, a solution based only on reflection does
place an incredible burden on trying to improve performance.  Even
using a dynamically created proxy class without reflection is expensive.

To be sure there is no perfect solution, but the "Spring" style
component using setters and getters is natural to a great number of
developers.  The "pico" style component using constructor parameters
is also very natural to a great number of developers.  Sometimes a
hybrid can be used like constructor parameters for required components
and setters and getters for optional components.  The setter/getter
approach does make the testing of the component much easier.  However
do recognize that Cocoon has a certain inertia that must be redirected.
I suggest small corrective improvements to get Cocoon where you would
like to be.

Re: [RT] Serviceable considered harmful (was Re: XSP not working in CVS head?)

[Berin Loritsch <bl...@d-haven.org>]

Ugo Cei wrote:

>> I understand.  I wasn't so much suggesting looking at the code but the
>> design principles.  The only way heterogeneous component types would
>> work in a Cocoon environment is employing something like what I
>> suggested.  Granted there may be other ways, but IMO that is the most
>> easily sustainable way.
> 
> 
> Can you explain what you mean by "heterogeneous components"?

heterogeneous simply means "of different types".  I.e. the ability to
mix Spring style components with Avalon style components and pico style
components.

You do have to draw boundaries of where and how these components are
defined so that you can know how to instantiate them.

Re: [RT] Serviceable considered harmful (was Re: XSP not working in CVS head?)

[Ugo Cei <ug...@apache.org>]

Il giorno 17/mag/04, alle 22:51, Berin Loritsch ha scritto:

> I thought the idea here was to have Cocoon hosted on its own container,
> initially based on ECM style code and adapted better to Cocoon's needs.
> This much has (I believe) happened.

I don't know. We have a tentative "kernel" in 2.2, but I doubt we can 
host Cocoon in it at the moment.

> I understand.  I wasn't so much suggesting looking at the code but the
> design principles.  The only way heterogeneous component types would
> work in a Cocoon environment is employing something like what I
> suggested.  Granted there may be other ways, but IMO that is the most
> easily sustainable way.

Can you explain what you mean by "heterogeneous components"?

	Ugo

-- 
Ugo Cei - http://beblogging.com/

Re: [RT] Serviceable considered harmful (was Re: XSP not working in CVS head?)

[Berin Loritsch <bl...@d-haven.org>]

Ugo Cei wrote:
> Il giorno 17/mag/04, alle 16:53, Berin Loritsch ha scritto:
>> OK, now to the topic of IoC, Serviceable, etc.  This is a fundamental
>> change to the framework that you may are suggesting.  Such a change is
>> not easy, and can be considered harmful unless you design your container
>> in a way to support heterogeneous component types.
> 
> Just to be clear: I'm not going to write a container any time soon. I 
> don't have neither the time nor the necessary architectural and coding 
> skills. I just started evaluating Spring for implementing the Model part 
> of an MVC application that we are developing (V+C is Cocoon with 
> Flowscript, obviously) and I like what I see. At the same time, I don't 
> like some of what I see in the usage of Avalon in Cocoon. Spring is a 
> well-established, well-documented product that is rapidly gaining 
> popularity and is being put to test in writing real applications (I'm 
> not implying that Avalon isn't) and we might learn something from it.

Well, I will say that it looks like Cocoon has its own container, which
is fine.  If enough people want to adapt that container to different
component models then we need to look at that.

> (As an aside, Spring's lead developer thinks checked exceptions are 
> evil, so I like the guy ;-) )

I, personally, am somewhere in between.

> And yes, this is a fundamental change. We started discussing fundamental 
> changes since Stefano's "On building on stone" RT, but discussion has a 
> little subsided since then, so I'm trying to revive it.

I thought the idea here was to have Cocoon hosted on its own container,
initially based on ECM style code and adapted better to Cocoon's needs.
This much has (I believe) happened.

>> You might want to take some inspiration from my Dojo project (note I
>> said inspiration--I am not suggesting you depend on my code unless you
>> feel it truly merits it).  The concept that I am designing and
> 
> I've been following Dojo through your blog, but I must be sincere: I 
> don't have the time to look at its code. I am looking at Spring with 
> some interest because, as I said above, I'm using it in a real project, 
> and that's all.

I understand.  I wasn't so much suggesting looking at the code but the
design principles.  The only way heterogeneous component types would
work in a Cocoon environment is employing something like what I
suggested.  Granted there may be other ways, but IMO that is the most
easily sustainable way.

I will say that initial experimentation with writing components in
different styles I like certain aspects of Spring, Pico, and Avalon
style components--although I must admit that the initial romance of
King Author's court has worn off.  In the end, the direct injector
style of component works quite well, and is quicker than Avalon
components for startup times.  Why?  The answer is simple, the component
has less to do.  With Avalon, you are given an artifact that you must
now read and interpret at runtime.  So instead of just one read and
interpret cycle (i.e. the reading of a configuration file or something
similar) we have two (one for the config file and one for each
component).

This also leaves allot for the component to have to deal with if
something is not right.  As you can imagine, some components are well
designed and have well thought out error messages and failure
notification while other components don't.  You can't easily codify
an "aspect" that can be applied across all components because the
mechanism to set values is different.  This is probably another area
where you enjoy Spring style components.

The end result is that with components that are set up much quicker,
the need for pooling components becomes less of a need, and it is more
reasonable to use singleton and transient style components.  Another
benefit we all enjoy is simpler code as we no longer have to surround
our lookups with try/catch/finally--although it is still necessary for
database code.

Lastly, I find that testing spring/pico style components is much much
easier as I can inject my mocks directly into the component to test
its functionality.  This combination makes a strong case for the Spring/
Pico style components, but again, providing native support for it in
Cocoon will not be as straightforward as it could be.  Changes to the
core of a framework or application should be done with great care--but
don't be too afraid to do it.

Re: [RT] Serviceable considered harmful (was Re: XSP not working in CVS head?)

[Ugo Cei <ug...@apache.org>]

Il giorno 17/mag/04, alle 16:53, Berin Loritsch ha scritto:

> Ok, so LogEnabled is the interface, and AbstractLogEnabled is a way of
> taking care of this aspect using inheritance, they are two different
> methods of achieving the same thing.

Yes. It's just that achieving reuse through implementation inheritance 
does not seem to me to be very elegant in this particular case.

>> Oh, by the way, LogicSheet extends AbstractLogEnabled but does not 
>> actually log anything. So I removed "extends AbstractLogEnabled" in 
>> my local copy and will commit it after the release, if nobody 
>> objects.
>
> I remember making a logging XSP logicsheet a while back, is this used/
> still included?

I don't know, but I'm afraid I spoke too early. Cocoon doesn't build if 
I remove "extends AbstractLogEnabled". I was lead into error when 
Eclipse did not complain, but it complained after a full project 
rebuild.

> OK, now to the topic of IoC, Serviceable, etc.  This is a fundamental
> change to the framework that you may are suggesting.  Such a change is
> not easy, and can be considered harmful unless you design your 
> container
> in a way to support heterogeneous component types.

Just to be clear: I'm not going to write a container any time soon. I 
don't have neither the time nor the necessary architectural and coding 
skills. I just started evaluating Spring for implementing the Model 
part of an MVC application that we are developing (V+C is Cocoon with 
Flowscript, obviously) and I like what I see. At the same time, I don't 
like some of what I see in the usage of Avalon in Cocoon. Spring is a 
well-established, well-documented product that is rapidly gaining 
popularity and is being put to test in writing real applications (I'm 
not implying that Avalon isn't) and we might learn something from it.

(As an aside, Spring's lead developer thinks checked exceptions are 
evil, so I like the guy ;-) )

And yes, this is a fundamental change. We started discussing 
fundamental changes since Stefano's "On building on stone" RT, but 
discussion has a little subsided since then, so I'm trying to revive 
it.

> You might want to take some inspiration from my Dojo project (note I
> said inspiration--I am not suggesting you depend on my code unless you
> feel it truly merits it).  The concept that I am designing and

I've been following Dojo through your blog, but I must be sincere: I 
don't have the time to look at its code. I am looking at Spring with 
some interest because, as I said above, I'm using it in a real project, 
and that's all.

	Ugo

-- 
Ugo Cei - http://beblogging.com/