springframework-rcp-dev — Spring Rich Client developer list

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

[Larry S. <lst...@au...>]

In this approach haven't we just replaced the ServiceLocator with a 
ServiceRegistry - with all the same problems?  Meaning that every object 
needs to "find" the ServiceRegistry, either by having it be a static 
singleton, or having declarative XML to DI it.  This leads us right back 
to the earlier problems we had with the ServiceLocator.  Or, have I 
misunderstood something in your proposal Kevin?

Thanks,
Larry.

Kevin Day wrote:
> How about we start with a concrete example of how the service locator 
> is currently used, and consider how it could be refactored?
>  
> Here's a simple example:
>  
> Currently RulesValidator has the ability to set a RulesSource object 
> in the constructor, or if none is specified, it uses 
> ApplicationServicesLocator to look up a RulesSource.
>  
>  
> Another approach is to consider that we know that any given 
> RulesValidator is *always* going to need a RulesSource.  So we provide 
> a setter for rulesSource (and probably ditch the variable pass in the 
> constructor).  When a RulesValidator is created, it is registered with 
> a ServiceRegistry.  The ServiceRegistry sends notifications that a new 
> RulesValidator has been registered.
>  
> We also have a Configurator object that has been created that listends 
> to the ServiceRegistry.  When new objects are registered, it injects 
> resources into them.  So as the RulesValidator is registered, the 
> Configurator becomes aware of it, and injects the appropriate 
> RulesSource.  For the generic case, a default RulesSource will get 
> injected.  If a given RulesValidator needs a specific instance, the 
> Configurator can determine which one to provide using a number of 
> different strategies (xml, annotations, convention or any of a ton of 
> other ways of declaritively specifying this kind of thing).
>  
>  
> Advantages of this approach:
>  
> 1.  The RulesValidator needs no knowledge of the ServiceRegistry - 
> that dependency is completely gone.
> 2.  The RulesSource needs no knowledge of the ServiceRegistry (Spring 
> DI should be able to take care of the registration as it creates the 
> RulesSource)
> 3.  The behavior of configuration of objects becomes factored out into 
> a separate entity (Configurator, or whatever).  There is no longer any 
> self configuration, which keeps the RulesValidator and RulesSource clean.
>  
> If the Configurator is in a separate 'module' (or we follow 
> appropriate design guidelines to ensure there isn't dependency creep), 
> it may be possible to have different implementations of the basic 
> configuration policy (i.e. one using xml files, one using annotations, 
> one 'by-convention', etc...).
>  
> Disadvantages of this approach:
>  
> 1.  The service registry becomes more complicated (it has to support 
> registration, and possibly deregistration, event notifications)
> 2.  The service registry still needs to be made available (although I 
> suspect that in most cases this can be factored out into Spring DI).  
> If it does need to be made available, I believe that it should be done 
> by injection (at least at the module level) and not via static 
> lookup.  If a module wants to store a copy of the service registry in 
> a static variable with global module scope, then so be it - but I 
> think the overall framework should not require this.
>  
>  
> Comments? I think it may be worthwhile to take a look at a bunch of 
> cases like this and make sure that it really makes sense.
>  
> - K
>  
> ----------------------- *Original Message* -----------------------
>   
> *From:* Larry Streepy <lst...@au...> 
> <mailto:lst...@au...>
> *To:* spr...@li... 
> <mailto:spr...@li...>
> *Cc:* 
> *Date:* Tue, 08 Jul 2008 14:59:53 -0500
> *Subject: _Re: [Springframework-rcp-dev] [Spring Desktop] ideas for 
> the    Desktop version_*
>   
> Peter De Bruycker wrote:
>> 2nd attempt:
>>
>> Can we reach a consensus here?
>> I think we need to go as fast as possible, to keep the momentum going...
>>
>> 1. code organization:
>>
>>     * core
>>     * application: window, dialogs, page, view, action, ...
>>     * binding: validation, binding, forms
>>     * resources
>>
>> 2. singleton/service locator:
>>
>> Get rid of it by clever use of custom xml, component scanning + 
>> autowiring, convention over configuration, simpler object structures, ...
>
> I'm still unclear on how we do this without an explosion of XML or 
> intermediate factories, lots of boilerplate (including additional 
> members on objects), or some other nasty artifact that makes the 
> platform difficult to use.  Maybe I missed how this was to be done in 
> the earlier email exchange, or I'm just being dense.  Could you please 
> elucidate how we get rid of the service locator and keep the solution 
> simple to implement even with dynamic objects?
>
>>
>> 3. osgi support
>>
>> First make sure we have something working, then see what we can do to 
>> improve?
>
> Do you mean to get the basic modularity cleaned up first and then look 
> at OSGi, or do you mean get OSGi working right away?
>
>>
>>
>> Again: I think we need to go fast, so we have something working as 
>> soon as possible.
>>
>>
>> I already started on work on the application infrastructure code 
>> (window, page, pagecomponent, view, editor) that will allow for much 
>> simpler (and less) xml, multiple view instances at the same time 
>> (formerly known as editors) and easier integration possibilities with 
>> 3rd party component providers (i.e. Jide, SwingDocking, ...), and I 
>> expect to be able to check them in this week. If you have 
>> questions/remarks/suggestions on these parts of the framework, don't 
>> hesitate to give me a nudge!
>>
>>
>> regards,
>> Peter
>
> Good to see things getting ramped up!
>
> Thanks,
> Larry.
>

[Springframework-rcp-dev] Multiple Document Handling

[Peter K. <pe...@ya...>]

Hi,

on Javalobby someone asked me the following interesting question:

Does Spring RCP has support for a multiple-document interface? I mean
can I have more than one instance of my application and it's classes
running in the same JVM. Just wondering how it resolves which action
'belongs' to which application instance in this kind of scenario.

Do you have an answer?

And is there a Helper class that provides me the 3 common folders:
sth. like
APPLICATION_SETTINGS e.g. /usr/share/application
USER_SETTINGS  e.g. /home/user/.application
WORKING e.g. current working dir

I do not know for sure, but in NetBeans you could have 3 xml settings 
files in those folders and then it will merge them into the "real-used" 
settings file. [1]
Isn't this approach interesting?

Regards,
Peter.



[1]
http://wiki.netbeans.org/DevFaqModulesLayerFile

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

[Kevin D. <ke...@tr...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=Content-Type content=text/html;charset=ISO-8859-1>
<META content="MSHTML 6.00.2900.3059" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2>
<DIV>How about we start with a concrete example of how the service locator is currently used, and consider how it could be refactored?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Here's a simple example:</DIV>
<DIV>&nbsp;</DIV>
<DIV>Currently RulesValidator has the ability to set a RulesSource object in the constructor, or if none is specified, it uses <FONT size=2>ApplicationServicesLocator to look up a RulesSource.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Another approach is to consider that we know that any given RulesValidator is *always* going to need a RulesSource.&nbsp; So we provide a setter for&nbsp;rulesSource (and probably ditch the variable pass in the constructor).&nbsp; When a RulesValidator is created, it is registered with a ServiceRegistry.&nbsp; The ServiceRegistry sends notifications that a new RulesValidator has been registered.</DIV>
<DIV>&nbsp;</DIV>
<DIV>We also have a Configurator object that has been created that listends to the ServiceRegistry.&nbsp; When new objects are registered, it injects resources into them.&nbsp; So as the RulesValidator is registered, the Configurator becomes aware of it, and injects the appropriate RulesSource.&nbsp; For the generic case, a default RulesSource will get injected.&nbsp; If a given RulesValidator needs a specific instance, the Configurator can determine which one to provide using a number of different strategies (xml, annotations, convention or any of a ton of other ways of declaritively specifying this kind of thing).</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Advantages of this approach:</DIV>
<DIV>&nbsp;</DIV>
<DIV>1.&nbsp; The RulesValidator needs no knowledge of the ServiceRegistry - that dependency is completely gone.</DIV>
<DIV>2.&nbsp; The RulesSource needs no knowledge of the ServiceRegistry (Spring DI should be able to take care of the registration as it creates the RulesSource)</DIV>
<DIV>3.&nbsp; The behavior of configuration of objects becomes factored out into a separate entity (Configurator, or whatever).&nbsp; There is no longer any self configuration, which keeps the RulesValidator and RulesSource clean.</DIV>
<DIV>&nbsp;</DIV>
<DIV>If the Configurator is in a separate 'module' (or we follow appropriate design guidelines to ensure there isn't dependency creep), it may be possible to have different implementations of the basic configuration policy (i.e. one using xml files, one using annotations, one 'by-convention', etc...).</DIV>
<DIV>&nbsp;</DIV>
<DIV>Disadvantages of this approach:</DIV>
<DIV>&nbsp;</DIV>
<DIV>1.&nbsp; The service registry becomes more complicated (it has to support registration, and possibly deregistration,&nbsp;event notifications)</DIV>
<DIV>2.&nbsp; The service registry still needs to be made available (although&nbsp;I suspect that in most cases this can be factored out into Spring DI).&nbsp; If it does need to be made available, I believe that it should be done by injection (at least at the module level) and not via static lookup.&nbsp; If a module wants to store a copy of the service registry in a static variable with global module scope, then so be it - but I think the overall framework should not require this.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Comments? I think it may be worthwhile to take a look at a bunch of cases like this and make sure that it really makes sense.</DIV>
<DIV>&nbsp;</DIV>
<DIV>- K<BR></DIV>
<DIV>&nbsp;</DIV></FONT>
<DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma">
<DIV>----------------------- <B>Original Message</B> -----------------------</DIV>
<DIV>&nbsp;&nbsp;</DIV>
<DIV><B>From:</B>&nbsp;Larry Streepy <A href="mailto:lst...@au..."><FONT color=#0000ff>&lt;lst...@au...&gt;</FONT></A></DIV>
<DIV><B>To:</B>&nbsp;<A href="mailto:spr...@li..."><FONT color=#0000ff>spr...@li...</FONT></A></DIV>
<DIV><B>Cc:</B>&nbsp;</DIV>
<DIV><B>Date:</B>&nbsp;Tue, 08 Jul 2008 14:59:53 -0500</DIV>
<DIV><B>Subject:&nbsp;<U>Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the&nbsp;&nbsp;&nbsp;&nbsp;Desktop version</U></B></DIV>
<DIV>&nbsp;&nbsp;</DIV></DIV>Peter De Bruycker wrote: 
<BLOCKQUOTE cite=mid:6f9...@ma... type="cite">2nd attempt:<BR><BR>Can we reach a consensus here?<BR>I think we need to go as fast as possible, to keep the momentum going...<BR><BR>1. code organization:<BR>
<UL>
<LI>core 
<LI>application: window, dialogs, page, view, action, ... 
<LI>binding: validation, binding, forms 
<LI>resources </LI></UL>2. singleton/service locator:<BR><BR>Get rid of it by clever use of custom xml, component scanning + autowiring, convention over configuration, simpler object structures, ...<BR></BLOCKQUOTE><BR>I'm still unclear on how we do this without an explosion of XML or intermediate factories, lots of boilerplate (including additional members on objects), or some other nasty artifact that makes the platform difficult to use.&nbsp; Maybe I missed how this was to be done in the earlier email exchange, or I'm just being dense.&nbsp; Could you please elucidate how we get rid of the service locator and keep the solution simple to implement even with dynamic objects?<BR><BR>
<BLOCKQUOTE cite=mid:6f9...@ma... type="cite"><BR>3. osgi support<BR><BR>First make sure we have something working, then see what we can do to improve?<BR></BLOCKQUOTE><BR>Do you mean to get the basic modularity cleaned up first and then look at OSGi, or do you mean get OSGi working right away?<BR><BR>
<BLOCKQUOTE cite=mid:6f9...@ma... type="cite"><BR><BR>Again: I think we need to go fast, so we have something working as soon as possible.<BR><BR><BR>I already started on work on the application infrastructure code (window, page, pagecomponent, view, editor) that will allow for much simpler (and less) xml, multiple view instances at the same time (formerly known as editors) and easier integration possibilities with 3rd party component providers (i.e. Jide, SwingDocking, ...), and I expect to be able to check them in this week. If you have questions/remarks/suggestions on these parts of the framework, don't hesitate to give me a nudge!<BR><BR><BR>regards,<BR>Peter<BR></BLOCKQUOTE><BR>Good to see things getting ramped up!<BR><BR>Thanks,<BR>Larry.<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>

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

[Larry S. <lst...@au...>]

Peter De Bruycker wrote:
> 2nd attempt:
>
> Can we reach a consensus here?
> I think we need to go as fast as possible, to keep the momentum going...
>
> 1. code organization:
>
>     * core
>     * application: window, dialogs, page, view, action, ...
>     * binding: validation, binding, forms
>     * resources
>
> 2. singleton/service locator:
>
> Get rid of it by clever use of custom xml, component scanning + 
> autowiring, convention over configuration, simpler object structures, ...

I'm still unclear on how we do this without an explosion of XML or 
intermediate factories, lots of boilerplate (including additional 
members on objects), or some other nasty artifact that makes the 
platform difficult to use.  Maybe I missed how this was to be done in 
the earlier email exchange, or I'm just being dense.  Could you please 
elucidate how we get rid of the service locator and keep the solution 
simple to implement even with dynamic objects?

>
> 3. osgi support
>
> First make sure we have something working, then see what we can do to 
> improve?

Do you mean to get the basic modularity cleaned up first and then look 
at OSGi, or do you mean get OSGi working right away?

>
>
> Again: I think we need to go fast, so we have something working as 
> soon as possible.
>
>
> I already started on work on the application infrastructure code 
> (window, page, pagecomponent, view, editor) that will allow for much 
> simpler (and less) xml, multiple view instances at the same time 
> (formerly known as editors) and easier integration possibilities with 
> 3rd party component providers (i.e. Jide, SwingDocking, ...), and I 
> expect to be able to check them in this week. If you have 
> questions/remarks/suggestions on these parts of the framework, don't 
> hesitate to give me a nudge!
>
>
> regards,
> Peter

Good to see things getting ramped up!

Thanks,
Larry.

Re: [Springframework-rcp-dev] First commit

[Geoffrey De S. <ge0...@gm...>]

Please copy paste the svn:ignore list that are currently used for each 
module directory.
It ignores the eclipse, intellij and netbeans files, as well as the 
target dir and local dir.
In my experience it's a bad idea to check in the ide (especially 
eclipse) files, when you can just generate them with maven anyway.
Could you also remove the eclipse files from subversion?

wkr,
Geoffrey De Smet

Peter De Bruycker schreef:
> I just did to the first commit for Spring Desktop!
> 
> It's nothing shocking, just a dedicated DesktopApplicationContext 
> interface + implementation + tests.
> 
> the pom.xml doesn't contain all developers yet (just me and Jan have 
> been added, the list will be updated when needed)
> 
> for the moment, there's only one module (core).
> 
> regards,
> 
> Peter
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

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

[Arne L. <Arn...@ar...>]

Hi Peter,

great that you started committing.

I would prefer having having two more modules:
1. Separate an action module. Business modules may implement actions not 
needing to know about the application displaying it.
2. Move out the forms from the binding/validation module. The binding 
and validation stuff may be used without forms.

Regards,
Arne

Peter De Bruycker schrieb:
> 2nd attempt:
>
> Can we reach a consensus here?
> I think we need to go as fast as possible, to keep the momentum going...
>
> 1. code organization:
>
>     * core
>     * application: window, dialogs, page, view, action, ...
>     * binding: validation, binding, forms
>     * resources
>
> 2. singleton/service locator:
>
> Get rid of it by clever use of custom xml, component scanning + 
> autowiring, convention over configuration, simpler object structures, ...
>
> 3. osgi support
>
> First make sure we have something working, then see what we can do to 
> improve?
>
>
> Again: I think we need to go fast, so we have something working as 
> soon as possible.
>
>
> I already started on work on the application infrastructure code 
> (window, page, pagecomponent, view, editor) that will allow for much 
> simpler (and less) xml, multiple view instances at the same time 
> (formerly known as editors) and easier integration possibilities with 
> 3rd party component providers (i.e. Jide, SwingDocking, ...), and I 
> expect to be able to check them in this week. If you have 
> questions/remarks/suggestions on these parts of the framework, don't 
> hesitate to give me a nudge!
>
>
> regards,
>
> Peter
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> ------------------------------------------------------------------------
>
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>   

Re: [Springframework-rcp-dev] First commit

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

https://anonsvn.springframework.org/svn/spring-desktop/


On Tue, Jul 8, 2008 at 12:40 PM, Kevin Day <ke...@tr...> wrote:

>  While we are at it, can we get an svn url (even if read only)?  I'd like
> to review commits as they come in.
>
> I would also still like to see a design philosophy of some sort emerge - if
> nothing else, it will provide content for a project home page...
>
> Thanks,
>
> - K
>
>  ----------------------- *Original Message* -----------------------
>
> *From:* Lieven Doclo <lie...@ji...> <lie...@ji...>
> *To:* spr...@li...
> *Cc:*
> *Date:* Tue, 8 Jul 2008 15:01:24 +0000 (UTC)
> *Subject: Re: [Springframework-rcp-dev] First commit*
>
> Peter,
>
> Would you mind if I deleted the IDE specific files (.settings/*, .project,
> .classpath), since I don't think everyone will be using Eclipse (I think
> Jan already mentioned that we have a IntelliJ license for Spring Deskop
> developers)?
>
> Since we're starting to build up the codebase, perhaps we should set the
> coding standards? Or do we take over the ones from RCP? That way we can
> make
> sure that there are no commits regarding indentation, etc...
>
> Perhaps it's not a bad idea to create a new dev mailinglist for
> spring-desktop
> (can be confusing if there are rcp issues in between in the future...)?
>
> Great idea by the way regarding the BeanPostProcessor... We could also do
> this using i.e. an @Application component stereotype and use the 2.5
> autowiring...
> We could off course provide both ways...
>
> Greetz,
>
> Lieven
>
> > ----------------------------------------------------------------------
> > ---
> > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> > Studies have shown that voting for your favorite open source project,
> > along with a healthy diet, reduces your potential for chronic lameness
> > and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> > _______________________________________________
> > Springframework-rcp-dev mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>
>
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!*Studies
> have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
> *
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>

Re: [Springframework-rcp-dev] First commit

[Kevin D. <ke...@tr...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>

<META content="MSHTML 6.00.2900.3059" name=GENERATOR></HEAD>
<BODY leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2>
<DIV>While we are at it, can we get an svn url (even if read only)?&nbsp; I'd like to review commits as they come in.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I would also still like to see a design philosophy of some sort emerge - if nothing else, it will provide content for a project home page...</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks,</DIV>
<DIV>&nbsp;</DIV>
<DIV>- K<BR></DIV>
<DIV>&nbsp;</DIV></FONT>
<DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma">
<DIV>----------------------- <B>Original Message</B> -----------------------</DIV>
<DIV>&nbsp;&nbsp;</DIV>
<DIV><B>From:</B>&nbsp;Lieven Doclo <A href="mailto:lie...@ji..."><FONT color=#0000ff>&lt;lie...@ji...&gt;</FONT></A></DIV>
<DIV><B>To:</B>&nbsp;<A href="mailto:spr...@li..."><FONT color=#0000ff>spr...@li...</FONT></A></DIV>
<DIV><B>Cc:</B>&nbsp;</DIV>
<DIV><B>Date:</B>&nbsp;Tue, 8 Jul 2008 15:01:24 +0000 (UTC)</DIV>
<DIV><B>Subject:&nbsp;<U>Re: [Springframework-rcp-dev] First commit</U></B></DIV>
<DIV>&nbsp;&nbsp;</DIV></DIV><FONT face=Tahoma size=2>
<DIV>Peter,<BR><BR>Would you mind if I deleted the IDE specific files (.settings/*, .project, <BR>.classpath), since I don't think everyone will be using Eclipse (I think <BR>Jan already mentioned that we have a IntelliJ license for Spring Deskop developers)?<BR><BR>Since we're starting to build up the codebase, perhaps we should set the <BR>coding standards? Or do we take over the ones from RCP? That way we can make <BR>sure that there are no commits regarding indentation, etc... <BR><BR>Perhaps it's not a bad idea to create a new dev mailinglist for spring-desktop <BR>(can be confusing if there are rcp issues in between in the future...)? <BR><BR>Great idea by the way regarding the BeanPostProcessor... We could also do <BR>this using i.e. an @Application component stereotype and use the 2.5 autowiring... <BR>We could off course provide both ways...<BR><BR>Greetz,<BR><BR>Lieven<BR><BR>&gt; ----------------------------------------------------------------------<BR>&gt; ---<BR>
 &gt; Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!<BR>&gt; Studies have shown that voting for your favorite open source project,<BR>&gt; along with a healthy diet, reduces your potential for chronic lameness<BR>&gt; and boredom. Vote Now at <A href="http://www.sourceforge.net/community/cca08"><FONT color=#0000ff>http://www.sourceforge.net/community/cca08</FONT></A><BR>&gt; _______________________________________________<BR>&gt; Springframework-rcp-dev mailing list<BR>&gt; <A href="mailto:Spr...@li..."><FONT color=#0000ff>Spr...@li...</FONT></A><BR>&gt; <A href="https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev"><FONT color=#0000ff>https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev</FONT></A><BR><BR><BR><BR><BR><BR>-------------------------------------------------------------------------<BR>Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!<B
 R>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 <A href="http://www.sourceforge.net/community/cca08"><FONT color=#0000ff>http://www.sourceforge.net/community/cca08</FONT></A><BR>_______________________________________________<BR>Springframework-rcp-dev mailing list<BR><A href="mailto:Spr...@li..."><FONT color=#0000ff>Spr...@li...</FONT></A><BR><A href="https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev"><FONT color=#0000ff>https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev</FONT></A><BR><BR></DIV></FONT></BODY></HTML>

Re: [Springframework-rcp-dev] First commit

[Lieven D. <lie...@ji...>]

Hello Peter,

I've just checked the code and when you're using autowiring and component 
scanning, a problem occurs: The ApplicationContext implementation is responsible 
for creating an Application, whereas I would let the container do this (annotate 
your Application and let the component scan handle the instantiation). However, 
since the ApplicationContext constructs the Spring container, one cannot 
inject the scanned Application into the ApplicationContext. 

Hence the services are injected correctly (with my annotated Application), 
but the ApplicationContext holds his own created Application...

Can't see a solution atm...

Greetz,

Lieven
> ----------------------------------------------------------------------
> ---
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

Re: [Springframework-rcp-dev] First commit

[Lieven D. <lie...@ji...>]

Peter,

Would you mind if I deleted the IDE specific files (.settings/*, .project, 
.classpath), since I don't think everyone will be using Eclipse (I think 
Jan already mentioned that we have a IntelliJ license for Spring Deskop developers)?

Since we're starting to build up the codebase, perhaps we should set the 
coding standards? Or do we take over the ones from RCP? That way we can make 
sure that there are no commits regarding indentation, etc... 

Perhaps it's not a bad idea to create a new dev mailinglist for spring-desktop 
(can be confusing if there are rcp issues in between in the future...)? 

Great idea by the way regarding the BeanPostProcessor... We could also do 
this using i.e. an @Application component stereotype and use the 2.5 autowiring... 
We could off course provide both ways...

Greetz,

Lieven

> ----------------------------------------------------------------------
> ---
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

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

[Claudio R. <cla...@li...>]

Peter De Bruycker <peter.de.bruycker <at> gmail.com> writes:

> 
> 
> 2nd attempt:Can we reach a consensus here?I think we need to go as fast as
possible, to keep the momentum going...1. code organization:
> 
> core
> application: window, dialogs, page, view, action, ...
> binding: validation, binding, forms
> resources

+1

> 2. singleton/service locator:Get rid of it by clever use of custom xml, 
>component scanning + autowiring, convention over configuration, simpler object 
>structures, 

+1 (just use spring 2.5 features)

> 3. osgi supportFirst make sure we have something working, then see what we can
do to improve?

+1 Just focus on cohesive packages .... after hat we can have a deeper look into
osgi if it makes sense.

> Again: I think we need to go fast, so we have something working as soon as
possible.I already started on work on the application infrastructure code
(window, page, pagecomponent, view, editor) that will allow for much simpler
(and less) xml, multiple view instances at the same time (formerly known as
editors) and easier integration possibilities with 3rd party component providers
(i.e. Jide, SwingDocking, ...), and I expect to be able to check them in this
week. If you have questions/remarks/suggestions on these parts of the framework,
don't hesitate to give me a nudge!regards,Peter
> 

What about the JSR 295 and 296?  Do we want to take a look at them, at least to
the binding JSR to see if it would make sense to integrate it?


-
Claudio

> 
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> 
> _______________________________________________
> Springframework-rcp-dev mailing list
> Springframework-rcp-dev <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
> 

Re: [Springframework-rcp-dev] [Spring Desktop] Modularity

[Claudio R. <cla...@li...>]

Jim Moore <moore.jim <at> gmail.com> writes:

> 
> Short summary of the modularity discussion...First premise: Modularity is
good.Second premise: OSGi help with modularity.Therefore Spring Desktop needs
modularity from a "good design" standpoint, but it's debatable the extent of the
benefits OSGi would give relative to the additional complexity (technical and
conceptual).There's no reason to over-burden either development of the
framework, or what people have to learn to use it.  The beautiful thing about
Spring DM for the end-user is that it lets you develop your application as a
"normal Spring app" (ie, using DI) and not worry about if it's running in an SE
or OSGi environment.  If they know and want to use OSGi, then they create and
consume bundles as normal Spring app-contexts with additional meta-data,
otherwise they simply do things the "old" way.On the framework side, as long as
we do good, disciplined design (e.g., highly cohesive packages with absolutely
no cycles between them, no static singletons, etc) then there's nothing that
would prevent us from going for the traditional library modularity approach we
all know and love, then upgrade to OSGi when we're feeling more comfortable with
the technology.  At first, no OSGi.  Later someone can start maintaining the
OSGi meta-data so end-users that want to use Spring Desktop in an OSGi
environment can do so easily.  Then, after we've seen/experienced exactly how
the technology is being used, we can start adding the cool features of OSGi for
those that want to take advantage of them.  (This is the path that all the core
Spring libraries are taking.
>  )We should go for the simplest solution first, which in this case is a highly
modular library (at the package level, not necessarily the src code level) with
no OSGi use.  When we get to things people are begging for that can't be done
except with OSGi, we'll start doing so.  But let's get the basics in there
first. -Jim Moore

Hi All,

sorry for not answering I was on holiday.

My thoughts on the OSGI stuff is that modularity is very important for the
framework. In our application we often have the need to modularize the
application. We have a customizable software for different customers. Customers
may have different or custom modules that can interact with other modules. An
easy example to think of is the administration module of the software.
(Administration module may depends on other modules but none of the other
modules depends on the administration) 

At the moment we have developed a simple module system for the current codebase
on spring rich. Every module has it's own spring-context. This module context
has the spring-rich application context as the parent. 

Every module has its own resources, actions and bindings. This resources will
then be injected to the main application context. It works, but it's a very
simple implementation and lot of nice features are missing (load/unload modules)
but it allows us to have a nice granularity on our code and the dependency's
between the modules are clearly defined.

Most problems we had during implementing this simple module feature for
spring-rich where the static methods on the application context. Something like
the whiteboard pattern (or Spring-DO magic) would have made our live much more
easier. 

I would like to see the possibility to handle this kind of scenario with 
Spring-Desktop.

But for all this I don't think that OSGI is needed from the beginning on. OSGI
would be a huge hurdle for developers when they start with Spring-Desktop, as
the framework is already complex, without the OSGI stuff in there.

As Jim said, let's focus on cohesive packages ,not having cycles dependencies
between them and no static singletons .... 

just my two cents...


Claudio

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

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

Peter De Bruycker wrote:
> 
>     Is there some way of instructing the different views on which object to
>     present? e.g. in Eclipse, you can have multiple instances of a Java code
>     editor, each editing a different .java source file. How do you specify
>     which file to edit?
> 
> to open a view, you do ApplicationPage.showView(String id).
> 
> I created a new method ApplicationPage.showView(String id, Object input)
> the ApplicationPage checks if a view with the given id and input is 
> already open. if not, it opens a new one, otherwise it shows the 
> existing one
> 
> the input is passed on to the View, so it can render itself using this 
> object (the object can be anything, a file, a customer object, ...)
> 

Perfect. Thanks!

Rogan

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

[Peter De B. <pet...@gm...>]

On Tue, Jul 8, 2008 at 3:04 PM, Rogan Dawes <ro...@da...> wrote:

> Peter De Bruycker wrote:
> > 2nd attempt:
> >
> > Can we reach a consensus here?
> > I think we need to go as fast as possible, to keep the momentum going...
> >
> > 1. code organization:
> >
> >     * core
> >     * application: window, dialogs, page, view, action, ...
> >     * binding: validation, binding, forms
> >     * resources
> >
>
> This looks like a reasonable split to me.
>
> > I already started on work on the application infrastructure code
> > (window, page, pagecomponent, view, editor) that will allow for much
> > simpler (and less) xml, multiple view instances at the same time
> > (formerly known as editors)
>
> Is there some way of instructing the different views on which object to
> present? e.g. in Eclipse, you can have multiple instances of a Java code
> editor, each editing a different .java source file. How do you specify
> which file to edit?
>


to open a view, you do ApplicationPage.showView(String id).

I created a new method ApplicationPage.showView(String id, Object input)
the ApplicationPage checks if a view with the given id and input is already
open. if not, it opens a new one, otherwise it shows the existing one

the input is passed on to the View, so it can render itself using this
object (the object can be anything, a file, a customer object, ...)



>
> Regards,
>
> Rogan
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>

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

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

Peter De Bruycker wrote:
> 2nd attempt:
> 
> Can we reach a consensus here?
> I think we need to go as fast as possible, to keep the momentum going...
> 
> 1. code organization:
> 
>     * core
>     * application: window, dialogs, page, view, action, ...
>     * binding: validation, binding, forms
>     * resources
> 

This looks like a reasonable split to me.

> I already started on work on the application infrastructure code 
> (window, page, pagecomponent, view, editor) that will allow for much 
> simpler (and less) xml, multiple view instances at the same time 
> (formerly known as editors) 

Is there some way of instructing the different views on which object to
present? e.g. in Eclipse, you can have multiple instances of a Java code 
editor, each editing a different .java source file. How do you specify 
which file to edit?

Regards,

Rogan

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

[Peter De B. <pet...@gm...>]

2nd attempt:

Can we reach a consensus here?
I think we need to go as fast as possible, to keep the momentum going...

1. code organization:

   - core
   - application: window, dialogs, page, view, action, ...
   - binding: validation, binding, forms
   - resources

2. singleton/service locator:

Get rid of it by clever use of custom xml, component scanning + autowiring,
convention over configuration, simpler object structures, ...

3. osgi support

First make sure we have something working, then see what we can do to
improve?


Again: I think we need to go fast, so we have something working as soon as
possible.


I already started on work on the application infrastructure code (window,
page, pagecomponent, view, editor) that will allow for much simpler (and
less) xml, multiple view instances at the same time (formerly known as
editors) and easier integration possibilities with 3rd party component
providers (i.e. Jide, SwingDocking, ...), and I expect to be able to check
them in this week. If you have questions/remarks/suggestions on these parts
of the framework, don't hesitate to give me a nudge!


regards,

Peter

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

[Peter De B. <pet...@gm...>]

C

On Mon, Jul 7, 2008 at 8:26 PM, Thomas R. Corbin <tho...@gm...>
wrote:

> This all looks great!
>
> On Tuesday 01 July 2008, Jim Moore escreveu:
> > Heya, everyone.  Sorry for jumping into this discussion late.
> >
> > 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.
> >
> > 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.)
> >
> > 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 SpringSource Application Platform
> > (S2AP), for example.
> >
> > I love the idea of new XML configuration.  A couple of comments on the
> > examples:
> >
> > <bean id="someBean" class="foobar">
> >     <property name="prefs">
> >         <desktop:prefs scope="user|system"
> > path="path/to/preferences/node"/> </property>
> > </bean>
> >
> > 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.
> >
> > <desktop:view id="someView" viewClass="com.acme.foo.bar.SomeView">
> >     <property name="someService" ref="serviceId"/>
> > </desktop:view>
> >
> > <desktop:view id="otherView" viewClass="com.acme.foo.bar.OtherView"
> > mdi:closable="true" mdi:resizable="false">
> >     <property name="someService" ref="serviceId"/>
> > </desktop:view>
> >
> > <desktop:view id="yetAnotherView"
> > viewClass="com.acme.foo.bar.YetAnotherView" docking:closable="false"
> > docking:draggable="true">
> >     <property name="someService" ref="serviceId"/>
> > </desktop:view>
> >
> > In Spring 2.5 ADI style that might be done as
> >
> > <context:component-scan package="com.myco"/>
> >
> > @View
> > public class SomeView {
> >   @Autowired SomeView(SomeService someService) {..}
> > }
> >
> > @View
> > @MdiConfiguration(closable=true, resizable=false)
> > public class OtherView {
> >   @Autowired OtherView(SomeService someService) {..}
> > }
> >
> > @View
> > @DockingConfiguration(closable=false, draggable=false)
> > public class YetAnotherView {
> >   @Autowired YetAnotherView(SomeService someService) {..}
> > }
> >
> >
> > 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.
> >
> > -Jim Moore
> >  Senior Consultant, SpringSource
>
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>

[Springframework-rcp-dev] First commit

[Peter De B. <pet...@gm...>]

I just did to the first commit for Spring Desktop!

It's nothing shocking, just a dedicated DesktopApplicationContext interface
+ implementation + tests.

the pom.xml doesn't contain all developers yet (just me and Jan have been
added, the list will be updated when needed)

for the moment, there's only one module (core).

regards,

Peter

Re: [Springframework-rcp-dev] [Spring Desktop] Modularity

[Kevin D. <ke...@tr...>]

<!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>Amen.&nbsp; I also appreciate your comments describing the reason that some of the service locator features were used in the RCP project - that makes a lot of sense, and I think taking some time to go through the specific use cases of dialog creation, etc... would be time well spent.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>So, it sounds like we have the beginning of a design philosophy for the Desktop project:&nbsp; "we do good, disciplined design (e.g., highly cohesive packages with absolutely no cycles between them, no static singletons, etc)"</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>I think that a good starting point is to lay out the services that are actually provided by the framework, and the mechanism by which users can work with those services.&nbsp; With these services in mind, perhaps a module definition will begin to materialize.&nbsp; We should also keep in mind that there are cases where modules are used to provide functionality (not necessarily services).&nbsp; I think that binding is a good example of this.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>That said, here is the beginning of services/capabilities that I would love to see in a RC framework (obviously, some are more important than others):</DIV>
<DIV>&nbsp;</DIV>
<DIV><STRONG><U>For lower level stuff:</U></STRONG></DIV>
<DIV>Service registration (let's leave the details on that one alone for the time being)</DIV>
<DIV>&nbsp;</DIV>
<DIV>Binding (I know that there is already binding capability in RCP, but JSR 295 is pretty slick if anyone hasn't looked at it - and possibly more general purpose.&nbsp; For list binding, GlazedLists is amazing - if you haven't used it and your apps have anything that is list or table based, I highly recommend it).&nbsp; In any case, the use of the PresentationModel pattern (something akin to the Form</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<DIV>Validation</DIV></DIV>
<DIV>&nbsp;</DIV>
<DIV>Action management (JSR 296 actually has some pretty nice ideas on this)</DIV>
<DIV>&nbsp;</DIV>
<DIV>Curent Selection State management (in some of our apps, we use data binding to bind the current selection state to our various Action implementations - something like a dynamic dependency injection)</DIV>
<DIV>&nbsp;</DIV>
<DIV>GUI state persistence (allowing for addition of new functionality and toolbars as new modules are added or removed to/from the system)</DIV>
<DIV>&nbsp;</DIV>
<DIV>Preferences persistence (??&nbsp; not sure on this one)</DIV>
<DIV>&nbsp;</DIV>
<DIV>Dynamic menu/command bar configuration from Action definitions&nbsp;(including special menu types such as MRU lists, and the ability to dynamically add and remove bundles of menu items based on 'module' presence).&nbsp; Ability to define insertion points for adding specific functionality (i.e. if I want to add a menu option to the Edit menu).&nbsp; Bear in mind that menus and command bars may need to be completely swapped out (similar to what happens with Perspective changes in Eclipse).</DIV>
<DIV>&nbsp;</DIV>
<DIV>Resource injection (for internationalization, etc...)</DIV>
<DIV>&nbsp;</DIV>
<DIV>Undo/Redo support</DIV>
<DIV>&nbsp;</DIV>
<DIV><STRONG><U>At a higher level:</U></STRONG></DIV>
<DIV>Dialog creation (some mechanism to quickly create bound controls, validation feedback, etc... - from what I've seen so far, Spring RCP excels at this)</DIV>
<DIV>&nbsp;</DIV>
<DIV>Wizard creation&nbsp; (dialog creation bundled with some standardized mechanism for controling wizard workflow)</DIV>
<DIV>&nbsp;</DIV>
<DIV>Preferences GUI (a standardized preferences GUI would be a nice option for many apps)</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>That's all for now - I'm sure the list can and will be expanded.</DIV>
<DIV>&nbsp;</DIV>
<DIV>- K</DIV>
<DIV>&nbsp;</DIV>
<DIV><BR>&nbsp;</DIV>
<DIV>&nbsp;</DIV></FONT>
<DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma">
<DIV>----------------------- <B>Original Message</B> -----------------------</DIV>
<DIV>&nbsp;&nbsp;</DIV>
<DIV><B>From:</B>&nbsp;"Jim Moore" <A href="mailto:moo...@gm..."><FONT color=#0000ff>&lt;moo...@gm...&gt;</FONT></A></DIV>
<DIV><B>To:</B>&nbsp;"Spring Rich Dev" <A href="mailto:spr...@li..."><FONT color=#0000ff>&lt;spr...@li...&gt;</FONT></A></DIV>
<DIV><B>Cc:</B>&nbsp;</DIV>
<DIV><B>Date:</B>&nbsp;Mon, 7 Jul 2008 08:37:32 -0400</DIV>
<DIV><B>Subject:&nbsp;<U>Re: [Springframework-rcp-dev] [Spring Desktop] Modularity</U></B></DIV>
<DIV>&nbsp;&nbsp;</DIV></DIV>Short summary of the modularity discussion...<BR>First premise: Modularity is good.<BR>Second premise: OSGi help with modularity.<BR>Therefore Spring Desktop needs modularity from a "good design" standpoint, but it's debatable the extent of the benefits OSGi would give relative to the additional complexity (technical and conceptual).<BR><BR>There's no reason to over-burden either development of the framework, or what people have to learn to use it.&nbsp; The beautiful thing about Spring DM for the end-user is that it lets you develop your application as a "normal Spring app" (ie, using DI) and not worry about if it's running in an SE or OSGi environment.&nbsp; If they know and want to use OSGi, then they create and consume bundles as normal Spring app-contexts with additional meta-data, otherwise they simply do things the "old" way.<BR><BR>On the framework side, as long as we do good, disciplined design (e.g., highly cohesive packages with absolut
 ely no cycles between them, no static singletons, etc) then there's nothing that would prevent us from going for the traditional library modularity approach we all know and love, then upgrade to OSGi when we're feeling more comfortable with the technology.&nbsp; At first, no OSGi.&nbsp; Later someone can start maintaining the OSGi meta-data so end-users that want to use Spring Desktop in an OSGi environment can do so easily.&nbsp; Then, after we've seen/experienced exactly how the technology is being used, we can start adding the cool features of OSGi for those that want to take advantage of them.&nbsp; (This is the path that all the core Spring libraries are taking.)<BR><BR>We should go for the simplest solution first, which in this case is a highly modular library (at the package level, not necessarily the src code level) with no OSGi use.&nbsp; When we get to things people are begging for that can't be done except with OSGi, we'll start doing so.&nbsp; But let's get the b
 asics in there first. :-)<BR><BR>-Jim Moore<BR><BR>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<FONT face=Tahoma size=2>
<DIV></FONT><FONT face=Tahoma size=2><BR>&nbsp;</DIV></FONT></BODY></HTML>

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

[Kevin D. <ke...@tr...>]

<!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>&nbsp;</DIV>
<DIV>Your comment in a more recent email helped clarify the current state of things quite a bit:</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV>The principle reason for the ApplicaionServices singleton was for substantial convenience.&nbsp; 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).&nbsp; 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>&nbsp;</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>&nbsp;</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.&nbsp; 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).&nbsp; 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.&nbsp; The RulesSource would then inject itself into the dialog.&nbsp; 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.&nbsp; 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>&nbsp;</DIV>
<DIV>One interesting side effect of&nbsp;this is that the actual RulesSource instance&nbsp;is never registered with the service registry.&nbsp; It's literally impossible for some other module to get access to the RulesSource by interacting directly with the registry.&nbsp; Instead, the other module must register a consumer of that particular RulesSource and allow the instance to be injected during registration.&nbsp; 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>&nbsp;</DIV>
<DIV>As another example, you can imagine a service for providing resource injection (ResourceInjector)&nbsp;from properties files.&nbsp; This service would never actually be registered with the service registry.&nbsp; Instead, at startup the ResourceInjector gets mapped as a listener for all 'Dialog' objects that get registered with the registry.&nbsp; 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>&nbsp;</DIV>
<DIV>The ResourceInjector instance would need to be created at app startup.&nbsp; And it would need to be registered as a listener to the service registry.&nbsp; I think that defining which class the ResourceInjector instance actually is, and how the listeners should be configured&nbsp;is where declarative configuration comes into play in this scenario.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>What I'm not clear on is how much this complicates the declaritive/configuration portion of the system.&nbsp; It certainly simplifies the actual code, but if the tradeoff is reams of XML, then I'm not particularly interested.</DIV>
<DIV>&nbsp;</DIV>
<DIV>- K</DIV>
<DIV><BR>&nbsp;</DIV>
<DIV>&nbsp;</DIV></FONT>
<DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma">
<DIV>----------------------- <B>Original Message</B> -----------------------</DIV>
<DIV>&nbsp;&nbsp;</DIV>
<DIV><B>From:</B>&nbsp;"Jim Moore" <A href="mailto:moo...@gm..."><FONT color=#0000ff>&lt;moo...@gm...&gt;</FONT></A></DIV>
<DIV><B>To:</B>&nbsp;<A href="mailto:spr...@li..."><FONT color=#0000ff>spr...@li...</FONT></A></DIV>
<DIV><B>Cc:</B>&nbsp;</DIV>
<DIV><B>Date:</B>&nbsp;Wed, 2 Jul 2008 22:25:25 -0400</DIV>
<DIV><B>Subject:&nbsp;<U>Re: [Springframework-rcp-dev] [Spring Desktop] whiteboard vs lookup</U></B></DIV>
<DIV>&nbsp;&nbsp;</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?&nbsp; (Using the ApplicationContext as the container in lieu of OSGi.)&nbsp; 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 &lt;<A href="mailto:ke...@tr...">ke...@tr...</A>&gt; 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:&nbsp; <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>&nbsp;- is something going on?</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>I completely agree on the comments re: modules.</DIV>
<DIV>&nbsp;</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,&nbsp;module life cycle management, etc... there is still a big advantage from a&nbsp;coding practices perspective of using modules (JRE 7 is probably going to be introducing module as a scoping feature).&nbsp; 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>&nbsp;</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>&nbsp;</DIV>
<DIV>This places a&nbsp;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>&nbsp;</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.&nbsp; Instead, the listeners of those services are registered as services.&nbsp; As listener objects&nbsp;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() ).&nbsp; This, I think, makes a strong case for not using global service lookup in the traditional sense.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</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).&nbsp; 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>&nbsp;</DIV>
<DIV>- K<BR></DIV>
<DIV>&nbsp;</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>

Re: [Springframework-rcp-dev] [Desktop] Opinions on JSR 295 and 296?

[Thomas R. C. <tho...@gm...>]

On Tuesday 24 June 2008, Kevin Day escreveu:
> I am wondering if anyone has any general thoughts on JSR 295 and 296.  My
> initial impression from working with 296 is that they have hit the nail
> directly on the head - but that it doesn't go quite far enough.  I think
> that 295 still has some details to work out (especially with where they
> incorporate validation), but their use of EL for certain binding
> definitions is very elegant in a lot of situations, and the underlying
> approach seems to be very intuitive (I am a user and fan of JGoodies
> bindings, but the learning curve can be steep).
>
> Just curious about where everyone sees this fitting into the Desktop
> project (if at all).

All I know is that the binding/validation of spring rcp as it stands seems to 
be vastly complicated and I'd prefer to go with standards.

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

[Thomas R. C. <tho...@gm...>]

This all looks great!

On Tuesday 01 July 2008, Jim Moore escreveu:
> Heya, everyone.  Sorry for jumping into this discussion late.
>
> 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.
>
> 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.)
>
> 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 SpringSource Application Platform
> (S2AP), for example.
>
> I love the idea of new XML configuration.  A couple of comments on the
> examples:
>
> <bean id="someBean" class="foobar">
>     <property name="prefs">
>         <desktop:prefs scope="user|system"
> path="path/to/preferences/node"/> </property>
> </bean>
>
> 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.
>
> <desktop:view id="someView" viewClass="com.acme.foo.bar.SomeView">
>     <property name="someService" ref="serviceId"/>
> </desktop:view>
>
> <desktop:view id="otherView" viewClass="com.acme.foo.bar.OtherView"
> mdi:closable="true" mdi:resizable="false">
>     <property name="someService" ref="serviceId"/>
> </desktop:view>
>
> <desktop:view id="yetAnotherView"
> viewClass="com.acme.foo.bar.YetAnotherView" docking:closable="false"
> docking:draggable="true">
>     <property name="someService" ref="serviceId"/>
> </desktop:view>
>
> In Spring 2.5 ADI style that might be done as
>
> <context:component-scan package="com.myco"/>
>
> @View
> public class SomeView {
>   @Autowired SomeView(SomeService someService) {..}
> }
>
> @View
> @MdiConfiguration(closable=true, resizable=false)
> public class OtherView {
>   @Autowired OtherView(SomeService someService) {..}
> }
>
> @View
> @DockingConfiguration(closable=false, draggable=false)
> public class YetAnotherView {
>   @Autowired YetAnotherView(SomeService someService) {..}
> }
>
>
> 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.
>
> -Jim Moore
>  Senior Consultant, SpringSource

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

[Thomas R. C. <tho...@gm...>]

> > 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.

Yes, the separate commands context has been the bane of my spring rcp 
programming.

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

[Thomas R. C. <tho...@gm...>]

On Friday 04 July 2008, Lieven Doclo escreveu:
> Hi guys,
>
> Been reading all the posts here and been comtemplating on OSGi. And
> frankly, as a business application developers, I really don't see the
> additional benefit of a modular system on a GUI level. Perhaps I'm thick, I
> don't know, but I really can't find a reason to provide a modular system on
> a GUI framework system.
>
> Most application I come in contact with don't have a modular design
> (actually, that's incorrect, but not in the modular sense we're talking
> about here). Enterprise custom-built application don't need plugin
> functionality (although it could be handy on a development level, granted).
> They almost always see their thick-client gui as a entire module (in the
> sense we're talking about here), which might be split up in different
> modules (in the more traditional way, for development purposes).
>
> Don't get me wrong, I do see OSGi as a good thing, but for clearly defined
> concerns (dao, service, webservice, domain (although disputable, who would
> want to take down a POJO layer...) and webstart GUI as a single module)...
> Using OSGi for GUI just seems overkill, could anyone give me an example on
> how he or she would split up his GUI application, 'cause that would be
> great.
>
> Please enlighten me, let me see the OSGi light :).

We are developing a suite of applications using spring rcp.   They all have a 
common core, but include a different set of spring beans, separated out into 
different xml files.   It is somewhat painful to deal with all this and I hope 
that an osgi base might make it easier.   Could certainly be wrong.

But we have applications that deal with a core set of common objects, but are 
targeted for different users and which all have some additional specialized 
beans.   It would be nice to be able to handle all that gracefully and easily.

We have a LOT of spring bean defs, probably too many.   And all of them can be 
overwhelming.

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

[Kevin D. <ke...@tr...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>

<META content="MSHTML 6.00.2900.3268" name=GENERATOR></HEAD>
<BODY leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2>
<DIV>I think I detect some mild sarcasm :-)&nbsp; I was under the impression that Desktop was an opportunity to take a fresh look at things.&nbsp; If this is intended to be an incremental update, please let me know.&nbsp; Cheerio - K<BR></DIV>
<DIV>&nbsp;</DIV></FONT>
<DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma">
<DIV>----------------------- <B>Original Message</B> -----------------------</DIV>
<DIV>&nbsp;&nbsp;</DIV>
<DIV><B>From:</B>&nbsp;"Luan O'Carroll" <A href="mailto:lua...@gm..."><FONT color=#0000ff>&lt;lua...@gm...&gt;</FONT></A></DIV>
<DIV><B>To:</B>&nbsp;<A href="mailto:spr...@li..."><FONT color=#0000ff>spr...@li...</FONT></A></DIV>
<DIV><B>Cc:</B>&nbsp;</DIV>
<DIV><B>Date:</B>&nbsp;Mon, 7 Jul 2008 17:56:06 +0100</DIV>
<DIV><B>Subject:&nbsp;<U>Re: [Springframework-rcp-dev] [Spring Desktop] ideas for theDesktopversion</U></B></DIV>
<DIV>&nbsp;&nbsp;</DIV></DIV><FONT face=Tahoma size=2>
<DIV>Yes please, let's design modularity in from the start, even if it is<BR>implemented fully now.<BR><BR></DIV></FONT></BODY></HTML>