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.
1) Create an EJB module project 2) Create a set of EJBs from DB 3) Quit the IDE and restart 4) Delete one of the beans from the logical view (right click on the node under Enterprise JavaBeans node and choose delete) 5) Open the sun customizer, notice that there is no node for that ejb 6) Close the customizer and examine sun-ejb-jar.xml and sun-cmp-mappings.xml files and notice that the deleted bean is still there 7) Close the xml editor(s) and reopen the gui customizer. Make a change to a field (like mapping properties on a cmp bean) so that save all is enabled and force a save. Notice that timestamp of the sun-* files have not changed and therefore still contain the old deleted bean and no new value for the edit done in 7.
I made this a P2 because it is causing problems in my fix for issue 54867.
if an IDE save action does not result in a file save on disk with a new timesstamp, this is of course very serious.... Another wierd behaviour related to jsr88 node, files, and dataobject management in j2eeserver land? We need to spend the time to understand this. This is blocking other bugs to be fixed.
The cause of this issue is following: After the ide is restarted, the data objects for sun-ejb-jar.xml and sun-cmp-mappings.xml are not created yet, so that these server specific files do not listen to changes in the ejb-jar.xml. When an ejb is removed from the logical view, it is removed also from the ejb-jar.xml. If you then open the sun customizer you won't see the deleted beans because the model in the memory is build based upon the current DD model. The j2eeserver, however, doesn't know and without appserver's help can't know that the memory model and what is stored on the disc is not consistent. After you make any change, like mentioned in step 7, the document is mark as dirty and the save action will be enabled. Appserver should therefor check this and either save it by itself or tell the j2eeserver that the given DConfigBean has been removed so that the j2eeserver could mark the files as dirty.
Reassign this to appserver
Vince, we need to make progress on this one... Thanks for your evaluation time.
I found a quick and dirty fix for some of this issue.... I noticed that the project open hook did not have an call to ConfigSupport's ensureConfigurationReady(). I added this call to the open hook and the delete operation gets forwarded now. The save-all button lights up when the bean is removed in step 4. I think that the change is making the round-trip. It would be nice if the change actually got written to the sun-ejb-jar.xml file automatically. Right now, the file is just marked as dirty... I think this is covered by another issue, though. It is dirty because it can become expensive for projects that may never need to have the configuration readied. Does anybody know a place where this call might be "better"?
From Stepan evaluation, I think adding ensureConfigurationReady in project open hook is the exact fix, not just a dirty trick. It is a must that configuration should be ready to react to any DD changes as soon as the DD graph is created. Note that Web project did not have to call ensureCongigurationReady because it already call get/setWebContextRoot. We need to also make sure earproject also have ensureConfigurationReady in its open hook.
have fix for this particular use-case. Doing a check to find other un-ensured DD manipulations.
ejbjarproject/.../EjbViewController.java (1.6)
verified