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.
If you have own dataObject with resolver based on XMLrules it's not recognised by the file creation but only after next restart of IDE. I debug it for quite a long time and find out that DataObjectPool.register associate given fileObject always with XMLDataObject (in cases by creation the file thru DO.createFromTemplate) and probably no any recognisation aren't done then. It's probably possible to WA that in cases if I you have an InstantiatingIterator for that template but not in cases if some default is used. Finally I found out that there helps when DO.find(FO) is called before createMultiObject(FO) because the file is then probably associated with the proper Loader. You will know more, I wanted just to describe what I find out during the debugging session. BTW, I was able temporarily fix that by adding: MultiDataObject:855 ... DataObject.find(pf); FYI, due to looking into MultiDataObject code I found for similar issue #61600. Steps for reproducing: (with InstantiatingIterator) 1, Create web application 2, create file Spring -> Spring XML Configuration File -> the file is not recognised as SpringXMLConfigDataObject till you will restart the IDE or (w/o InstantiatingIterator) 1, build Coherence module in trunk 2, create project 3, create any coherence DD file in it -> the same behaviour
Why is not the spring configuration template recognized by your loader to begin with?
It is recognized by loader, the loader should be correct. But it's not recognized at the IDE run when the file was created from Spring configuration template by DO.createFromTemplate() method. Then it doesn't come to my loader at all. And why? It looks to me that DataObjectPool.register() caches the fileObject with wrong DataObject when the file is created from XML template by invoking that method.
If the template is recognized by your DataLoader, then MultiDataObject.java:856 calls (indirectly) your loader's findDataObject method. I don't see a reason why this would not work. If you claim the data object for your file object is created sooner, please provide a creation stacktrace.
(In reply to comment #1) > Why is not the spring configuration template recognized by your loader to begin > with? Sorry, I answered wrongly before. I should say that SpringXMLConfigDataLoader is able to recognize Spring configuration files but it's not recognizing properly the template. (In reply to comment #3) > If the template is recognized by your DataLoader, then MultiDataObject.java:856 > calls (indirectly) your loader's findDataObject method. Agree on that. So probably the problem is that for all XML templates looks (I debug that for Spring, JSF templates) to be used XMLDataLoader. BTW, thanks to this investigation I found a WA, but I wouldn't want to do that: DataObject datO = templateDO.createFromTemplate(dataFolder, targetName, params); createdFile[0] = datO.getPrimaryFile(); datO.setValid(false); DataObject.find(createdFile[0]);
Well, you need to recognize the templates. Without that, plain XMLDataObject will be created in createFromTemplate.
Created attachment 112659 [details] unit test Actually it should be recognised based on XML rules for that file. Anyway on your (offline) doupt about freemarker template I tried to rebuild the module with template w/o freemarker tags and the spring configuration file was recognised correctly then. So I changed a little bit the summary. Finally I created the unit test as you wished, so hopefully it could help.
As I mentioned, unit test is done, so probably nothing to do more on my side, reassigning back.
ergonomics#72b7289adc14
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/72b7289adc14 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #203959: It is a joy to fix bugs with such good unit tests! Do everything to parse the XML file.
verified. Product Version: NetBeans IDE Dev (Build 20111124-a2921333b478) Java: 1.6.0_29; Java HotSpot(TM) 64-Bit Server VM 20.4-b02-402 System: Mac OS X version 10.7.2 running on x86_64; MacRoman; en_US (nb) User directory: /Users/tomas/.netbeans/dev Cache directory: /Users/tomas/.netbeans/dev/var/cache