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 }
