cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [RT] Spring+JMX == Real Blocks?
Date Mon, 12 Jul 2004 11:48:41 GMT

Sylvain Wallez wrote:

> Ugo Cei wrote:
>> Dear Cocooners,
>> this is something more crazy than a Random Thought, something that one 
>> can only think of on a Friday evening after a few hours of boooring 
>> application development (doing infrastructure things is much more 
>> fun). Maybe we should coin a new acronym: "WT" for "Wild Thoughts".
> <snip/>
>> Now, please tell me I'm totally out of my mind, so that I stop toying 
>> with too many crazy ideas and get down to get some real work done ;-)
> Crazy ideas can become mainstream when they're collectively shaked ;-)
> I only have a reading knowledge of Spring, and find its lack of invasive 

I've been gradually delving in deeper and deeper, and I can only 
resonate with Ugo's enthousiasm (even on well designed use of RTE's :-))

> API a very good thing contrarily to Avalon. But I'm wondering about a 
> few things... These may be naive questions though, for someone having 
> the knowledge of both Avalon and Spring.
> The bean definition file defines all services of system like 
> cocoon.xconf, but also the wiring, which is handled internally by 
> lookups with Avalon. This has several consequences:
> - people writing this file must have an in-depth knowledge of 
> implementation classes used (not only abstract service interfaces) and 
> the wiring they need. This is a difficult task.

which can be abstracted down,

point being: I don't see how e.g. listing up the different component 
implementations of a certain component-interface becomes more dificult 
or more verbose in spring's bean-xml then in our cocoon.xconf

> - the full wiring may lead to huge files in large systems (i.e. Cocoon). 
> So the question is: does it scale?

well, that's what I like in the JMX mix-in wild-thought of Ugo's 
subject-line: an idea of grouping of these spring-xml's would map 
exactly the 'feature/feeling/flexibility' of the block-componentization idea

wiring complex beasts up in a simple config based on simple beasts

> - can the framework ensure that no wiring is missing? Is there another 
> way than having a NPE at runtime?

if it's an issue, you handle it.

if in avalon you forget to lookup or release a dependency you're baked
if in spring you forget to declare the dependency in the bean-xml: 
you're in the same spot

both cases could be handled to resort to some default behaviour (which 
could be: throwing NPE :-) to indicate a serious 'programming' error)

there is what they call auto-wiring support, but (with my current 
knowledge) I would not advise to generaly rely on that kind of magic

in any case, you can still be working with service-selectors (factories 
and/or poolmanagers) AFAICS you just pull those aspects up in your POJO 
level: meaning you consider them not as part of the framework, but part 
of what is essentially making your application...

still, if you identify those as an importent aspect of your setup that 
needs proper and consistent implementation, then you resort to good OOP 
and/or AOP to get that done...

I like how the 'do one thing right' focus in spring makes that 
distinction clear again.

> In the end, this file looks like an XML serialization format for POJOs.

which it is.

> These issues seems to me somehow solved by Pico/NanoContainer:
> - a concrete class can be associated to an interface, and then becomes 
> wired to all dependencies of this interface. No need to explicitely 
> declare the wiring.
> - constructor dependency injection expresses the required dependencies 
> (can check that no wiring is omitted)

I think I read about similar support in spring dunno if it's all that 
interesting though: why would you favour a reflection mismtach exception 
(couldn't find the constructor taking the provided set of args) over an NPE?

It's really matter of how you look at things: javabeans always had zero 
arg constructors, setters, property-editors, serialization (to XML) as a 
way to deal with 'customizing'

> I have the feeling Spring can be used for small sets of components, but 
> can it be used for the full assembly of large systems like Cocoon?

well, have to dig some deeper, but if we could find a way to structure 
and componentize (e.g. by 'blocking' things up using jmx??? although I 
lack the JMX experience to understand how things would work there) then 
we're half way there...

the other half in my head is handling decent classloading (which spring 
doesn't do and where I don't know the support jmx is offering)

and if I'm allowed to my own personal wild-thoughts then let it please 
be done based on some merlin-like deployment that will get you the jars 
from a maven repo

there is loads of good ideas out there, spring does a good job in doing 
one thing well, in the same filosophy we must be able to incrementally 
make some other good things available...

> Thanks for your answers.

and more questions....

> Sylvain

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message