This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Product Version: NetBeans IDE Dev (Build 200708150000) Java: 1.6.0_02; Java HotSpot(TM) Client VM 1.6.0_02-b06 System: Windows XP version 5.1 running on x86; & Windows Vista Scenario - tutorial "Performing Inserts, Updates, and Deletes". 1. Connect to DB Derby Travel. 2. Create new VWP project (Java EE 5, Classfish V2) 3. DnD Drop Down List on Designer. Change its property "id" from "dropDown1" to "personDD". DnD DB table PERSON on it. Use popup menu: - set "Auto-Submit on Change" to ON. - "Configure Virtual Forms..." - add new virtual form: "person, Yes, Yes". 4. DnD JSF component Table on Designer. DnD DB table TRIP on it. Result: - see attached screenshot "screenshot_1.jpg" - JSF components are bound to DB tables properly. 5. Use popupmenu item "Edit Event Handler -> processValueChange" for JSF component "personDD" and insert the following java code inside the created method "personDD_processValueChange()" Object selectedPersonId = personDD.getSelected(); try { personDataProvider.setCursorRow( personDataProvider.findFirst("PERSON.PERSONID", selectedPersonId)); getSessionBean1().getTripRowSet().setObject(1, selectedPersonId); tripDataProvider.refresh(); form1.discardSubmittedValues("save"); } catch (Exception e) { error("Cannot switch to person " + selectedPersonId); log("Cannot switch to person " + selectedPersonId, e); } 6. Save All and switch to Designer. Result: - see attached screenshots "screenshot_2.jpg" & "screenshot_2.jpg" - JSF components are NOT bound to DB tables.
Created attachment 46686 [details] screenshot
Created attachment 46687 [details] screenshot
Created attachment 46688 [details] screenshot
I couldn't reproduce using the latest dataconnectivity and project changes/ Binding for both the component and Table was maintained.
Need more information please
I can reproduce this using: Product Version: NetBeans 6 IDE Dev (Build 200708150000) Java: 1.5.0_12; Java HotSpot(TM) Client VM 1.5.0_12-b04 System: Windows Vista version 6.0 running on x86; Cp1252; en_US (nb) Woodstock 4.1: 200708141616
My IDE log shows an insync error (attaching full) java.util.ConcurrentModificationException at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:4 49) at java.util.AbstractList$Itr.next(AbstractList.java:420) at org.netbeans.modules.visualweb.insync.live.LiveUnit.resurrect(LiveUni t.java:407)
Created attachment 46700 [details] insync error
Created attachment 46701 [details] project
I can reproduce now using the 0815 build Thanks Lark! But, the exception appears to not be in database. I maintained binding until the source is entered in the Java editor. See stack traces attached by Lark Deva checked and will look into
Inserting code is not the issue here, even if you update something in java file and come back to the designer, you should see the problem. It can be easily reproduced with the attached project if you do the following 1) Open the attached project by lark 2) Right click on table component, select Bind to Data, in the dialog select a different dataprovider (personDataProvider) 3) Go to java source, modify something 4) Click on the designer tab and you will see the error Debugging revealed that it is introduced because of fix for #112688 When you perform step 2, a dataprovider listener is added as per the following call stack com.sun.data.provider.impl.AbstractDataProvider.addDataListener(AbstractDataProvider.java:370) com.sun.webui.jsf.component.TableRowGroupDesignInfo.propertyChanged(TableRowGroupDesignInfo.java:217) org.netbeans.modules.visualweb.insync.live.LiveUnit.firePropertyChanged(LiveUnit.java:1937) org.netbeans.modules.visualweb.insync.live.SourceDesignBean.fireDesignPropertyChanged(SourceDesignBean.java:459) org.netbeans.modules.visualweb.insync.live.BeansDesignProperty.setValue(BeansDesignProperty.java:375) org.netbeans.modules.visualweb.insync.live.FacesDesignProperty.setValue(FacesDesignProperty.java:215) com.sun.webui.jsf.component.table.TableRowGroupDesignState.setPropertyValue(TableRowGroupDesignState.java:470) com.sun.webui.jsf.component.table.TableRowGroupDesignState.saveState(TableRowGroupDesignState.java:576) com.sun.webui.jsf.component.table.TableDesignState.saveState(TableDesignState.java:400) com.sun.webui.jsf.component.TableDesignInfo.linkBeans(TableDesignInfo.java:183) when you do step 4, the added listener tries to delete the code as per the following call stack org.netbeans.modules.visualweb.insync.live.LiveUnit.deleteBean(LiveUnit.java:1139) com.sun.webui.jsf.component.table.TableRowGroupDesignState.setDataProviderBean(TableRowGroupDesignState.java:194) com.sun.webui.jsf.component.TableRowGroupDesignInfo$ProviderListener.providerChanged(TableRowGroupDesignInfo.java:281) com.sun.data.provider.impl.AbstractDataProvider.fireProviderChanged(AbstractDataProvider.java:432) com.sun.data.provider.impl.CachedRowSetDataProvider.setCachedRowSet(CachedRowSetDataProvider.java:216) com.sun.data.provider.impl.CachedRowSetDataProvider.close(CachedRowSetDataProvider.java:228) sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:597) org.netbeans.modules.visualweb.insync.live.BeansDesignBean.invokeCleanupMethod(BeansDesignBean.java:81) org.netbeans.modules.visualweb.insync.live.LiveUnit.resurrect(LiveUnit.java:411) org.netbeans.modules.visualweb.insync.live.LiveUnit.sync(LiveUnit.java:321) Assigning this to matt to revisit his fix for #112688
In a strange way, it appears the behavior observed is by design. To "clean up," insync calls CachedRowSetDataProvider.close, which calls setCachedRowSet(null). The design info code I've added reacts to this by reassessing what the table columns should be, and ultimately "decides" to hook up the default data provider, since there are no field keys in the CachedRowSetDataProvider. Why does insync clean up in this way?
Insync is just responding to deleteBean call from designtime. Insync doesn't decide when to add/delete code, it just provides a mechanism to add/delete as required by designtime
sandipchitale has requested I search for the uses of the CLEANUP_METHOD mechanism, to see if insync can perhaps forego invocation of the "cleanup method." I searched for the text "CLEANUP_METHOD" in the bean infos in dataprovider, woodstock, and jsfsupport. I found no occurrences other than the one in CachedRowSetDataProviderBeanInfo. Is there any other place we need to search? Passing to sandipchitale.
Keyword "REGRESSION" was added.
Currently Insync calls the "CLEANUP_METHOD" method as specified by a value in BeanInfo/DesignInfo in addition to the DesignInfo.beanDeletedCleanup(). The "CLEANUP_METHOD" mechanism is meant for code generation. The generated code is executes at runtime when the lifecycle beans such as Page, Request, Session, Application are destroyed. The "CLEANUP_METHOD" is not meant to be called at designtime. Insync will not call "CLEANUP_METHOD" method at design time. The DesignInfo of components should take care of the cleanup in the DesignInfo.beanDeletedCleanup() callback.
Actually it turns out that the CLEANUP_METHOD is expected to be called at designtime also. Therefore approach mentioned in the previous comment has been shelved. We are working on a potential fix in CachedRowSetDataProvider which does different thing based on Bean.isDesignTime(). We are currently testing for memory leaks that this may introduce.
It has been decided to implement the fix based on Beans.isDesignTime(). Matt will implement that fix after making sure that the fix (itself) does not introduce a memory leak. Matt should verify that.
Slight change in plans. Because this issue is pressing, it has been agreed that I will integrate the isDesignTime fix now and file a separate issue to investigate any related memory leak.
I have filed issue 113555 regarding memory leakage.
I have integrated the fix based on isDesignTime: Checking in dataprovider/runtime/library/src/com/sun/data/provider/impl/CachedRo wSetDataProvider.java; /cvs/visualweb/dataprovider/runtime/library/src/com/sun/data/provider/impl/Cache dRowSetDataProvider.java,v <-- CachedRowSetDataProvider.java new revision: 1.5; previous revision: 1.4 done
Verified, not reproduced on: Product Version: NetBeans IDE Dev (Build 200708270000) Java: 1.6.0_02; Java HotSpot(TM) Client VM 1.6.0_02-b06 System: Windows XP version 5.1 running on x86