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

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

1) The principle reason for the ApplicaionServices singleton was for
substantial convenience.  For example, creating something like a wizard
dialog means calling "new" on it, so it's not coming from Spring, and doing
all the DI on it manually could be cumbersome (especially since the calling
object would need to know everything that it would need to pass in and get
that DIed first).  Fortunately, this is not difficult to solve: Spring MVC
has the same kinds of issues and solves it very cleanly, if you're familiar
with the patterns there.

2) Agreed, but let's go for the "this solves an immediate need" modularity
stuff first.

3) Great idea.


On Sun, Jul 6, 2008 at 10:38 AM, Arne Limburg <Arn...@ar...> wrote:

> Hi to all,
>
> 1. Of course Lieven is right that we should not use OSGi, if we just
> want to remove our service locator singleton.
> I wonder why we couldn't simply remove the service locator and directly
> inject the needed services to the needing beans?!
>
> 2. There are at least three use-cases where Spring-Desktop could benefit
> from OSGi:
> a) OSGi provides a mechanism that could be used to dynamically plug in
> business modules into a Spring-Desktop-Application. Spring-Deskop should
> provide a mechanism to add and remove menu or toolbar entries
> dynamically on startup or shutdown of these business bundles (i.e.
> entries in the "New"-submenu. The bundles could register Actions as OSGi
> Services. And the menus must be aware of that.
> b) OSGi service-resolution may be used to dynamically switch
> implementations of the application-services. We could provide a bundle
> with default-implementations and if needed someone could register a
> bundle with a higher ranking, forcing to use his implementation.
> c) With OSGi we could provied an update-mechanism to update parts of the
> application without needing to restart it.
>
> 3. Besides the OSGi debate Spring-Desktop should definitely provide a
> Spring bean-scope "window" to be able to configure commands in the
> normal application-context (if needed with scope "window") and get rid
> of the separate commans-context.
>
> Regards,
> Arne
>