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.
The FileUtil.copyAttribute uses simple and straight forward approach to copy attributes of one file object to another. It asks for the value of the attribute (the attribute is deserialized) and then saves it to the new object (the attribute is serialized). This causes problems if the classes of the attributes are not available and also deletes ignores attributes of .nbattrs & xmlfs (newvalue and methodvalue). As part of work on issue 20168 I have improved the behaviour to just copy the attributes as XML file. See http://www.netbeans.org/issues/showattachment.cgi?attach_id=4573 Please implement the behaviour into main trunk.
There is no API. To implement it means in other words to hack it.Moreover there are complications with decorated attribute names that are compound from full path and attribute name for MultiFileObject that doesn`t have on writable layer appropriate FileObject. Moreover I think that original need for this enhancement is much weeker because cache is relaized completely without XMLFileSystem. I tried to implement it but code was gradually uglier and probably error prone. So changed to RFE, priority 5, MileStone 4.0.
Increasing priority of this enhancement to P2 (it is tempting to change it to defect). It is serious problem for new projects where XML filesystems are often merged. Please fix if you can ASAP. Thanx!
I hope that you have read my previous contribution. You must be aware that there is no definition about attributes at all. Attributes means value - some Object, that`s all. There is specific impl. for XMLFileSystem defined in dtd, but it is valid only for XMLFileSystem. This RFE is a little misleading at all. This RFE is basically RFH (request for hack), but I`m ready to do it. So, FileObjects that are implemented in package filesystems can accept copiing of definition as impl. detail. But I think that changing this RFH to DEFECT would be unacceptable.
Reassigning to new module owner jskrivanek.
This is really a DEFECT which makes the impl of copying in favorites.templates.TemplatesPanel not be able to work reliably. An attempt was made to fix this in #7893ff771dee, mistakenly attributed to issue #140308 (I don't know what the real issue number was but it was open and commented on recently), but that attempt will not work - it handles newvalue but not methodvalue. The only thing I can think of that could work is for XMLMapAttr to keep a (weak) cache of Object's it has created using newvalue and methodvalue, so that if you try to write them back to disk in some other attribute they will be stored correctly. But even that would probably not work, since the original reading will likely be done by BinaryFS whereas XMLMapAttr would do the writing - i.e. the cache would need to be shared between openide.filesystems and core.startup.
Long time open enhancements without patches don't deserve to be left open.
Copying templates really is broken. Examples: Action (apisupport) -> display name stored as serialvalue Entity Classes from Database -> <attr name="instantiatingIterator" newvalue="null"/> Java Beans Component: original <attr name="instantiatingIterator" methodvalue="org.netbeans.spi.java.project.support.ui.templates.JavaTemplates.createJavaTemplateIterator"/> -> copy <attr name="instantiatingIterator" newvalue="org.netbeans.modules.java.project.NewJavaFileWizardIterator"/>
Created attachment 96613 [details] Sample project Run module project. Make a j2seproject. File > New > Other > Special File. Should show current time - OK. Tools > Templates > Other > Special File, Duplicate, Rename to Special File #2. File > New > Other > Special File now shows an older time, not current time. Restart, File > New > Other > Special File; now throws an exception, because its content is not a copy of the original layer entry: <fileobject name="special_1"> <attr name="SystemFileSystem.localizingBundle" serialvalue="aced0005737200316f72672e6f70656e6964652e66696c6573797374656d732e4d756c746946696c654f626a65637424566f696456616c7565d9ec9c94d5fd3ca40c0000787077040000000178"/> <attr name="displayName" stringvalue="Special File #2"/> <attr name="instantiatingIterator" newvalue="test20169.SpecialWizardIterator"/> <attr name="template" boolvalue="true"/> <attr name="templateWizardURL" urlvalue="nbresloc:/test20169/special.html"/> </fileobject> Includes unnecessary SystemFileSystem.localizingBundle, and instantiatingIterator is using newvalue (on a class with no no-arg ctor) rather than methodvalue.
Jesse, your example module shows bug in favorites implementation, not in FileUtil.copyAttributes. The templates dialog does its own manual copying: private static void setTemplateAttributes(FileObject fo, HashMap<String, Object> attributes) throws IOException { for (Entry<String, Object> entry : attributes.entrySet()) { // skip localizing bundle for custom templates if (TEMPLATE_LOCALIZING_BUNDLE_ATTRIBUTE.equals (entry.getKey ())) { continue; } fo.setAttribute(entry.getKey(), entry.getValue()); } } Reassigning to favorites module.
TemplatesPanel need to use FileUtil.copyAttributes() instead of manually copying the attributes.
Fixed by changeset: 178963:3405348d2adc http://hg.netbeans.org/main/rev/3405348d2adc
Integrated into 'main-golden', will be available in build *201010080000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/3405348d2adc User: mentlicher@netbeans.org Log: #20169 Use FileUtil.copyAttributes() instead of manually copying the file attributes.