Marc Portier wrote:
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,
"abstracted"? What do you mean?
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 point is the wiring: in cocoon.xconf, you only declare components, now how they should be wired together (this is handled by manager.lookup()). Declaring the full wiring leads to a bigger configuration and the knowledge of what wires need to be set up.
- 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
Ok, sounds good.
- 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)
I don't agree with this: with Avalon, the container will tell you it doesn't have a component that is looked up. So you know that a component is missing in the xconf.
If you get a NPE from somewhere deep in the code, how do you know that it's because of a missing component. Or your beans may have some consistency check code, but where does it have to be called, if the framework doesn't have the equivalent to initialize()?
That's why I like more construction injection for _required_ dependencies, as the container can check that it's able to pass non-null values for each of the constructor parameters. And you still can use setter injection for optional dependencies.
Or else, we need some class attributes (or bean PropertyDescriptors?) for the container to know which of the wirings are mandatory.
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
Mmmh... aren't you using auto-wiring each and every day with Cocoon?
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...
I understand your point, but don't you think this leads to reinventing the wheel and duplicating container-level code in many places of the 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.
(playing the devil's advocate) So what's the point of Spring then? XML bean serialization has been around since 1998...
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?
Simply because the reflection mismatch exception will be raised by the container, and hence in a controlled way or at least with a meaningful message indicating a configuration problem, whereas the NPE can happen way later at runtime and be very difficult to related to some configuration problem.
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 agree. But JavaBeans is IMO an overused term here, as components define services, whereas GUI beans (this what JavaBeans where invented for) are data objects.
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...
Spring does one thing well, but I'm really wondering if this one thing is sufficient for something like Cocoon. Note that I really would like to be proven wrong, as I love new-generation containers that don't impose a specific API to write components. But I'm wondering if they can be used to build large-scale component applications.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
