cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [RT] Spring+JMX == Real Blocks?
Date Mon, 12 Jul 2004 14:51:52 GMT
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 }


Mime
View raw message