[jbosside-dev] RE: Memory leak in DroolsIDE
by Mark Proctor
Awesome, thank you - we'll get a JIRA made for that today.
________________________________
From: marshall.jboss(a)gmail.com [mailto:marshall.jboss@gmail.com] On
Behalf Of Marshall Culpepper
Sent: 15 August 2006 01:42
To: jbosside-dev(a)lists.jboss.org; Kris Verlaenen; Mark Proctor; Michael
Neale
Subject: FW: Memory leak in DroolsIDE
FYI Rob Stryker (our JBossAS adapter lead) has found a memory leak in
the DroolsIDE code:
On 8/14/06, Robert Stryker < rob.stryker(a)jboss.com
<mailto:rob.stryker@jboss.com> > wrote:
Hey Marshall:
Please forward this over to the rules guy. I found a memory leak in
his code.
The class RuleHelperActionDelegate ( svn
<http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-ide/src/main
/java/org/drools/ide/menu/RuleHelperActionDelegate.java> ) has a memory
leak. Specifically:
the Delegate itself is responsible for deleting any and all created Menu
widgets. In the current implementation, the getMenu(Control) method is
as follows:
Menu menu = new Menu( parent );
final Shell shell = parent.getShell();
addProjectWizard( menu, shell );
addRuleWizard( menu,shell );
addDSLWizard( menu, shell );
addDTWizard( menu,shell );
return menu;
Clearly, new menu widgets are created each time and are never disposed
of. A correct implementation of this interface is available at
org.eclipse.wst.server.ui.internal.webbrowser.SwitchBrowserWorkbenchActi
on . Specifically, the getMenu(Control) method should first dispose of
the last menu, then create the new ones.
public Menu getMenu(Control parent) {
setMenu(new Menu(parent));
//fillMenu(fMenu);
initMenu();
return fMenu;
}
private void setMenu(Menu menu) {
if (fMenu != null) {
fMenu.dispose();
}
fMenu = menu;
}
So... ... ... he needs to destroy his menus before creating new ones =]
--
Marshall Culpepper
marshall.culpepper(a)jboss.com
JBoss Eclipse IDE Lead, JBoss Inc.
18 years, 3 months
[jbosside-dev] tag for tools
by Max Rydahl Andersen
TOOLS_3_2_0_beta7
still missing some docs, but not something that should stop the release
build.
Let me know when there is a download to test (note, i also updated the
testsuite so should still run ;)
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
max(a)hibernate.org
http://hibernate.org
JBoss a division of Red Hat
max.andersen(a)jboss.com
18 years, 3 months
[jbosside-dev] FW: Memory leak in DroolsIDE
by Marshall Culpepper
FYI Rob Stryker (our JBossAS adapter lead) has found a memory leak in the
DroolsIDE code:
On 8/14/06, Robert Stryker <rob.stryker(a)jboss.com> wrote:
>
> Hey Marshall:
>
> Please forward this over to the rules guy. I found a memory leak in his
> code.
>
> The class RuleHelperActionDelegate ( svn<http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-ide/src/main/j...>)
> has a memory leak. Specifically:
>
> the Delegate itself is responsible for deleting any and all created Menu
> widgets. In the current implementation, the getMenu(Control) method is as
> follows:
>
> Menu menu = new Menu( parent );
>
> final Shell shell = parent.getShell();
> addProjectWizard( menu, shell );
> addRuleWizard( menu,shell );
> addDSLWizard( menu, shell );
> addDTWizard( menu,shell );
>
> return menu;
>
>
> Clearly, new menu widgets are created each time and are never disposed of.
> A correct implementation of this interface is available at
> org.eclipse.wst.server.ui.internal.webbrowser.SwitchBrowserWorkbenchAction. Specifically, the getMenu(Control) method should first dispose of the last
> menu, then create the new ones.
>
> public Menu getMenu(Control parent) {
> setMenu(new Menu(parent));
> //fillMenu(fMenu);
> initMenu();
> return fMenu;
> }
>
> private void setMenu(Menu menu) {
> if (fMenu != null) {
> fMenu.dispose();
> }
> fMenu = menu;
> }
>
>
> So... ... ... he needs to destroy his menus before creating new ones =]
>
--
Marshall Culpepper
marshall.culpepper(a)jboss.com
JBoss Eclipse IDE Lead, JBoss Inc.
18 years, 3 months
[jbosside-dev] JBossWS
by lars@eviware.com
Hi Marshall,I have split a plugin in 2. This affects the feature com.eviware.soapui.jbosside_feature that you use. Before, this feature used the plugin com.eviware.soapui.eclipse.ui, but now it uses com.eviware.soapui.eclipse.core instead.So, perhaps you need to update your build scripts.Regards,Lars Høidahl, eviware
18 years, 3 months