Re: [Springframework-rcp-dev] [Spring Desktop] ideas for theDesktopversion

[Larry S. <lst...@au...>]

Hi Everyone,

It's been a long time since I've participated, so hopefully my 
viewpoints won't be too dated :-)

IOn the issue of OSGi, I would argue along the lines of Jim Moore - do 
it later when we find a pressing need that can't be solved without it, 
and work to cleanly modularize our codebase to ensure no cyclic 
dependencies etc.

To Kevin's question about the decision to not use DI for the core 
services (and to use a service locator pattern instead), the main reason 
that it came about was due to the massive amount of XML that would be 
required to inject the desired services into every object.  
Additionally, the number of dynamic objects that need access to platform 
services can be huge, and there was no good way to get the quickly wired 
in.  You either had to resort to intermediate factories that could be 
DI'd and have the factories wire in the services (and that required 
extra interfaces on the created objects to accept the injection), or 
invent some other similar scenario to get the services into the dynamic 
objects.

I'm still of the opinion that a service locator singleton (with a 
pluggable implementation) provides benefits and doesn't require the 
complexity of having to have a declarative model that knows about every 
single kind of object that might come into existence during the life of 
the application.  But, I'm always ready to be educated out of any 
antiquated notions I may hold if someone can show me how the wiring of 
dynamic objects can be handled in a simple way (very little XML and 
minimal biolerplate).

Learning curve and the amount of XML you have to write in order to get 
your application running were two significant factors we faced with the 
adoption of Spring RCP.  I personally feel that requiring new app 
developers to learn yet another complex piece of machinery (OSGi) in 
addition to all the rest of Spring Rich (which is significant by itself) 
would not be beneficial to the project's uptake.

Just my $.02 worth - boy, I hate how the current economy makes my 
opinions worth less each month :-)

Thanks,
Larry.

Kevin Day wrote:
> Eclipse is entirely built on top of OSGi bundles (in fact, Eclipse's 
> Equinox project is the baseline OSGi implementation).
>  
> From my perspective, I don't think that OSGi is necessarily 
> appropriate for a lot of GUI apps (although I do think it probably has 
> more applicability than we might give it credit - even a simple music 
> player could benefit greatly from a pluggable codec system).  From my 
> perspective, the *module* approach is the important thing.  And if we 
> are going to do modules, we might as well do something that is at 
> least upwards compatible with OSGi.  Certainly, the full OSGi 
> functionality is not necessary for most apps - I actually a think a 
> very small subset would be appropriate - and this sub-set could be run 
> inside AND outside an OSGi container with a little bit of Spring DI magic.
>  
> Here's the basic premise:  Because OSGi supports dynamic loading and 
> unloading of modules, they have been forced to address the issue of 
> dynamic dependency management.  The core result is that modules do 
> *not* interact directly with each other.  Instead, they either locate 
> other modules (using a service locator type pattern), or they have 
> those modules injected (using the whiteboard pattern).  Time has shown 
> that the dynamic dependency injection pattern is more reliable, easier 
> to test and results in more flexible systems (allowing modules to be 
> dynamically loaded and unloaded without impacting the operation of the 
> application).  In dynamic environments, it also makes service 
> consumers much, much simpler to write (there is almost no boilerplate 
> code - this is all refactored up into the framework).
>  
> Most importantly, modularity forces better design practices overall.  
> There are absolutely cases where functionality is so closely tied 
> together that it will always reside in the same module - but I suspect 
> that  a lot of that sort of thing is occuring in the current code base 
> because of the use of service locator type patterns instead of 
> dependency injection (could be wrong on that, and I certainly don't 
> want to step on any toes - but sometimes it's healthy to have an 
> outsider question a design decision :-)  ).
>  
>  
> This actually raises an interesting question that I hope someone with 
> a deeper history in the Spring-RCP project can answer:  How did the 
> original decision to depart from Spring IOC/DI come about in the RCP 
> project?  Was it b/c of objection of creating and maintaining tons of 
> Spring xml files, or was there some other reason?  I think that maybe 
> by understanding this, we may learn many of the things that need to be 
> considered as we have the current discussion.  It's super easy to set 
> back at the end of years of development and question design decisions 
> that were made early on - and in doing so, it's easy to miss some 
> extremely important detail that went into the decision.
>  
> - K
>