You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(37) |
Jun
(141) |
Jul
(111) |
Aug
(91) |
Sep
(79) |
Oct
(151) |
Nov
(161) |
Dec
(93) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(40) |
Feb
(60) |
Mar
(43) |
Apr
(90) |
May
(31) |
Jun
(114) |
Jul
(35) |
Aug
(112) |
Sep
(305) |
Oct
(151) |
Nov
(122) |
Dec
(103) |
2006 |
Jan
(65) |
Feb
(57) |
Mar
(475) |
Apr
(276) |
May
(482) |
Jun
(134) |
Jul
(127) |
Aug
(188) |
Sep
(271) |
Oct
(220) |
Nov
(74) |
Dec
(41) |
2007 |
Jan
(121) |
Feb
(50) |
Mar
(36) |
Apr
(11) |
May
(31) |
Jun
(12) |
Jul
(73) |
Aug
(41) |
Sep
(59) |
Oct
(33) |
Nov
(60) |
Dec
(111) |
2008 |
Jan
(139) |
Feb
(49) |
Mar
(87) |
Apr
(43) |
May
(10) |
Jun
(25) |
Jul
(114) |
Aug
(17) |
Sep
(25) |
Oct
(199) |
Nov
(94) |
Dec
(45) |
2009 |
Jan
(36) |
Feb
(14) |
Mar
(29) |
Apr
(32) |
May
(49) |
Jun
(18) |
Jul
(68) |
Aug
(34) |
Sep
(34) |
Oct
(11) |
Nov
(10) |
Dec
(14) |
2010 |
Jan
(35) |
Feb
(12) |
Mar
(23) |
Apr
(17) |
May
(4) |
Jun
(1) |
Jul
(4) |
Aug
|
Sep
(2) |
Oct
|
Nov
(10) |
Dec
|
2011 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
2012 |
Jan
(2) |
Feb
(1) |
Mar
(8) |
Apr
(3) |
May
|
Jun
|
Jul
(4) |
Aug
(3) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
2013 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(8) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(3) |
Dec
(4) |
2014 |
Jan
(2) |
Feb
(2) |
Mar
(3) |
Apr
(1) |
May
(5) |
Jun
(1) |
Jul
(13) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
(15) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2019 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2025 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Ryan O. (JIRA) <no...@sp...> - 2010-01-25 21:59:04
|
update version of the spring-binding dependency to 2+ ----------------------------------------------------- Key: RCP-627 URL: https://jira.springsource.org/browse/RCP-627 Project: Spring Rich Client Project Issue Type: Improvement Components: Build System, Core Affects Versions: 1.1.0 Reporter: Ryan Ovrevik Assignee: Lieven Doclo Priority: Minor Updating spring-binding to a version 2+ is a key dependency that prevents cleanly updating to spring framework 3 and the spring enterprise repository. Another intermediate (admittedly dirty) possibility might be to merge the needed components from spring-binding version 1 into RCP and pulling the remaining dependencies from spring-binding version 2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Adam A. (JIRA) <no...@sp...> - 2010-01-21 17:03:07
|
[ https://jira.springsource.org/browse/RCP-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Armistead updated RCP-626: ------------------------------- Attachment: RCP-626_1.patch Downgraded logger lines to debug, clearing docking desktop before calling super.showPage, changed conditional to check for null oldPage, and removed extraneous casting. > VLDocking integration broken > ---------------------------- > > Key: RCP-626 > URL: https://jira.springsource.org/browse/RCP-626 > Project: Spring Rich Client Project > Issue Type: Bug > Reporter: Adam Armistead > Assignee: Lieven Doclo > Attachments: RCP-626.patch, RCP-626_1.patch > > > In the VLDocking integrations each application page is its own DockingDesktop instance. Pages are not being saved and loaded correctly resulting in floating dockables remaining on screen after showing a new page that should not show the floating dockable as a view. Floating dockables are not positioned correctly when a page is shown, and when closing a page it is saved once for each page created, so if you create 5 application pages and close one of them it is saved 5 times in a row. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Adam A. (JIRA) <no...@sp...> - 2010-01-21 16:48:05
|
[ https://jira.springsource.org/browse/RCP-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50373#action_50373 ] Adam Armistead commented on RCP-626: ------------------------------------ I have downgraded the logging lines to debug and am clearing the dockables before calling super.showPage(). As for calling oldPage.close() I will change the conditional to if(oldPage != null) which is probably more accurate and remove the casting. > VLDocking integration broken > ---------------------------- > > Key: RCP-626 > URL: https://jira.springsource.org/browse/RCP-626 > Project: Spring Rich Client Project > Issue Type: Bug > Reporter: Adam Armistead > Assignee: Lieven Doclo > Attachments: RCP-626.patch > > > In the VLDocking integrations each application page is its own DockingDesktop instance. Pages are not being saved and loaded correctly resulting in floating dockables remaining on screen after showing a new page that should not show the floating dockable as a view. Floating dockables are not positioned correctly when a page is shown, and when closing a page it is saved once for each page created, so if you create 5 application pages and close one of them it is saved 5 times in a row. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Rogan D. (JIRA) <no...@sp...> - 2010-01-21 16:28:04
|
[ https://jira.springsource.org/browse/RCP-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50372#action_50372 ] Rogan Dawes commented on RCP-626: --------------------------------- Well, maybe not remove, but maybe downgrade to debug or some lesser level? > VLDocking integration broken > ---------------------------- > > Key: RCP-626 > URL: https://jira.springsource.org/browse/RCP-626 > Project: Spring Rich Client Project > Issue Type: Bug > Reporter: Adam Armistead > Assignee: Lieven Doclo > Attachments: RCP-626.patch > > > In the VLDocking integrations each application page is its own DockingDesktop instance. Pages are not being saved and loaded correctly resulting in floating dockables remaining on screen after showing a new page that should not show the floating dockable as a view. Floating dockables are not positioned correctly when a page is shown, and when closing a page it is saved once for each page created, so if you create 5 application pages and close one of them it is saved 5 times in a row. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Adam A. (JIRA) <no...@sp...> - 2010-01-21 16:17:04
|
[ https://jira.springsource.org/browse/RCP-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50370#action_50370 ] Adam Armistead commented on RCP-626: ------------------------------------ There are only 2 logging lines at the info level in my code. One when an application window is created and one when an application page is created. Should I get rid of both of them? I will look into and test calling the close method to see why I did it that way. > VLDocking integration broken > ---------------------------- > > Key: RCP-626 > URL: https://jira.springsource.org/browse/RCP-626 > Project: Spring Rich Client Project > Issue Type: Bug > Reporter: Adam Armistead > Assignee: Lieven Doclo > Attachments: RCP-626.patch > > > In the VLDocking integrations each application page is its own DockingDesktop instance. Pages are not being saved and loaded correctly resulting in floating dockables remaining on screen after showing a new page that should not show the floating dockable as a view. Floating dockables are not positioned correctly when a page is shown, and when closing a page it is saved once for each page created, so if you create 5 application pages and close one of them it is saved 5 times in a row. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Rogan D. (JIRA) <no...@sp...> - 2010-01-21 15:51:06
|
[ https://jira.springsource.org/browse/RCP-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50367#action_50367 ] Rogan Dawes commented on RCP-623: --------------------------------- Code looks obviously correct. Please apply. > Add ResizeWeight support to VLDocking > ------------------------------------- > > Key: RCP-623 > URL: https://jira.springsource.org/browse/RCP-623 > Project: Spring Rich Client Project > Issue Type: Improvement > Components: Integration > Affects Versions: 1.1.0 > Reporter: Adam Armistead > Assignee: Lieven Doclo > Priority: Minor > Attachments: RCP-623.patch > > > VLDocking should be able to support resize weight on the dock key. Adding this support is trivial and should only require adding a resizeWeight property to VLDockingViewDescriptor with get/set methods and to set the assigned resizeWeight to the DockKey in the ViewDescriptorDockable constructor. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Rogan D. (JIRA) <no...@sp...> - 2010-01-21 15:48:04
|
[ https://jira.springsource.org/browse/RCP-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50366#action_50366 ] Rogan Dawes commented on RCP-626: --------------------------------- The code looks fine, although there are perhaps a few too many logging lines at info level. You might also want to clear the floating dockables before calling super.showPage(), rather than after. Finally, this seems unnecessary: {quote} + // Saves the layout for the current page before displaying the new one. + if(oldPage instanceof VLDockingApplicationPage) { + ((VLDockingApplicationPage)oldPage).close(); + } {quote} ApplicationPage specifies .close() anyway, so there is no need for the conditional and casting. > VLDocking integration broken > ---------------------------- > > Key: RCP-626 > URL: https://jira.springsource.org/browse/RCP-626 > Project: Spring Rich Client Project > Issue Type: Bug > Reporter: Adam Armistead > Assignee: Lieven Doclo > Attachments: RCP-626.patch > > > In the VLDocking integrations each application page is its own DockingDesktop instance. Pages are not being saved and loaded correctly resulting in floating dockables remaining on screen after showing a new page that should not show the floating dockable as a view. Floating dockables are not positioned correctly when a page is shown, and when closing a page it is saved once for each page created, so if you create 5 application pages and close one of them it is saved 5 times in a row. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Adam A. (JIRA) <no...@sp...> - 2010-01-21 01:13:04
|
[ https://jira.springsource.org/browse/RCP-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Armistead updated RCP-626: ------------------------------- Attachment: RCP-626.patch I removed the page listener and associated layout saving code in the VLDockingApplicationPageFactory as this was causing the desktop layout to be saved once for each page created. Pages are saved when closed anyway. Which works on a show page command and when closing the application. I created a VLDockingApplicationWindowFactory and VLDockingApplicationWindow that interact with the VLDockingApplicationPage to load and save layouts and clear the docking desktop when a new page is shown. I removed loading the initial layout from the createControl method in the VLDockingApplicationPage as this was attempting to layout floating dockables whose position is dependent on the main window before the docking desktop was added to the window. This was pulled out and put in the loadInitialLayout method which is called from VLDockingApplicationWindow during a show page command AFTER the docking desktop is added to the main window. To configure the VLDocking support the only thing that needs to be done differently is in the ApplicationContext xml file you must specify a VLDockingApplicationWindowFactory bean and reference this with an idref tag in the application services. > VLDocking integration broken > ---------------------------- > > Key: RCP-626 > URL: https://jira.springsource.org/browse/RCP-626 > Project: Spring Rich Client Project > Issue Type: Bug > Reporter: Adam Armistead > Assignee: Lieven Doclo > Attachments: RCP-626.patch > > > In the VLDocking integrations each application page is its own DockingDesktop instance. Pages are not being saved and loaded correctly resulting in floating dockables remaining on screen after showing a new page that should not show the floating dockable as a view. Floating dockables are not positioned correctly when a page is shown, and when closing a page it is saved once for each page created, so if you create 5 application pages and close one of them it is saved 5 times in a row. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Adam A. (JIRA) <no...@sp...> - 2010-01-21 00:57:12
|
VLDocking integration broken ---------------------------- Key: RCP-626 URL: https://jira.springsource.org/browse/RCP-626 Project: Spring Rich Client Project Issue Type: Bug Reporter: Adam Armistead Assignee: Lieven Doclo In the VLDocking integrations each application page is its own DockingDesktop instance. Pages are not being saved and loaded correctly resulting in floating dockables remaining on screen after showing a new page that should not show the floating dockable as a view. Floating dockables are not positioned correctly when a page is shown, and when closing a page it is saved once for each page created, so if you create 5 application pages and close one of them it is saved 5 times in a row. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Adam A. (JIRA) <no...@sp...> - 2010-01-19 18:55:06
|
[ https://jira.springsource.org/browse/RCP-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Armistead updated RCP-625: ------------------------------- Attachment: RCP-625.patch > AbstractApplicationWindow createPage method uses confusing variable name > ------------------------------------------------------------------------ > > Key: RCP-625 > URL: https://jira.springsource.org/browse/RCP-625 > Project: Spring Rich Client Project > Issue Type: Refactoring > Reporter: Adam Armistead > Assignee: Lieven Doclo > Attachments: RCP-625.patch > > > The createPage method in the AbstractApplicationWindow get the ApplicationPageFactory from the registered application services and assigns it to a variable with the confusing name of "windowFactory" and uses it to create a new application page. The variable should probably be named "pageFactory". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Adam A. (JIRA) <no...@sp...> - 2010-01-19 18:53:10
|
AbstractApplicationWindow createPage method uses confusing variable name ------------------------------------------------------------------------ Key: RCP-625 URL: https://jira.springsource.org/browse/RCP-625 Project: Spring Rich Client Project Issue Type: Refactoring Reporter: Adam Armistead Assignee: Lieven Doclo The createPage method in the AbstractApplicationWindow get the ApplicationPageFactory from the registered application services and assigns it to a variable with the confusing name of "windowFactory" and uses it to create a new application page. The variable should probably be named "pageFactory". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Press c. <tyf...@gm...> - 2010-01-17 06:36:08
|
"Love Don't Cost a Thing" clip special edition with NAKED Jennifer Lopez! Just look! http://yy.vc/naked |
From: Ryan O. (JIRA) <no...@sp...> - 2010-01-11 16:27:05
|
migrate pom dependencies to come from the SpringSource Enterprise Bundle Repository ------------------------------------------------------------------------------------ Key: RCP-624 URL: https://jira.springsource.org/browse/RCP-624 Project: Spring Rich Client Project Issue Type: Refactoring Components: Build System Affects Versions: 1.1.1 Reporter: Ryan Ovrevik Assignee: Lieven Doclo Priority: Minor Update all poms to retrieve dependencies from the SpringSource Enterprise Bundle Repository. This seems like a reasonable precondition for updating the project(s) to utilize spring3. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Christian H. (JIRA) <no...@sp...> - 2010-01-07 13:08:32
|
[ https://jira.springsource.org/browse/RCP-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50001#action_50001 ] Christian Heilmann commented on RCP-589: ---------------------------------------- With commit r2144 the method ApplicationPage.showView(ViewDescriptor viewDescriptor) was removed. This method is necessary for showing dynamically created views (see bug RCP-363 that is about the same issue for pages) and was available in RCP 1.0. What's the suggested way to show dynamically created views? Could you please re-add this method? > ApplicationPage: add showView(String id, Object input) > ------------------------------------------------------ > > Key: RCP-589 > URL: https://jira.springsource.org/browse/RCP-589 > Project: Spring Rich Client Project > Issue Type: Improvement > Reporter: Peter De Bruycker > Assignee: Peter De Bruycker > > add showView(String id, Object input) to ApplicationPage > A setInput method would be added to the View interface, with an empty implementation in AbstractView. Concrete implementations could then implement this method to update its state. This method would be called by the showView method in the ApplicationPage -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Adam A. (JIRA) <no...@sp...> - 2010-01-06 19:26:22
|
[ https://jira.springsource.org/browse/RCP-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Armistead updated RCP-623: ------------------------------- Attachment: RCP-623.patch > Add ResizeWeight support to VLDocking > ------------------------------------- > > Key: RCP-623 > URL: https://jira.springsource.org/browse/RCP-623 > Project: Spring Rich Client Project > Issue Type: Improvement > Components: Integration > Affects Versions: 1.1.0 > Reporter: Adam Armistead > Assignee: Lieven Doclo > Priority: Minor > Attachments: RCP-623.patch > > > VLDocking should be able to support resize weight on the dock key. Adding this support is trivial and should only require adding a resizeWeight property to VLDockingViewDescriptor with get/set methods and to set the assigned resizeWeight to the DockKey in the ViewDescriptorDockable constructor. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Adam A. (JIRA) <no...@sp...> - 2010-01-06 19:08:26
|
Add ResizeWeight support to VLDocking ------------------------------------- Key: RCP-623 URL: https://jira.springsource.org/browse/RCP-623 Project: Spring Rich Client Project Issue Type: Improvement Components: Integration Affects Versions: 1.1.0 Reporter: Adam Armistead Assignee: Lieven Doclo Priority: Minor VLDocking should be able to support resize weight on the dock key. Adding this support is trivial and should only require adding a resizeWeight property to VLDockingViewDescriptor with get/set methods and to set the assigned resizeWeight to the DockKey in the ViewDescriptorDockable constructor. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Valeria <oli...@gm...> - 2010-01-03 07:33:40
|
Hi to my group friends! Have You seen this new video? http://shrtb.us/21332 |
From: Celicia J. <sau...@gm...> - 2010-01-01 05:30:46
|
Hi to all. Here isour wedding video. Happy New Year! http://tpal.us/wedding2 |
From: Anna F <plu...@gm...> - 2009-12-31 01:54:56
|
O-ha-ha What are they doing? PS Just a joke, but so funny :) http://snipurl.com/tx2r6 |
From: Vidinha A. <re...@dc...> - 2009-12-24 12:07:04
|
Aketh wood or weald, How long she stood on the roof of the world As he stood on my shield. "The new wild world forgetteth her As foam fades on the sea, How long she stood with her foot on Man As he with his foot on me. "No more shall the brown men of the south Move like the ants in lines, To quiet men with olives Or madden men with vines. "No more shall the white towns of the south, Where Tiber and Nilus run, Sitting around a secret sea Worship a secret sun. "The blind gods roar for Rome fallen, And forum and garland gone, For the ice of the north is broken, And the sea of the north comes on. "The blind gods roar and rave and dream Of all cities under the sea, For the heart of the north is broken, And the blood of the north is free. "Down from the dome of the world we come, Rivers on rivers down, Under us swirl the sects and hordes And the high dooms we drown. "Down from the dome of the world and down, Struck flying as a skiff On a river in spate is spun and swirled Until we come to the end of the world That breaks short, like a cliff. "And when we come to the end of the world For me, I count it fit To take the leap like a good river, Shot shrieking over it. "But whatso hap at the end of the world, Where Nothing is struck and sounds, It is not, by |
From: Helga M. <mit...@gm...> - 2009-12-23 23:18:18
|
One short joke clip to cheer Your up! http://www.tcp3.com/helga-4315 |
From: Andreas K. (JIRA) <no...@sp...> - 2009-12-01 13:01:42
|
[ https://jira.springsource.org/browse/RCP-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Kuhtz updated RCP-622: ------------------------------ Attachment: patch-622.diff I think this is the patch for this problem. > ListBinding with SingleSelectionMode does not work with spring-binding 1.0.5 > ---------------------------------------------------------------------------- > > Key: RCP-622 > URL: https://jira.springsource.org/browse/RCP-622 > Project: Spring Rich Client Project > Issue Type: Bug > Components: Core > Affects Versions: 1.1.0 > Reporter: Christian Heilmann > Assignee: Lieven Doclo > Attachments: patch-622.diff > > > spring richclient has a dependency to spring-binding in version 1.0.5 > The class ListBinding is catching IllegalArgumentException in the method isPropertyConversionExecutorAvailable(), but in spring-binding 1.0.5 the IllegalArgumentException was replaced by a ConversionException, and so the ListBinding with single-selection does not work with spring-binding 1.0.5. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Christian H. (JIRA) <no...@sp...> - 2009-11-26 16:46:08
|
ListBinding with SingleSelectionMode does not work with spring-binding 1.0.5 ---------------------------------------------------------------------------- Key: RCP-622 URL: https://jira.springsource.org/browse/RCP-622 Project: Spring Rich Client Project Issue Type: Bug Components: Core Affects Versions: 1.1.0 Reporter: Christian Heilmann Assignee: Lieven Doclo spring richclient has a dependency to spring-binding in version 1.0.5 The class ListBinding is catching IllegalArgumentException in the method isPropertyConversionExecutorAvailable(), but in spring-binding 1.0.5 the IllegalArgumentException was replaced by a ConversionException, and so the ListBinding with single-selection does not work with spring-binding 1.0.5. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Chris.Hunter (JIRA) <no...@sp...> - 2009-11-24 10:46:04
|
[ https://jira.springsource.org/browse/RCP-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=48557#action_48557 ] Chris.Hunter commented on RCP-621: ---------------------------------- it happened in multi-thread accessing of the two methods, seems not consider the synchronization of using the field in multiple threads : private final HashSet members = new LinkedHashSet(5); > calling CommandGroup.add(AbstractCommand command) or CommandGroup.remove(AbstractCommand command) methods caused a ConcurrentModificationException > -------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: RCP-621 > URL: https://jira.springsource.org/browse/RCP-621 > Project: Spring Rich Client Project > Issue Type: Bug > Components: Core > Affects Versions: 1.1.1 > Environment: java version "1.6.0_15" > Java(TM) SE Runtime Environment (build 1.6.0_15-b03) > Java HotSpot(TM) Client VM (build 14.1-b02, mixed mode, sharing) > Reporter: Chris.Hunter > Assignee: Lieven Doclo > Original Estimate: 0.12d > Remaining Estimate: 0.12d > > java.util.ConcurrentModificationException > at java.util.LinkedHashMap$LinkedHashIterator.nextEntry(Unknown Source) > at java.util.LinkedHashMap$KeyIterator.next(Unknown Source) > at org.springframework.richclient.command.ExpansionPointGroupMember.fill(ExpansionPointGroupMember.java:169) > at org.springframework.richclient.command.GroupMemberContainerManager.rebuildControlsFor(GroupMemberContainerManager.java:64) > at org.springframework.richclient.command.GroupMemberList.rebuildControls(GroupMemberList.java:91) > at org.springframework.richclient.command.CommandGroup.rebuildAllControls(CommandGroup.java:352) > at org.springframework.richclient.command.CommandGroup.rebuildIfNecessary(CommandGroup.java:343) > at org.springframework.richclient.command.CommandGroup.remove(CommandGroup.java:307) > at org.springframework.richclient.command.CommandGroup.remove(CommandGroup.java:296) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Chris.Hunter (JIRA) <no...@sp...> - 2009-11-24 10:36:11
|
calling CommandGroup.add(AbstractCommand command) or CommandGroup.remove(AbstractCommand command) methods caused a ConcurrentModificationException -------------------------------------------------------------------------------------------------------------------------------------------------- Key: RCP-621 URL: https://jira.springsource.org/browse/RCP-621 Project: Spring Rich Client Project Issue Type: Bug Components: Core Affects Versions: 1.1.1 Environment: java version "1.6.0_15" Java(TM) SE Runtime Environment (build 1.6.0_15-b03) Java HotSpot(TM) Client VM (build 14.1-b02, mixed mode, sharing) Reporter: Chris.Hunter Assignee: Lieven Doclo java.util.ConcurrentModificationException at java.util.LinkedHashMap$LinkedHashIterator.nextEntry(Unknown Source) at java.util.LinkedHashMap$KeyIterator.next(Unknown Source) at org.springframework.richclient.command.ExpansionPointGroupMember.fill(ExpansionPointGroupMember.java:169) at org.springframework.richclient.command.GroupMemberContainerManager.rebuildControlsFor(GroupMemberContainerManager.java:64) at org.springframework.richclient.command.GroupMemberList.rebuildControls(GroupMemberList.java:91) at org.springframework.richclient.command.CommandGroup.rebuildAllControls(CommandGroup.java:352) at org.springframework.richclient.command.CommandGroup.rebuildIfNecessary(CommandGroup.java:343) at org.springframework.richclient.command.CommandGroup.remove(CommandGroup.java:307) at org.springframework.richclient.command.CommandGroup.remove(CommandGroup.java:296) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |