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] Cocoon component container and excalibur
Date Thu, 03 Jun 2004 06:26:53 GMT
Antonio Gallardo wrote:

>Hi:
>
>I need to accept I am lost in the component containers.
>
>Cocoon is migrating to a new container architecture. The question
>remaining in my mind is: How to develop components right now? In the sense
>that we don't want to write components for ECM, because it is almost dead.
>  
>

ECM isn't dead. Excalibur is now a top-level Apache project that holds 
both Fortress and ECM. This means that their users and developpers now 
have a quiet place to continue work on it.

>How to avoid to rewrite when the new component container in Cocoon will
>raise?
>  
>

You have to consider two very different things:
- the Avalon framework APIs (LogEnabled, Serviceable, Configurable, etc.)
- the container that implements the framework behaviour

Although the container implementation may change, there's a strong 
commitment to the framework APIs as this is what we've used and invested 
in for many years.

So even if a new container comes with new features (e.g. IOC type 2/3), 
it will also have to implement the Avalon framework behaviour. We cannot 
trash years of use of this API overnight.

>People wanting to write new components now, hope they will be deployable
>in the next Cocoon container or with less changes will be full deployed
>outside a legacy container as it was promised. Where is the path to that?
>Exists it at all?
>
>I am facing the above question now and I decided to make this post,
>because i think other people have the same problem. Or it is only me?
>
>Need we to wait until the new Cocoon container get life? Am I missing
>something?
>  
>

My opinion is: write your components on the Avalon framework API right 
now. We don't have something else now, and that something else, when 
available, will have to implement these APIs, even if in the form of 
legacy compatibility layer.

>The things are even worse: some people suggest Web services as the right
>path, others said that Flow with Javascript is a nowhere path. Don't miss
>the pressure of EJB vs. lightweight containers, etc.
>  
>

Mmmh... you're mixing a lot of things here:
- web services are certainly not a solution for calls between components 
inside the JVM. Way too much overhead that will make the system totally 
unsusable.
- Flow/JS suffers from the legal situation of Rhino+cont and the 
difficulty to merge the fork into the Mozilla trunk. I suggested as a 
solution to use JavaFlow to instrument Rhino-generated bytecode. That 
would lead to a unified code base allowing flow to be written in any 
language compiled to a .class, i.e. Java, JS, Groovy, Jython, etc.
- EJB vs lightweight containers is definitely out of Cocoon's scope, as 
this choice has to be made to implement the business logic. I understand 
this adds to the confusion though.

I hope this clarified things a bit :-)

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