Re: [Springframework-rcp-dev] [Spring Desktop] whiteboard vs lookup

[Jim M. <moo...@gm...>]

Kevin, could you please give an example of how we can get rid of the
ApplicationServices singleton with the whiteboard pattern allows access to
capabilities such as ApplicationObjectConfigurer or RulesSource?  (Using the
ApplicationContext as the container in lieu of OSGi.)  It's not clear to me
how that would work.


On Wed, Jul 2, 2008 at 1:14 PM, Kevin Day <ke...@tr...> wrote:

>  BTW - the email archive for this list seems to be dead as of 6/17/08:
> http://sourceforge.net/mailarchive/forum.php?forum_name=springframework-rcp-dev -
> is something going on?
>
>
> I completely agree on the comments re: modules.
>
> This is still a rough idea, but I'm thinking that while many apps have no
> need for per-module class loaders, hot swappable modules, module life cycle
> management, etc... there is still a big advantage from a coding practices
> perspective of using modules (JRE 7 is probably going to be introducing
> module as a scoping feature).  In these types of apps, the only OSGi-type
> event that would need to be fired is ServiceEvent.REGISTERED - and this
> would all happen at startup (i.e. at the time of dependency injection).
>
> Maybe there is a way to introduce the module concept, and do it in such a
> way that apps that *want* to run in an OSGi container can do so by just
> ensuring they have the correct entries in their jar manifests (and using
> SpringDM).
>
> This places a requirement that the Desktop framework be designed in a
> manner compatible with SpringDM (keeping sub-systems modularized, not use
> global service lookups if at all possible, and possibly add required info to
> the jar manifests for apps that do need to run in an OSGi container).
>
> Interestingly, one of the tenets of the whiteboard pattern is that objects
> that are traditionally thought of as services are actually not registered as
> global services.  Instead, the listeners of those services are registered as
> services.  As listener objects are registered with the container, the
> service is notified about their presence and adds the listener to itself
> (instead of the more traditional approach of having the listener look up the
> service, and call addListener() ).  This, I think, makes a strong case for
> not using global service lookup in the traditional sense.
>
>
> Given the above, I wonder if the module break out of the Desktop project
> should be aligned along functional lines (and possibly divided with modules
> for interface, implementation and possibly GUI).  I could see having
> separate packages for jdk6 specific stuff (maybe), but a totally separate
> module seems to cut across concerns in an odd way.
>
> - K
>
>