cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: [RT] Spring+JMX == Real Blocks?
Date Mon, 12 Jul 2004 16:23:31 GMT


Sylvain Wallez wrote:

> 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?
> 

I meant 'grouped' into more abstract things, so you don't need to know 
all the detail thingies....

but that is just matter of grouping and clustering as in good 
programming desing, no?

>> 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 

euh? it is handled by the code that does the manager.lookup(), meaning 
that your component itself needs to hold that part of the configuration 
logic

> configuration and the knowledge of what wires need to be set up.
> 

yeah, sort of, but on the other hand: it's all in one place now

>>> - 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.
> 

think so too, just needs more wild thinking and somebody doing :-)

>>> - 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 

Well, I was actually refering to the 'programming error' of not doing 
the lookup: how different is that from the 'configuration error' of not 
providing it?

same net end result?

no compiler is going to tell you, and it's going to be a runtime issue 
either way

> is missing in the xconf.
> 

I might be missing something, but if we take this one step further: what 
do you _do_ when it is missing in the xconf?

and how different is that to detecting NPE?

(probably too pragmatic?)

> 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 

what else could it be?

so you 're a component in need of some reference, and it's not there:
then go barf about it, or should it be simpler?

> consistency check code, but where does it have to be called, if the 
> framework doesn't have the equivalent to initialize()?
> 

there is: you can specify some init method (no args) or even implement a 
framework-specific interface (the latter not recommended for obvious 
reasons)

> 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.
> 

hey, makes sense, would fit the filosophy, I'll look around for those.

>> 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?
> 

am i?

autowiring as I understand it is about automatically getting your 
setters called with argument-beans from the configuration that have 
matching types: kinda: ah I see you have a setter for 
domain.whatever.Model and I happen to have a spare one over here...

it might look like our Service.ROLE 'accidentally' being the 
class.getName(), but I think it is slightly more introspecting magic 
here (and I'm not entirely fond of it, unless maybe again we could have 
small separated local configs that together build up larger more complex 
stuff)

>> 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?
> 

yes and no:
I agree that it should be done once and well, but in spring's vision 
it's not their job (again: do one thing well...)

>> 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...
> 

the point is: using it :-)
(not just knowing/noting that it is there)

spring makes all those old ideas usuable and pushes them up to the 
server side (pushing ejb's as we know them out a bit)

well, that and (next to the pure bean support and DependencyInjection) 
they have a well featured transaction manager, a well thought of jdbc 
abstraction layer that really simplifies things, and nicely hosts or 
mapping tools as well... and they were able to bring Dynamic Proxies 
(also there since jdk 1.1, no?) under more common knowledge and use 
(probably mostly by jumping on the AOP marketing train, but hey)

>>> 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.
> 

got that, you would go for that init() method then to check the state, fine

and (only) if you want to (additionally) avoid runtime reconfiguring you 
would need to throw some IllegalStateException when the setter is called 
a second time

but again, there exists constructor injection too, it's just not the 
full javabean vision, and hard core springers don't seem to be missing it

(taling of which: you must agree that there have to be at least a 
*couple* of areas inside cocoon where the answer to the newbie is also: 
it might be different but it works for us, just go with the flow ;-))

>> 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've never understood this GUI only focus for javaBeans

I remember my first JavaBean example being a temperature-class that just 
emmitted some valueChangedEvents, no GUI at all... until some later in 
the app...

I also remember the long time gone Bean-wiring app from Sun which showed 
quite some none gui uses of the idea as well

(ah what was the name? JavaStudio? it followed sun's preferred software 
roadmap: great noise: 1.0 then next: discontinued :-))

>>> 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 

true, it's most likely not enough, but it seems more fun to think about 
incrementally adding just what you need, then digging through all the 
stuff one doesn't need?

(maybe the large and complex beast 'under' cocoon is the largest reason 
for our inability to refactoring it and prepping it up for the next 
features we need: being mostly blocks, no? - no need to flame: I really 
don't know what I'm talking about, it just *feels* that way from a 
distance, hoping more knowledgeable people can comment there)

> 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.
> 

I honestly don't want to shape the discussion into a 'should spring be 
used for redoing cocoon' discours, since I think cocoon and avalon kinda 
shaped each other in terms of what was needed and thought as a best 
match to solve...

so no real benefit of doing that exercise again in a spring filosophy 
(no other benefit then to proove it's possible, well: yawn!)

thing to note though is that spring shows us how refreshingly simple 
things can be (and even more a lesson: how refeshing the simple things 
in life are), and we must be aware that up to today hooking up business 
logic inside cocoon kinda urges people to go down the avalon path which 
might be great for all cocoon needs but quite one step too far for what 
their logic needs...

from that angle I guess Ugo's spring-hibernate sample in the wiki is the 
good route on short term at least.

regards,
-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo@outerthought.org                              mpo@apache.org

Mime
View raw message