Menu
▾
▴
Re: [Springframework-rcp-dev] [Spring Desktop] whiteboard vs lookup
|
From: Kevin D. <ke...@tr...> - 2008-07-07 18:38:40
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content="MSHTML 6.00.2900.3059" name=GENERATOR></HEAD> <BODY leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2> <DIV> </DIV> <DIV>Your comment in a more recent email helped clarify the current state of things quite a bit:</DIV> <DIV> </DIV> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <DIV>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.</DIV></BLOCKQUOTE> <DIV> </DIV> <DIV>Much of Spring RCP could be handled using startup DI, but there may be cases where dynamic loading (and injection of resources) would be desirable - the example you provide (creating a new dialog) is a very good one.</DIV> <DIV> </DIV> <DIV>The primary difference between the service locator and the whiteboard pattern in the ApplicationServices situation is that ApplicationServices doesn't provide registration event notification and listener services. In the case of creating a new dialog, for example, consider how things would be simplified if we registered the new dialog with ApplicationServices (or some equivalent that supports registration notification services). Actual service providers (say an implementation of RulesSource) would receive notification that a new object has been registered that is interested in that particular RulesSource. The RulesSource would then inject itself into the dialog. In practice, the actual registration listening and injection could be factored out (this is, I believe, some of what Spring DM does), simplifying things even further. Creation of a new dialog then consists of creating the dialog object and registering it with the framework (which the n triggers all of the dynamic DI and processing).</DIV> <DIV> </DIV> <DIV>One interesting side effect of this is that the actual RulesSource instance is never registered with the service registry. It's literally impossible for some other module to get access to the RulesSource by interacting directly with the registry. Instead, the other module must register a consumer of that particular RulesSource and allow the instance to be injected during registration. I believe that this is a core feature that encourages modular design, and is the reason I brought the pattern up in the first place.</DIV> <DIV> </DIV> <DIV>As another example, you can imagine a service for providing resource injection (ResourceInjector) from properties files. This service would never actually be registered with the service registry. Instead, at startup the ResourceInjector gets mapped as a listener for all 'Dialog' objects that get registered with the registry. When the registration event occurs, the resource injection can take place (in this case without even calling a setter on the Dialog, although that could certainly be an additional option that could be exposed in more complex use cases).</DIV> <DIV> </DIV> <DIV>The ResourceInjector instance would need to be created at app startup. And it would need to be registered as a listener to the service registry. I think that defining which class the ResourceInjector instance actually is, and how the listeners should be configured is where declarative configuration comes into play in this scenario.</DIV> <DIV> </DIV> <DIV> </DIV> <DIV>What I'm not clear on is how much this complicates the declaritive/configuration portion of the system. It certainly simplifies the actual code, but if the tradeoff is reams of XML, then I'm not particularly interested.</DIV> <DIV> </DIV> <DIV>- K</DIV> <DIV><BR> </DIV> <DIV> </DIV></FONT> <DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma"> <DIV>----------------------- <B>Original Message</B> -----------------------</DIV> <DIV> </DIV> <DIV><B>From:</B> "Jim Moore" <A href="mailto:moo...@gm..."><FONT color=#0000ff><moo...@gm...></FONT></A></DIV> <DIV><B>To:</B> <A href="mailto:spr...@li..."><FONT color=#0000ff>spr...@li...</FONT></A></DIV> <DIV><B>Cc:</B> </DIV> <DIV><B>Date:</B> Wed, 2 Jul 2008 22:25:25 -0400</DIV> <DIV><B>Subject: <U>Re: [Springframework-rcp-dev] [Spring Desktop] whiteboard vs lookup</U></B></DIV> <DIV> </DIV></DIV>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.<BR><BR><BR> <DIV class=gmail_quote>On Wed, Jul 2, 2008 at 1:14 PM, Kevin Day <<A href="mailto:ke...@tr...">ke...@tr...</A>> wrote:<BR> <BLOCKQUOTE class=gmail_quote style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"> <DIV><FONT face=Arial size=2> <DIV>BTW - the email archive for this list seems to be dead as of 6/17/08: <A href="http://sourceforge.net/mailarchive/forum.php?forum_name=springframework-rcp-dev" target=_blank>http://sourceforge.net/mailarchive/forum.php?forum_name=springframework-rcp-dev</A> - is something going on?</DIV> <DIV> </DIV> <DIV> </DIV> <DIV>I completely agree on the comments re: modules.</DIV> <DIV> </DIV> <DIV>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).</DIV> <DIV> </DIV> <DIV>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).</DIV> <DIV> </DIV> <DIV>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).</DIV> <DIV> </DIV> <DIV>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.</DIV> <DIV> </DIV> <DIV> </DIV> <DIV>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.</DIV> <DIV> </DIV> <DIV>- K<BR></DIV> <DIV> </DIV></FONT></DIV></BLOCKQUOTE></DIV><BR> <STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE> <FONT face=Tahoma size=2> <DIV>-------------------------------------------------------------------------<BR>Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!<BR>Studies have shown that voting for your favorite open source project,<BR>along with a healthy diet, reduces your potential for chronic lameness<BR>and boredom. Vote Now at http://www.sourceforge.net/community/cca08<BR><BR></DIV></FONT> <STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE> <FONT face=Tahoma size=2> <DIV>_______________________________________________<BR>Springframework-rcp-dev mailing list<BR>Spr...@li...<BR>https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev<BR><BR><BR></DIV></FONT></BODY></HTML> |
