Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
So GBeans seem like the only serious alternative. I don't know enough
about GBeans to be able to evaluate it. But its much earlier in its
development, it is not a standard and there is only one
implementation, so it should IMO have a considerable technical
advantage to OSGi to be used instead.
You forgot that since GBeans used in Geronimo, basing Cocoon on GBeans
means easier integration with/into Geronimo, which is significant
advantage.
Well, is it really?
Also I would assume that the fact that Eclipse is based on OSGi will
mean that it would be much easier to write various Cocoon tools if we
base Cocoon on OSGi.
The fact that Eclipse is based on OSGi, does it mean Cocoon will be
doggish slow if it is also based on OSGi, as Eclipse already is? It
might be FUD as I've not seen OSGi, but I've seen Eclipse.
Actually, OSGi is a key point in the performance improvements in the
upcoming Eclipse 3.1. It was introduced in 3.0 but many plugins were
still written on the previous kernel API, and the more plugins move to
the OSGi API, the more startup time increases and memory used decreases,
by allowing on-demand loading of plugins.
See also:
-
http://download.eclipse.org/eclipse/downloads/drops/S-3.1M7-200505131415/eclipse-news-all-M7.html
(second item)
- http://www.eclipse.org/eclipse/development/performance/index.html (the
"performance bloopers" page is a very interesting read)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
