springframework-rcp-dev — Spring Rich Client developer list

[Springframework-rcp-dev] ApplicationDialogs & CloseAction

[Jan H. <jh...@sc...>]

Hi all,

I'm reviewing the CloseAction & ApplicationDialog usage to fix RCP-379.
Currently the default action is to hide the dialog. Which is fine if it
is reused a lot but not when it's a one-shot dialog. 

Two questions arise:

1) do we want 'hide' to still be the default behavior?

I'm comfortable in having the 'hide' default, but it may lead to memory
leaks if it's overlooked (as in petclinic now, stated in RCP-379). We
can stress this in the api docs of course (which I would do anyways).

2) do we want to override this default in subclasses like
MessageDialog/ConfirmationDialog?

Both dialogs are typically small one-shot dialogs which won't suffer
from recreating the ui that much as a full application dialog.  

WDYT?

Anyways I'll go on and fix the petclinic memory leaks by explicitly
providing the closeAction and documenting this in code (probably using
both styles to show the difference)

Kind Regards,
Jan


 **** DISCLAIMER ****
 http://www.schaubroeck.be/maildisclaimer.htm

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-439) make AbstractCommand.getFaceDescriptor() public

[Arne L. (JIRA) <no...@sp...>]

    [ http://jira.springframework.org/browse/RCP-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_28746 ] 

Arne Limburg commented on RCP-439:
----------------------------------

Hi Peter,
you should have updated CommandFaceDescriptor before you commited your change to AbstractCommand. Jan just removed the BLANK_FACE_DESCRIPTOR-field

> make AbstractCommand.getFaceDescriptor() public
> -----------------------------------------------
>
>                 Key: RCP-439
>                 URL: http://jira.springframework.org/browse/RCP-439
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Command System
>    Affects Versions: 0.1.0, 0.2.0, 0.2.1
>            Reporter: Arne Limburg
>            Assignee: Peter De Bruycker
>
> In some situations it is necessary to get displayable informations (like text, icon, ...) from a configured AbstractCommand, i.e. if you want to display a command with a component that does not inherit from AbstractButton.
> There is no possibilty for this by now. AbstractCommand should either implement DescribedElement and VisualizedElement or you should make getFaceDescriptor() public.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-439) make AbstractCommand.getFaceDescriptor() public

[Peter De B. (JIRA) <no...@sp...>]

    [ http://jira.springframework.org/browse/RCP-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_28745 ] 

Peter De Bruycker commented on RCP-439:
---------------------------------------

as a getText, getAccelerator, ... methods already exist, I added a getIcon method.

Perhaps it's not a bad idea to have AbstractCommand implement DescribedElement and VisualizedElement. I will look into it.

> make AbstractCommand.getFaceDescriptor() public
> -----------------------------------------------
>
>                 Key: RCP-439
>                 URL: http://jira.springframework.org/browse/RCP-439
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Command System
>    Affects Versions: 0.1.0, 0.2.0, 0.2.1
>            Reporter: Arne Limburg
>            Assignee: Peter De Bruycker
>
> In some situations it is necessary to get displayable informations (like text, icon, ...) from a configured AbstractCommand, i.e. if you want to display a command with a component that does not inherit from AbstractButton.
> There is no possibilty for this by now. AbstractCommand should either implement DescribedElement and VisualizedElement or you should make getFaceDescriptor() public.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-439) make AbstractCommand.getFaceDescriptor() public

[Lieven D. (JIRA) <no...@sp...>]

    [ http://jira.springframework.org/browse/RCP-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_28728 ] 

Lieven Doclo commented on RCP-439:
----------------------------------

The text can already be retrieved through getText(), perhaps a getIcon() can be provided.

> make AbstractCommand.getFaceDescriptor() public
> -----------------------------------------------
>
>                 Key: RCP-439
>                 URL: http://jira.springframework.org/browse/RCP-439
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Command System
>    Affects Versions: 0.1.0, 0.2.0, 0.2.1
>            Reporter: Arne Limburg
>
> In some situations it is necessary to get displayable informations (like text, icon, ...) from a configured AbstractCommand, i.e. if you want to display a command with a component that does not inherit from AbstractButton.
> There is no possibilty for this by now. AbstractCommand should either implement DescribedElement and VisualizedElement or you should make getFaceDescriptor() public.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-509) Add Hibernate Validator notification to the GUI validation framework

