Re: [Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-165) Eliminate need for special bean names when configuring Application and ApplicationServices

[Rogan D. <ro...@da...>]

Arne Limburg (JIRA) wrote:
> 
> 3) You are right. I have upgraded my patch.
> 
> 4) It is great for prototypes.
> 
> I don't think you have to refactor the advisor. These bean names are
> not magic anyway. You can change them via the menubarBeanName and
> toolbarBeanName properties in DefaultApplicationLifecycleAdvisor.
> With this you can also change the toolbar without the need of
> specifying any menubar. You only need to include my
> commands-context.xml into yours, provide your own toolbar-bean and
> set its name in the advisor. You can also add new menubar entries by
> specifying a new menubar bean, but reuse the fileMenu, editMenu,
> windowMenu and helpMenu.
> 
> But anyway this cannot be the final solution. We need a more
> pluggable architecture for the commands context. What about a special
> menubar bean that acts as a beanpostprocessor to search for menubar
> entries? We then would need only a marker interface like MenubarEntry
> for the commands that should be plugged into the menubar. Same could
> go for the toolbar and the new-menu. You then would just have to
> specify your additional menus, new-commands and toolbar commands and
> could use the default-commands-context for the rest. We then should
> provide the ability to specify multiple commands-contexts in the
> advisor.

Hi folks,

I have been considering what would be required in order to enable OSGi 
and Spring RCP to interoperate. The basic approach would be to provide 
the application "shell", with a number of plug points, and allow OSGi 
providers to register things like views/view descriptors, 
commands/command descriptors, etc.

The thing that would need to change a fair amount is the 
commands-context.xml that we have currently. At the moment, each 
application window creates a whole new context by reading 
commands-context.xml. This means that setting beans to be singletons, 
etc is ineffective, since the bean is only a singleton *within that 
context*, and the context is sourced anew for each application window.

One approach might be to introduce CommandDescriptors, from which 
instances of the described Command are created, similarly to the 
ViewDescriptors. This would allow OSGi plugins to register a 
CommandDescriptor in the appropriate place, and this would still work 
for multiple app windows.

Any comments? Am I overcomplicating things?

Rogan