cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter royal <>
Subject Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Date Thu, 22 Jul 2004 01:10:47 GMT
On Jul 21, 2004, at 7:28 PM, Stefano Mazzocchi wrote:
> Ugo Cei wrote:
>> Since I'm getting more and more bored with my daytime job, I ended up 
>> doing something:
>> Comments are welcome, flames > /dev/null.

have you considered picocontainer at all? i would *LOVE* to see the 
core shuffled about. i want to be able to nest the containment of 
cocoon's core objects in order to share them between multiple cocoon 
instances, and being built upon an open container platform helps that a 

> You are proposing Springs which is a rather simple, bean based, 
> dependency-injection based framework.
> Alternatives are:
>  - Kernel (written by Pier and designed by Pier and myself)
>  - Merlin
>  - Geronimo Container (also compatible with Springs, from what I hear)
>  - Fortress
    - Pico/Nanocontainer

> My (obviously biased) view is that cocoon is both a production 
> software and a research project, depending on other communities for 
> our critical foundations turned out to be dangerous.
> So, the question is: what do we buy in using somebody else's code 
> instead of maintaining our own?

I would prefer to see somebody else's code. I think it depends on what 
one's view of cocoon is.

Is it:
  A) An application framework that you run as a servlet
  B) A set of components that you can integrate into your application

I take view B, and thus the ease with which Cocoon can be integrated 
into larger platforms is critical.

We have this with Avalon today. If you use the sevak component from 
avalon, <>, you 
can make a servlet Servicable. You can then run your sevak component 
inside of Phoenix, and voila, you can have cocoon components look up 
Phoenix blocks!

By going with an "open" container platform ("open" being that the 
license is compatible and it is just a container / component contract, 
explicitly designed for reuse), ease of integration with other 
component systems is that much easier.

While we can do that with our own container, I think it comes down to 
which is more work:

  * Maintaining your own container
  * Dealing with an external containers development priorities and 

With avalon, the latter has been more work. I don't think a sour avalon 
experience should turn us away from looking at containers from other 
normal communities.

Really, I'm +1 on pushing the platform forward, whichever direction it 
is.  Its the progress that's important :)

View raw message