[Lieven D. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo updated RCP-509:
-----------------------------

    Attachment: HibernateValidatorTest.java

Test added

> Add Hibernate Validator notification to the GUI validation framework
> --------------------------------------------------------------------
>
>                 Key: RCP-509
>                 URL: http://jira.springframework.org/browse/RCP-509
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>          Components: Application Framework
>            Reporter: Lieven Doclo
>         Attachments: HibernateRulesMessageInterpolator.java, HibernateRulesValidator.java, HibernateValidatorTest.java
>
>
> Use the Hibernate Validator to validate formobjects instead of or in combination with rules.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Closed: (RCP-97) Creating ActionCommands without a CommandFaceDescriptor causes memory leaks

[Jan H. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Hoskens closed RCP-97.
--------------------------

         Assignee: Jan Hoskens
       Resolution: Fixed
    Fix Version/s: 1.0.0

Removed Blank FaceDescriptor, more details in svn commit:

http://spring-rich-c.svn.sourceforge.net/spring-rich-c/?rev=1880&view=rev

> Creating ActionCommands without a CommandFaceDescriptor causes memory leaks
> ---------------------------------------------------------------------------
>
>                 Key: RCP-97
>                 URL: http://jira.springframework.org/browse/RCP-97
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Calvin Yu
>            Assignee: Jan Hoskens
>             Fix For: 1.0.0
>
>         Attachments: CommandFaceButtonManager.patch
>
>
> If no CommandFaceDescriptor is specified, then CommandFaceDescriptor.BLANK_FACE_DESCRIPTOR.  The ActionCommand's CommandFaceButtonManager then calls addPropertyChangeListener() on this descriptor, adding itself as the listener.  Unless another CommandFaceDescriptor is set for that ActionCommand, the CommandFaceButtonManager will never be removed from BLANK_FACE_DESCRIPTOR, and therefore the manager and command will never be garbage collected since the descriptor is a static.
> Possible solutions:
> 1) Remove AbstractPropertyChangePublisher's final modifiers on the addPropertyChangeListener() methods, so that they can be overriden by BLANK_FACE_DESCRIPTOR to be a no-op.
> 2) Create a new blank CommandFaceDescriptor instead of using a constant.
> 3) Modify CommandFaceButtonManager so that it isn't added as a PropertyChangeListener if the descriptor is BLANK_FACE_DESCRIPTOR.
> I've attached a patch to solution #3.  While I believe #3 isn't the most optimal solution, it does have less potential side effects to solutions #1 and #2.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Closed: (RCP-486) ShuttleList cannot be enabled/disabled

[Jan H. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Hoskens closed RCP-486.
---------------------------

         Assignee: Jan Hoskens
       Resolution: Fixed
    Fix Version/s: 0.3.0

I'm not using the shuttleList, but all suggested changes look reasonable. As this component is still in the sandbox, I don't see any argument to not apply this patch.

http://spring-rich-c.svn.sourceforge.net/viewvc/spring-rich-c?view=rev&revision=1878

> ShuttleList cannot be enabled/disabled
> --------------------------------------
>
>                 Key: RCP-486
>                 URL: http://jira.springframework.org/browse/RCP-486
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>          Components: Helper Classes
>    Affects Versions: 0.3.0
>            Reporter: Benoit Xhenseval
>            Assignee: Jan Hoskens
>             Fix For: 0.3.0
>
>         Attachments: ShuttleList-patch.txt
>
>
> Hi
> I'd like to offer a rough patch for the following issue.  It seems that the ShuttleList does not support changes to the 'enabled' meta data for a field.
> I've fixed this by simply overriding a setEnabled method on the ShuttleList which then enables (or not) the 2 lists and buttons).  The buttons had to become fields.
> I hope you can integrate this change.
> Thanks!
> Benoit

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Re: [Springframework-rcp-dev] Binding Errors

[Jan H. <jh...@sc...>]

I think you're missing the real point here.

There's a use-case in which these binding errors do make sense, I'll
elaborate with an example:

- say we have a date binded to a simple textfield
- user types in a string
- BeanPropertyAccessStrategy tries to set this on the backing bean
- exception is raised
- the ValidatingFormValueModel will catch this exception and raise a
binding error (meaning: setting the field in error state and providing an
error message)
- when the user corrects the error, the binding error is removed.

This is the only case in which the this exception-catching makes sense, in
other cases the exception should indeed fail fast. So we either keep this
use-case and correct its behavior (as I stated in my first mail) by only
catching binding exceptions and let others fall through or we completely
remove it and let all exceptions be thrown up to the user code.

So I do share your view on exceptions and fast failing, but remember that
we're talking about a specific use-case here. I do think we need to handle
this and that we cannot just remove this logic. Unless someone convinces
me otherwise, of course ;-)

