Trying to set the "instanceCreate" attribute of a FileObject contained in the System FileSystem to a Method object
results in the System FileSystem writing out the following :
<attr name="instanceCreate" serialvalue=""/>
<!-- public static usda.weru.weps.skeltomanconvertor.conversiontable.Conversion
The expected behavior is that it should write out the attr element as follows:
To test this, all you need to do is create a FileObject in a folder in the system filesystem and attempt to call
and look at the resulting output in the config folder of the user directory.
Upon tracing through the Netbeans source code, my coworker and I believe to have found the location in which to fix
this problem. We believe it can be found at org.openide.filesystems.XMLMapAttr.Attr.distinguishObject(Object o)
(XMLMapAttr.java:524). The distinguishObject(...) method is checking for all other supported Object types except for
Created attachment 52194 [details]
**Untested** Patch to fix the problem **Untested**
I have added an untested patch which should fix the problem. I must stress that it is an untested patch though. If
nothing else, it will serve to direct people to the location we believe the problem to reside.
RFE, thanks for a patch
Reassigning to new module owner jskrivanek.
Strictly speaking, calling setAttribute(name, java.lang.reflect.Method m) is not correct because the value of
getAttribute is the result of the method call, not the Method itself. However we have introduced some meta-attribute
conventions, e.g. "class:" before an attribute name is interpreted as returning the impl j.l.Class rather than the
actual object; perhaps we could do more, so that setAttribute("methodvalue:" + name, Method) would work.
apisupport.project does something similar for the virtual FileSystem it uses to represent an XML source layer, so that
it is possible to read and write the form of a FileObject attribute rather than its evaluated content.
I like the idea. However rather than providing untested patch, can you provide a unit test? The proper file would be
while I am waiting for the patch, I change the state to won'tfix. Reopen when your patch is ready.
Implementing something like this is useful prerequisite for fixing bug 20169.
Created attachment 98195 [details]
raw: & methodvalue: attributes
Did you mean to link to bug #131951 in apichanges.xml?
I don't think I follow the patch. Why are there both raw: and methodvalue: prefixes?
To copy all attributes safely you would also need to handle newvalue (i.e. Class or Constructor) - or does this work already?
Created attachment 103295 [details]
methodvalue: and newvalue: prefixes supported
Here is new patch that supports newvalue as well.
Re. "raw" I need some API between FileUtil and BinaryFS to ask for raw attribute (e.g. Method or Class). I've documented the API as private.
If there are no objections, I'd like to integrate tomorrow.
[JG01] Rather than putting a long explanation into apichanges.xml (and arch.xml), document the new feature properly in FileObject.setAttribute (and getAttribute, if its behavior is also changed - looks like it is not).
Integrated into 'main-golden', will be available in build *201011260001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jaroslav Tulach <email@example.com>
Log: #120724: methodvalue: and newvalue: prefixes for FileObject.setAttribute