cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ugo Cei <>
Subject [RT] Spring+JMX == Real Blocks?
Date Fri, 09 Jul 2004 15:41:23 GMT
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".

This particular WT arose from following this thread [1]. Be sure to 
read the whole thread and not just the message I am linking to. Then 

1) Spring is a very good container, better in many respects than Avalon 
(just IMHO, no flames please)
2) Geronimo (and JBoss too) use JMX to manage and hot-deploy and 
-undeploy components, so why shouldn't we? It was already proposed by 
Thor H-W in the famous "On building on stone" thread ([2]).

You see, when I work with Spring I feel the same excitement I felt when 
I started working with Java, Servlets, XML+XSL-T, Cocoon and Hibernate. 
Until now, my instinct hasn't failed me once ;-). I have even 
considered dropping Cocoon and using Spring's MVC exclusively for some 
web applications, but I'd hate doing without Flowscript and Cocoon 

Couldn't "Real Blocks" be Spring deployment units inside a JMX 
container? Of course, we shouldn't tie ourselves to Geronimo, but we 
might reuse parts of its JMX stack.

Now, what would be the most effective way to run this course, assuming 
there's someone crazy enough to run it, beside me? I think we shouldn't 
be dragged down by the desire to maintain too much 
backward-compatibility. We should instead try to do a mostly 
"clean-room" design and implementation, aiming for an initial milestone 
that would provide nothing more than:

1) a (possibly simplified) treeprocessor
2) a handul of sitemap components (a FileGenerator, TraxTransformer and 
XMLSerializer should be enough to put up a working pipeline)
3) flowscript (would be great, but first I'd stop and think whether we 
want to continue supporting JavaScript as the preferred language, given 
the situation with Rhino).

Since this is a "skunkworks" project, I wouldn't want someone to think 
this is going to be Cocoon 3 or 4 and I'd like to propose a new name 
for it. How about Butterfly (what do Cocoons turn into in Spring, after 

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




Ugo Cei -
View raw message