Kind Regards,
Jan

>IMHO if a binding error occurs, an exception should be thrown back to
>the user code (=fail fast) and spring-richclient shouldn't catch/log etc.
>
>Spring fails fast when you configure a <property name="doesNotExists"...
>Hiberante fails fast when you configure an @Temporal on a String.
>Neither of them actually logs anything: the exception is thrown back to
>the user code (sometimes wrapped, but never eaten or logged). The user
>code usually doesn't handle it, so it ends up in the thread uncaught
>exception handler which nicely logs it as an error (if
>log4j/commons-logging/slf4j is configured, otherwise directly
>stacktraces it to sout).
>
>With kind regards,
>Geoffrey De Smet
>
>
>Jan Hoskens wrote:
> Hi all,
>
> While looking at issue RCP-308 and rereading the associated forum thread,
> I get the feeling that we need a BindingException. I'll shortly sketch the
> problem and my idea.
>
> When any exception occurs while setting a value, the exception is caught
> in DefaultFormModel.ValidatingFormValueModel.setValueSilently(). Hereafter
> a binding error is raised, the exception logged as debug and that's it.
> This can be a perfect use-case for some, but it also covers up exceptions
> that may come from any listener attached to that valuemodel (or wrapped
> model). The latter should definitely not be handled as a binding error.
>
> The issue states that the log level should be at least at the warning
> level, which stands out more when developing. This is correct but I think
> we do need more precise handling of errors. We could create a
> BindingException that any PropertyAccessStrategy can throw and catch only
> this exception to raise as a binding error (and log it as warning). All
> others should be passed upwards. So I'm thinking of adding a
> BindingException and using this in the
> BeanPropertyAccessStrategy.setValue(Object) to wrap any exceptions
> concerning the binding to the backing bean.
>
> What do you think?
>
> Kind Regards,
> Jan
>



 **** DISCLAIMER ****
 http://www.schaubroeck.be/maildisclaimer.htm

Re: [Springframework-rcp-dev] Binding Errors

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

IMHO if a binding error occurs, an exception should be thrown back to 
the user code (=fail fast) and spring-richclient shouldn't catch/log etc.

Spring fails fast when you configure a <property name="doesNotExists"...
Hiberante fails fast when you configure an @Temporal on a String.
Neither of them actually logs anything: the exception is thrown back to 
the user code (sometimes wrapped, but never eaten or logged). The user 
code usually doesn't handle it, so it ends up in the thread uncaught 
exception handler which nicely logs it as an error (if 
log4j/commons-logging/slf4j is configured, otherwise directly 
stacktraces it to sout).

With kind regards,
Geoffrey De Smet


Jan Hoskens wrote:
> Hi all,
> 
> While looking at issue RCP-308 and rereading the associated forum thread,
> I get the feeling that we need a BindingException. I'll shortly sketch the
> problem and my idea.
> 
> When any exception occurs while setting a value, the exception is caught
> in DefaultFormModel.ValidatingFormValueModel.setValueSilently(). Hereafter
> a binding error is raised, the exception logged as debug and that's it.
> This can be a perfect use-case for some, but it also covers up exceptions
> that may come from any listener attached to that valuemodel (or wrapped
> model). The latter should definitely not be handled as a binding error.
> 
> The issue states that the log level should be at least at the warning
> level, which stands out more when developing. This is correct but I think
> we do need more precise handling of errors. We could create a
> BindingException that any PropertyAccessStrategy can throw and catch only
> this exception to raise as a binding error (and log it as warning). All
> others should be passed upwards. So I'm thinking of adding a
> BindingException and using this in the
> BeanPropertyAccessStrategy.setValue(Object) to wrap any exceptions
> concerning the binding to the backing bean.
> 
> What do you think?
> 
> Kind Regards,
> Jan
> 
> 
> 
>  **** DISCLAIMER ****
>  http://www.schaubroeck.be/maildisclaimer.htm
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[Springframework-rcp-dev] Binding Errors

[Jan H. <jh...@sc...>]

Hi all,

While looking at issue RCP-308 and rereading the associated forum thread,
I get the feeling that we need a BindingException. I'll shortly sketch the
problem and my idea.

When any exception occurs while setting a value, the exception is caught
in DefaultFormModel.ValidatingFormValueModel.setValueSilently(). Hereafter
a binding error is raised, the exception logged as debug and that's it.
This can be a perfect use-case for some, but it also covers up exceptions
that may come from any listener attached to that valuemodel (or wrapped
model). The latter should definitely not be handled as a binding error.

The issue states that the log level should be at least at the warning
level, which stands out more when developing. This is correct but I think
we do need more precise handling of errors. We could create a
BindingException that any PropertyAccessStrategy can throw and catch only
this exception to raise as a binding error (and log it as warning). All
others should be passed upwards. So I'm thinking of adding a
BindingException and using this in the
BeanPropertyAccessStrategy.setValue(Object) to wrap any exceptions
concerning the binding to the backing bean.

What do you think?

Kind Regards,
Jan



 **** DISCLAIMER ****
 http://www.schaubroeck.be/maildisclaimer.htm

[Springframework-rcp-dev] [Spring-JIRA] Closed: (RCP-260) using addChildForm for validation reporting can leave FormBackedWizardPage form guard in an improper state

