after sleeping one night over it, i actually came to about the same
conclusion ;)
but thanks for elaborating it...
  Gerolf

On Fri, Apr 18, 2008 at 8:57 AM, Bernd Fondermann <[EMAIL PROTECTED]>
wrote:

> 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]
>
>

Reply via email to