Gerolf Seitz wrote:
hi,
i was rather surprised about the heavy usage of spring for wiring the
different
parts of the system together.
imho, OSGi would be a much better fit, given the there are lots of
extensions.
so you could enable/disable/install/... a new feature/service to the server
while it's running, etc...
various parts (eg. NamespaceHandlers) could be put in a separate bundle
and only those bundles that are really needed have to be installed.
i just think the dynamic nature of OSGi would be a better fit than
hardwiring
everything in a spring-config.xml file.
wdyt? do you think it's worth the effort?
yes. no. yes. eh... let me explain my thoughts on this (simplified, to
keep it short):
Spring is a feature-rich component framework.
OSGi is a service framework and runtime.
Where Spring stops, OSGi starts. But without a decent component
framework, OSGi is reduced to bundles and classpath separation and I
would really miss Spring features.
So, Spring and OSGi are essentially orthogonal to each other.
(You see, I am pretty much on par with
http://static.springframework.org/osgi/docs/current/reference/html/why-spring-dm.html
)
In the first place, we need components wired together. This is where I'd
really like to stick with Spring. We really don't need to separate the
core (Vysper as it is now) into bundles (right now). We will profite
from fine-grained lightweight pojo components.
Then, there are the more loosely developed, deployed and
runtime-coupled, optional extensions. For those, there is already a
module package which is currently only a design study. This is the
place where OSGi is certainly a better fit than any self-developed
module/plug-in/extension framework.
I could write books about this topic, so if this is a too short answer,
please let me know ;-)
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