[Jan H. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Hoskens closed RCP-260.
---------------------------

         Assignee: Jan Hoskens  (was: Oliver Hutchison)
       Resolution: Cannot Reproduce
    Fix Version/s: 0.3.0

I cannot reproduce this. (tried several parent-child wizards)

This was probably fixed when the parent-child hierarchy was reviewed. The AbstractForm.hasErrors() method now delegates to the ValidationResultsModel which takes care of the parent-child relationship concerning errors/warnings etc...

Please reopen with an up-to-date test-case if it is still an issue.

> using addChildForm for validation reporting can leave FormBackedWizardPage form guard in an improper state
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: RCP-260
>                 URL: http://jira.springframework.org/browse/RCP-260
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>          Components: Binding System
>    Affects Versions: 0.1.0
>            Reporter: Frank Bowers
>            Assignee: Jan Hoskens
>             Fix For: 0.3.0
>
>
> I'm using the version of AbstractForm which has the fix for RCP-254.  
> 1. Construct a form with an embedded child form.
> 2. Use addChildForm to properly setup validation results reporting.
> 3. Use the form as the backing form for a FormBackedWizardPage
> 4. Place the form in such a state that there are validation errors only in the child form.
> 5. Invoke Next in the containing wizard to go to the FormBacked page
> 4. Note that the Next button is enabled although the page contains errors if you haven't made the fix below to AbstractForm.hasErrors().
> When FormBackedWizardPage.onAboutToShow is invoked a call to hasErrors is made.  Because the parent form doesn't have any errors the page is enabled although the child form has errors.
> The fix is to make AbstractForm.hasErrors() aware of the child forms:
>     public boolean hasErrors() {
>         if (formModel.getValidationResults().getHasErrors())return true;
>         else {
>             for (Iterator iter = childForms.values().iterator(); iter.hasNext(); ) {
>                 Form childForm = (Form) iter.next();
>                 if (childForm.hasErrors()) return true;
>             }
>         }            
>         return false;
>     }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Test 2 - Ignore

[<no...@sp...>]

This is a test message from JIRA. 
Server: Default SMTP Server
SMTP Port: 25
Description: 
From: no...@sp...
Host User Name: null

[Springframework-rcp-dev] Test - ignore

[Trevor M. <tre...@sp...>]

Thu 27 Dec 2007 18:55:35 PST

-- 
Trevor Marshall
Systems Administrator
SpringSource - the company behind Spring

+1 778 987 7431
tre...@sp...
http://www.springsource.com

Re: [Springframework-rcp-dev] JavaPolis discussions?

[Jonny W. <jwr...@gm...>]

Hi Peter,

Thanks for the reply and news of a pending release. Let me know if there is
anything I can do to help the release. I'd say the documentation is probably
going to be the hardest thing to get in shape, and I'd be happy to have a
crack at some sections of that if needs be, although my knowledge of the
code base isn't that deep.

I think the idea of creating a second version of the project, using the best
pieces, concepts etc. but incorporating changes in Spring, Java5, better
modularity, etc. is a good one. Did the use of OSGi via the Spring
integration come up as a potential direction? I've always thought that would
be a useful path to explore and potentially gain a lot of functionality for
free (ie all the bundles that come with the OSGi implementations) but I've
never had the time or suitable project to drive the exploration.

Jonny

On Dec 26, 2007 12:23 PM, Peter De Bruycker <pet...@gm...>
wrote:

> Jonny,
>
> I met with Jan Hoskens and Geoffrey De Smet, and with some others that
> are interested in Spring-RCP.
>
> We will be trying to get a 1.0 release out next month or so?
> In this release the following things will be included:
> - reference documentation
> - all open bugs will be fixed
>
> This 1.0 release will be final, and only bug-fix releases will be made.
>
> We will be starting a second version of the project, and we've been
> talking about a name change: Spring Desktop.
> New features will be:
> - better modularity
> - more integration with other frameworks
> - more annotation support (essentialy support for jdk5+)
> - better documentation
> - more samples
>
> A developer blog will also be started.
>
> regards,
>
> Peter
>
>

Re: [Springframework-rcp-dev] JavaPolis discussions?

[Xavier B. <xav...@ac...>]

Hi, it's nice the news of a 1.0 release.

I make some modifications to the messages_es.properties file, it is in
jira RCP-47.

I also changed the acegi security dependencies in the project for the
snapshot version of spring security release 2.0 this way when the
spring security is free, it's only needed a version change in the
parent pom.
The changes are in the RCP-513

Regards

Xavier Breton



On Dec 26, 2007 2:23 PM, Peter De Bruycker <pet...@gm...> wrote:
> Jonny,
>
> I met with Jan Hoskens and Geoffrey De Smet, and with some others that
> are interested in Spring-RCP.
>
> We will be trying to get a 1.0 release out next month or so?
> In this release the following things will be included:
> - reference documentation
> - all open bugs will be fixed
>
> This 1.0 release will be final, and only bug-fix releases will be made.
>
> We will be starting a second version of the project, and we've been
> talking about a name change: Spring Desktop.
> New features will be:
> - better modularity
> - more integration with other frameworks
> - more annotation support (essentialy support for jdk5+)
> - better documentation
> - more samples
>
> A developer blog will also be started.
>
> regards,
>
> Peter
>
> Jonny Wray schreef:
>
> > Hi,
> >
> > reading between the lines of a couple of recent messages I'm guessing
> > some of the developers met at the recent JavaPolis meeting and made
> > some decisions regarding a release, etc. Care to share what was
> > discussed and the decisions made?
> >
> > I've been trying recently to submit patches I've been working on
> > locally wrt both mac support and jide integration, and if there's
> > other areas I can help regarding moving towards a release I'm willing.
> >
> > Jonny
> > ------------------------------------------------------------------------
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Springframework-rcp-dev mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
> >
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>

Re: [Springframework-rcp-dev] JavaPolis discussions?

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

Jonny,

I met with Jan Hoskens and Geoffrey De Smet, and with some others that 
are interested in Spring-RCP.

We will be trying to get a 1.0 release out next month or so?
In this release the following things will be included:
- reference documentation
- all open bugs will be fixed

This 1.0 release will be final, and only bug-fix releases will be made.

We will be starting a second version of the project, and we've been 
talking about a name change: Spring Desktop.
New features will be:
- better modularity
- more integration with other frameworks
- more annotation support (essentialy support for jdk5+)
- better documentation
- more samples

A developer blog will also be started.

regards,

Peter

Jonny Wray schreef:
> Hi,
>
> reading between the lines of a couple of recent messages I'm guessing 
> some of the developers met at the recent JavaPolis meeting and made 
> some decisions regarding a release, etc. Care to share what was 
> discussed and the decisions made?
>
> I've been trying recently to submit patches I've been working on 
> locally wrt both mac support and jide integration, and if there's 
> other areas I can help regarding moving towards a release I'm willing.
>
> Jonny
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>   

Re: [Springframework-rcp-dev] Reference manual in docbook format => improvements

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

I've moved it to it's own separate module because spring and hibernate 
do it that way and it seems cleaner.

So now it's under
/spring-richclient-manual/src/docbook/en

You can build the module spring-richclient-manual with a "mvn clean 
install".
There are 3 docbook plugins: mojo's (=sucks), jboss's (= I 've used that 
one) and agilejava (= used by spring-osgi).
I haven't tested agilejava's one yet, nor have I used a decent style on 
the jboss's one yet, but at least I get some html output :)

Here's the current manual (with exception handling section):
http://users.telenet.be/geoffrey/tmp/spring-richclient/manual/html_single/

I don't have much more time to put into this (as I am gonna put more 
time into drools-solver...), but if anyone else wants to continue this 
work, there are 2 things I would like to suggest:
- try out the agilejava docbook plugin with the Spring style
- get it to publish on the website ("mvn site-deploy")
This should be pretty trivial, as spring-osgi already does both already:
http://springframework.svn.sourceforge.net/viewvc/springframework/spring-osgi/trunk/docs/pom.xml?view=markup
http://code.google.com/p/docbkx-tools/

