let me try to clarify: OSGi is by no means a "must" in Spring nor is it tightly coupled into it. Instead it is a nicely developed and well integrable extension to the core and lightweight Spring IOC container.
Spring eases plug-in development based on OSGi as this technology has several advantages:
- runtime platform independence (you can use e.g. eclipse, apache felix, Spring dm server and others as execution environment)
- automated dependency resolution among OSGi bundles (say, e.g., a particular auctioneer plugin requires a particular auction language plugin)
- well-defined public method exposure from one OSGi bundle to the outside world
- the ability to run several different versions of an OSGi plugin in parallel (say, simple consumer plugin v.01 and simple consumer plugin v0.2 where both versions still have most of the classes identical).
A good example for an OSGi implementation that is *not* a monolithic server with its own plugin architecture is running on your computer. It's your Eclipse IDE, which, strapped from all of its plugins (all of them are OSGi bundles), has barely any functionality other than opening files and showing them in a file viewer window. Also eclipse demonstrates bundle dependencies as e.g. the repast plugin requires installation of (and invokes functionality from) the groovy plugin in order run properly.
Still, there is no hard requirement to use OSGi for PowerTAC as part of Spring Container and actually it would be even easier for us in the first step not to use that functionality. Instead we can link the different pieces of code (OSGi bundles are also only jars with a special Manifest.MF file in it) to each other during configuration time using the xml or annotation-based Spring configuration with its dependency injection by type or by name and a common lib directory. In future there is a smooth transition to OSGi possible if we think it provides enogh value-add sometimes later on.
In the second part of your mail you suggest switching to Excalibur as an alternative. I don't see that as an good alternative to Spring. Excalibur's main selling point is leightweightness and that's pretty much it. The team page says that "There are no developers working on this project." and "There are no contributors listed for this project." (http://excalibur.apache.org/team-list.html).
The last update to the excalibur webpage is from July 31, 2009 - about 1.5 years ago. In contrast, things I really like about Spring include:
-- Lightweight, very well documented and very actively developed IOC core container with many (optional) and very nicely integrated extensions (see below) that has become the de facto standard in Enterprise Java World (just file a query to Gulp and search for spring expertise...)
-- optional and very nicely abstracted JMS / AMQP / XMPP support
-- optional Pipe-and-Filter Support (Spring Integration - did you have a chance the attend the Spring Webinar on this today? If not it will be available as video by Monday next week.)
-- Scheduling / Periodic job execution (Spring Core)
-- AOP (Spring Core)
-- optional transaction support (Spring TX - note that transaction support is not limited to database operations. You can actually wrap any sequence of commands into Transactions and roll-them back collectively if something fails on the way)
-- Automated XML <-> POJO marshalling / unmarshalling (Spring OXM)
-- optional database integration layer (Hibernate or JPA OR mapping)
-- optional MVC extension (Spring MVC)
-- Excellent Tooling Support for Eclipse, Netbeans and IntelliJ
-- Optional OSGi support if we might find that useful in future
These advantages outperform the Excalibur ones on every dimension.
What's next? We currently write the proof-of-concept we promised showcasing an example of spring <-> repast integration and push that to launchpad by the weekend.
Am 18.11.10 04:27 schrieb "John Collins"
> Carsten -
> I don't feel like we finished the conversation today about the use of
> OSGi bundles. Everything I've heard so far tells me they are a nice
> solution for a different problem than the one we are trying to solve,
> and that some features, like separate classloaders, to me are a serious
> downside for our application. We are not building a server to host a
> number of separate applications that need to be individually
> hot-installable. I've worked with systems that had this feature, and my
> experience tells me that if we must use it, then our best bet would be
> to build the entire server in one big module, which of course would then
> need its own plug-in architecture.
> There is another, much lighter-weight IOC container that does not force
> you into the separate-classloader trap - it's called Apache Excalibur,
> and it's what we've used as the foundation for MinneTAC. It's APIs are
> used (at least in MinneTAC) only during the startup process. After that,
> modules can hold direct references to each other, and if I pass an
> object from module A to module B, then module B can recognize it without
> having to load another copy of its class. With separate classloaders, we
> will have to include copies of all the types used for data interchange
> in every single module, and we'll have to make sure when we change one
> that we update all the modules. What a mess.
> I really need to know why you are taking us down this road. At this
> point, I am convinced it's a bad decision.
> I posted a question on this issue in the Development Roadmap talk page
> Could you please write a clear explanation there of why this is really a
> good idea?
DisclaimerDe informatie verzonden in dit e-mail bericht inclusief de bijlage(n) is vertrouwelijk en is uitsluitend bestemd voor de geadresseerde van dit bericht. Lees verder: http://www.eur.nl/email-disclaimer.
The information in this e-mail message is confidential and may be legally privileged. Read more: http://www.eur.nl/english/email-disclaimer.
|Free forum by Nabble||Edit this page|