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.

Bug 120724 - FileObject.setAttribute(<String>, <Method>) fails
Summary: FileObject.setAttribute(<String>, <Method>) fails
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Filesystems (show other bugs)
Version: 6.x
Hardware: All All
: P1 blocker (vote)
Assignee: Jaroslav Tulach
URL:
Keywords: API, API_REVIEW_FAST
Depends on: 196608
Blocks: 20169
  Show dependency tree
 
Reported: 2007-10-31 21:11 UTC by kaithos
Modified: 2011-03-11 21:10 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
**Untested** Patch to fix the problem **Untested** (632 bytes, patch)
2007-10-31 21:47 UTC, kaithos
Details | Diff
raw: & methodvalue: attributes (15.17 KB, patch)
2010-04-28 10:44 UTC, Jaroslav Tulach
Details | Diff
methodvalue: and newvalue: prefixes supported (19.67 KB, patch)
2010-11-24 15:38 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description kaithos 2007-10-31 21:11:17 UTC
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 
usda.weru.weps.skeltomanconvertor.conversiontable.Conversion.createConversion(java.util.Map) -->

The expected behavior is that it should write out the attr element as follows:

<attr name="instanceCreate" 
methodvalue="usda.weru.weps.skeltomanconvertor.conversiontable.Conversion.createConversion"/>

To test this, all you need to do is create a FileObject in a folder in the system filesystem and attempt to call 

fo.setAttribute("instanceCreate", <Method>);

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 
Method Objects.
Comment 1 kaithos 2007-10-31 21:47:16 UTC
Created attachment 52194 [details]
**Untested** Patch to fix the problem **Untested**
Comment 2 kaithos 2007-10-31 21:49:00 UTC
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.
Comment 3 rmatous 2007-11-01 09:12:05 UTC
RFE, thanks for a patch
Comment 4 Antonin Nebuzelsky 2008-04-15 17:17:15 UTC
Reassigning to new module owner jskrivanek.
Comment 5 Jesse Glick 2009-03-10 22:12:00 UTC
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.
Comment 6 Jaroslav Tulach 2010-04-17 05:45:09 UTC
I like the idea. However rather than providing untested patch, can you provide a unit test? The proper file would be 

http://hg.netbeans.org/core-main/file/6d0fbf3731c2/openide.filesystems/test/unit/src/org/openide/filesystems/AttributesTestHidden.java

while I am waiting for the patch, I change the state to won'tfix. Reopen when your patch is ready.
Comment 7 Jaroslav Tulach 2010-04-28 10:40:24 UTC
Implementing something like this is useful prerequisite for fixing bug 20169.
Comment 8 Jaroslav Tulach 2010-04-28 10:44:01 UTC
Created attachment 98195 [details]
raw: & methodvalue: attributes
Comment 9 Jesse Glick 2010-04-28 19:10:12 UTC
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?
Comment 10 Jaroslav Tulach 2010-11-24 15:38:10 UTC
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.
Comment 11 Jesse Glick 2010-11-24 16:24:38 UTC
[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).
Comment 12 Jaroslav Tulach 2010-11-25 08:57:11 UTC
core-main#bfaef9e6fa46
Comment 13 Quality Engineering 2010-11-26 06:12:33 UTC
Integrated into 'main-golden', will be available in build *201011260001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/bfaef9e6fa46
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #120724: methodvalue: and newvalue: prefixes for FileObject.setAttribute