Have fun :)

With kind regards,
Geoffrey De Smet


Geoffrey De Smet wrote:
> I've started a reference manual in the docbook format.
> Docbook is the format used by reference manuals of spring, spring-osgi, 
> hibernate, seam, drools, ...
> 
> It's located under
>   /src/docbook/en
> There is currently 1 section (= chapter or subchapter or subsubchapter):
> exception handling.
> 
> You can easily copy-paste that file to start a new section.
> To edit a section, I can recommend the WYSI almost WYG editor XML mind 
> (the personal edition is free for non-commercial use).
>    http://www.xmlmind.com/xmleditor/download.shtml
> 
> Learn to use of:
> - the shortcut control-j (add a new element after the current
> - these elements:
> -- para
> -- literal inside a para (= java code inside a para)
> -- emphasis and emphasis-bold
> -- section (sections can be nested)
> -- programlisting (= to show java code or xml)
> -- mediaobject (= to show images)
> - using the top right buttons to select an entire element (such as 
> section etc)
> 
> Put the images in the same directory as the docbook file.
> When in doubt, take a look at how the spring reference manual is written.
> 
> Feed-back, questions, improvements, etc welcome.
> I am still working on using the docbook plugins to output pdf, 
> single_html and html.
> 

[Springframework-rcp-dev] Reference manual in docbook format: how to add to it

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

I've started a reference manual in the docbook format.
Docbook is the format used by reference manuals of spring, spring-osgi, 
hibernate, seam, drools, ...

It's located under
  /src/docbook/en
There is currently 1 section (= chapter or subchapter or subsubchapter):
exception handling.

You can easily copy-paste that file to start a new section.
To edit a section, I can recommend the WYSI almost WYG editor XML mind 
(the personal edition is free for non-commercial use).
   http://www.xmlmind.com/xmleditor/download.shtml

Learn to use of:
- the shortcut control-j (add a new element after the current
- these elements:
-- para
-- literal inside a para (= java code inside a para)
-- emphasis and emphasis-bold
-- section (sections can be nested)
-- programlisting (= to show java code or xml)
-- mediaobject (= to show images)
- using the top right buttons to select an entire element (such as 
section etc)

Put the images in the same directory as the docbook file.
When in doubt, take a look at how the spring reference manual is written.

Feed-back, questions, improvements, etc welcome.
I am still working on using the docbook plugins to output pdf, 
single_html and html.

-- 
With kind regards,
Geoffrey De Smet

Re: [Springframework-rcp-dev] SpringFramework JIRA is Moving!! JIRA Outage Friday Dec 21 @ 4am CST

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

It does look like the e-mail's of jira's no longer comes through?

With kind regards,
Geoffrey De Smet


Geoffrey De Smet wrote:
> Changed to http://jira.springframework.org/browse/RCP
> 
> Will be done on the next site deploy
> 
> With kind regards,
> Geoffrey De Smet
> 
> 
> Geoffrey De Smet wrote:
>> I 'll update the site for this issue too.
>> But I can't really make an issue for it
>>
>> http://forum.springframework.org/showthread.php?t=47680
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [Springframework-rcp-dev] SpringFramework JIRA is Moving!! JIRA Outage Friday Dec 21 @ 4am CST

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

Changed to http://jira.springframework.org/browse/RCP

Will be done on the next site deploy

With kind regards,
Geoffrey De Smet


Geoffrey De Smet wrote:
> I 'll update the site for this issue too.
> But I can't really make an issue for it
> 
> http://forum.springframework.org/showthread.php?t=47680

[Springframework-rcp-dev] JavaPolis discussions?

[Jonny W. <jwr...@gm...>]

Hi,

reading between the lines of a couple of recent messages I'm guessing some
of the developers met at the recent JavaPolis meeting and made some
decisions regarding a release, etc. Care to share what was discussed and the
decisions made?

I've been trying recently to submit patches I've been working on locally wrt
both mac support and jide integration, and if there's other areas I can help
regarding moving towards a release I'm willing.

Jonny

Re: [Springframework-rcp-dev] static message source problem

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

Lieven,

This is more an issue for the core springframework project, as
StaticMessageSource is in the core project.

Also note that the Locale.ROOT constant was introduced in JDK 1.6, so it's
possible the StaticMessageSource doesn't work correctly with it.

regards,

Peter

On Dec 21, 2007 11:10 AM, Lieven Doclo <ld...@sc...> wrote:

> Static message source does not fall back to ROOT locale when no message
> is found:
>
> public class StaticMessageSourceTest extends TestCase
> {
>     private StaticMessageSource source;
>     private MessageSourceAccessor accessor;
>
>     protected void setUp() throws Exception
>     {
>         source = new StaticMessageSource();
>         source.addMessage("key", Locale.ROOT, "root key");
>         accessor = new MessageSourceAccessor(source);
>     }
>
>     public void testKeys()
>     {
>         assertEquals("root key", accessor.getMessage("key"));
>     }
> }
>
> MessageSourceAccessor will try to find key_nl_BE in my case, and throws
> a NoSuchMessageException. It should try and find key_nl and key if not
> found.
>
> Something else I discovered:
>
> source.addMessage("key", Locale.ROOT, "root key") does not add "key" as
> a code, but "key_"... Shouldn't it omit the "_" sign when the locale is
> the ROOT locale ("")?
>
> Greetz,
>
> Lieven
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>

[Springframework-rcp-dev] static message source problem

[Lieven D. <ld...@sc...>]

Static message source does not fall back to ROOT locale when no message 
is found:

public class StaticMessageSourceTest extends TestCase
{
     private StaticMessageSource source;
     private MessageSourceAccessor accessor;

     protected void setUp() throws Exception
     {
         source = new StaticMessageSource();
         source.addMessage("key", Locale.ROOT, "root key");
         accessor = new MessageSourceAccessor(source);
     }

     public void testKeys()
     {
         assertEquals("root key", accessor.getMessage("key"));
     }
}

MessageSourceAccessor will try to find key_nl_BE in my case, and throws 
a NoSuchMessageException. It should try and find key_nl and key if not 
found.

Something else I discovered:

source.addMessage("key", Locale.ROOT, "root key") does not add "key" as 
a code, but "key_"... Shouldn't it omit the "_" sign when the locale is 
the ROOT locale ("")?

Greetz,

Lieven

[Springframework-rcp-dev] [Spring-JIRA] Closed: (RCP-422) Update the schema's in the examples to match for spring 2.0

[Jan H. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/spring/browse/RCP-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Hoskens closed RCP-422.
---------------------------

    Resolution: Fixed

I did a final search on xml files with a DTD of spring, looks like I finally got them all.

> Update the schema's in the examples to match for spring 2.0
> -----------------------------------------------------------
>
>                 Key: RCP-422
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-422
>             Project: Spring Framework Rich Client Project
>          Issue Type: Task
>          Components: Samples
>    Affects Versions: 0.2.1
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>             Fix For: 0.3.0
>
>         Attachments: spring-richclient-petclinic-business.patch, spring-richclient-petclinic-client.patch, spring-richclient-petclinic-gui.patch, spring-richclient-petclinic-server.patch, spring-richclient-petclinic-standalone.patch, spring-richclient-samples-simple.patch, spring-richclient-samples-vldocking.patch, spring-richclient-support.patch
>
>
> Now use:
> <beans xmlns="http://www.springframework.org/schema/beans"
>             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xsi:schemaLocation="http://www.springframework.org/schema/beans
>                 http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
> Also replace singleton="false" with scope="singleton".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] SpringFramework JIRA is Moving!! JIRA Outage Friday Dec 21 @ 4am CST

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

I 'll update the site for this issue too.
But I can't really make an issue for it

http://forum.springframework.org/showthread.php?t=47680
-- 
With kind regards,
Geoffrey De Smet