Menu
▾
▴
Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version
|
From: Kevin D. <ke...@tr...> - 2008-07-02 17:14:20
|
<!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>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">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 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> Tue, 1 Jul 2008 23:20:43 -0400</DIV> <DIV><B>Subject: <U>Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version</U></B></DIV> <DIV> </DIV></DIV>Heya, everyone. Sorry for jumping into this discussion late.<BR><BR>I prefer Claudio's distinctions for breaking out the modules. In any case, we need to make sure (like Spring) that there's never a circular dependency between packages so that things can easily be broken apart later if needed.<BR><BR>Spring 3.0 will also be dropping JDK1.4 support. Going to Java 5 just makes sense -- especially for a desktop app. (In fact it's arguable that we should go to Java 6 given all the desktop improvements they made.)<BR><BR>There's a reason no Spring example shows injecting a Logger. The nature of logging and the logging libraries means there's no real benefit to doing so. Also, in general commons-logging is a bad thing (especially in multiple classloader environments), which is why slf4j exists, but you can write to the commons-logging API and use slf4j as the implementation. That's what the Spring does on the Sp ringSource Application Platform (S2AP), for example.<BR><BR>I love the idea of new XML configuration. A couple of comments on the examples:<BR><BR><bean id="someBean" class="foobar"><BR> <property name="prefs"><BR> <desktop:prefs scope="user|system" path="path/to/preferences/node"/><BR> </property><BR></bean><BR><BR>It's not clear from the example, but Spring already has support for the scoping capability (via aop:scoped-proxy) as described in section 3.4 of the reference manual. I assume "user" scope would be defined based on a Spring Security SecurityContext and "system" would be a standard singleton? Having the custom XML element would nicely hide those details from the user.<BR><BR><desktop:view id="someView" viewClass="com.acme.foo.bar.SomeView"><BR> <property name="someService" ref="serviceId"/><BR></desktop:view ><BR><BR><desktop:view id="otherView" viewClass="com.acme.foo.bar.OtherView" mdi:closable="true" mdi:resizable="false"><BR> <property name="someService" ref="serviceId"/><BR></desktop:view><BR><BR><desktop:view id="yetAnotherView" viewClass="com.acme.foo.bar.YetAnotherView" docking:closable="false" docking:draggable="true"><BR> <property name="someService" ref="serviceId"/><BR></desktop:view><BR><BR>In Spring 2.5 ADI style that might be done as<BR><BR><context:component-scan package="com.myco"/><BR><BR>@View<BR>public class SomeView {<BR> @Autowired SomeView(SomeService someService) {..}<BR>}<BR><BR>@View<BR>@MdiConfiguration(closable=true, resizable=false)<BR>public class OtherView {<BR> @Autowired OtherView(SomeService someService) {..}<BR>}<BR><BR>@View<BR>@DockingConfiguration(closable=false, draggable=false)<BR>public class YetAnotherView {<BR> @Autowired YetAnotherView(So meService someService) {..}<BR>}<BR><BR><BR>Modular plugin support is partly for plugins (a-la Eclipse or Netbeans), but mostly for making it easier to do good modularity. Hot-swapping, discovery, etc are all just nice side-effects of having better modularity. Fortunately, because of Spring Dynamic Modules this can always be added later, especially if we follow the SpringDM conventions. (eg, /META-INF/spring/application-context.xml) S2AP can provide the underlying support for that if we want. Otherwise we can keep OSGi use (but not OSGi compliance) out for now. Having JSR-277 support (like WebStart and Netbeans) would be awesome so people don't have to download 50 copies of log4j and updates can happen faster/easier.<BR><BR>-Jim Moore<BR> Senior Consultant, SpringSource<BR><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> |
