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 201212080001) Operating System = Windows 7 version 6.1 running on amd64 Java; VM; Vendor = 1.7.0_09 Runtime = Java HotSpot(TM) 64-Bit Server VM 23.5-b02 When developer apply refactoring in package name for persistent beans, is expected that package names are also renamed in persistence.xml, which does not happen.
can't reproduce, tried to rename a package with an entity and got package updated. please provide: - project type - how and where entities and persistence.xml are created - how package is renamed please reopen
Better than that, I've created a screencast showing from start to end the creation of the project to the package rename to the wrong persistence.xml at end. I hope this helps. Check video here: http://screenr.com/5BM7 Regards, Edson
thanks, will try tomorrow,may be it's in case of multidot package with rename for only last part of the package. but it's unclear why you ave only last part when I have full package specification in refactor->rename.
either something may be broken in 20121208 or something important may be missed. I don't have this behavior neither with 20121203 nor with 20121211 (I mean incomplete package name in refactor dialog).
(In reply to comment #4) > either something may be broken in 20121208 or something important may be > missed. > I don't have this behavior neither with 20121203 nor with 20121211 (I mean > incomplete package name in refactor dialog). This behavior happens since first beta. I'll download latest dev build and try again. Edson
Ok, I got it: On latest build, after "replaying" the "new project" sequence several times, I'm able to reproduce the problem consistently. How the bug is hit: after import Entities, apply Refactor -> Rename (without doing anything else, just like I did in my video). How it works: before doing Refactor -> Rename, open the persistence.xml file at least once. This is the magick. So the point is, if the user open persistence.xml file at least once, he/she will never hit this bug. Regards, Edson
can you rename your br.net.mytest.beans into x.y.z? even you got it as related with persistence.xml, refactoring may be related issue also.
I've provided another video showing that if you don't open the persistence.xml (or at least, click on it to show in Navigator panel) for the first time, then refactor -> rename fails. See the video at: http://screenr.com/GhM7 To show that refactor fails, I've opened the persistence.xml file with external text editor. I've noticed also that when project is configured for "copy static resource on save" will not copy persistence.xml after refactor (maybe another issue).
(In reply to comment #7) > can you rename your br.net.mytest.beans into x.y.z? even you got it as related > with persistence.xml, refactoring may be related issue also. Refactor -> Rename does not offer option for full package rename, only last bit of the package name. Would be because I'm using "Reduced tree" view?
may be, how to switch-use "reduced tree"?
ok, thanks, already found. as it's not a bug, it's unrelated with persistence refactoring issue.
(In reply to comment #11) > ok, thanks, already found. as it's not a bug, it's unrelated with persistence > refactoring issue. Ok, I was about to point the New and Notewhorty page: http://wiki.netbeans.org/NetBeans_72_NewAndNoteworthy#Package_View Based on my last video, do you has been able to reproduce the bug, or you need more information? Please let me know. Thanks, Edson
yes, I'm able to reproduce with web project even with 1 entity now, it's not reproducible in j2se project. in case if there are a lot of entities it may case more side effects also.
Still under investigation. For workaorund it may not be necessary to open persistence.xml, got almost correct refactoring after expanding Configuration Files node. not a stopper with these workarounds and this use-case, but may be good to fix in next patch.
Created attachment 130259 [details] from DataObject.find to DataLoaderPool..findDataObject This one fix the issue, may it mean an issue in DataObject.find ?
Jaroslav, Can you look into proposed patch, main question if it's an issue in DataObject.find if this patch is required? It seems DataObject.find do not register newly created dataobject properly and it cause me to work with different dataobjects later and cause the issue with persistence.xml refactoring.
You seem to skip following code from DataObject.find: if (!fo.isValid()) throw new FileStateInvalidException(fo.toString()); // try to scan directly the pool (holds only primary files) DataObject obj = DataObjectPool.getPOOL().find (fo); if (obj != null) { return obj; } So either your fileobject is not valid or wrong(?) data object is found in the pool. But in the later case one should not be allowed to create instance of another DataObject anyway...
found my patch do not work now either I miss something and it wasn't a fix at all. or something is different in javaee7 branch and default branch.
Tried to follow attached video today, looks like some changes in core fix the issue. What steps are done: swith to reduced tree creae web project on tomcat create complex package create entitied from sample db refactor the package name check persistence.xml from filesystem or from withing ide - cotain correct package name. please reopen if you'll get this behaviour in 8.0.1