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.
Motivation: In some cases it is necessary to obtain info about the location of a persisted setting during reading or writing operations. Use case: To properly resolve urls peristed in setting that are shared via vcs. It is necessary to find out a proper reference resolver (e.g. project's one) and the file location can be the only way. Solution: I would propose to add 2 methods to Convertor class (http://www.netbeans.org/download/dev/javadoc/SettingsAPIs/org/netbeans/spi/settings/Con vertor.html): public Object read (java.io.Reader r, Lookup env) throws IOException, ClassNotFoundException public void write (java.io.Writer w, Object inst, Lookup env) throws IOException The settings framework would provide setting's FileObject via env. These methods would delegate to current read/write as default impl. Why Lookup: an api client should not be encourage or tempted to use the passed FileObject for storing/reading instead of Writer/Reader passed by the framework. Issues: What should be provided when a new .settings file is created. Now the InstanceDataObject writes a content to a memory buffer firstly to check the write operation is successful and to prevent early access to incomplete .settings file.
I have problems with adding the Lookup to the method signature. I do not like such style, also it duplicates the amount of methods in the class. Also I know that you plan to introduce DOMConvertor with additional methods and those would be duplicated too. So instead of that I suggest a protected static method for that: static Lookup findContext (); or with one argument static Lookup findContext (Reader); static Lookup findContext (Writer); these methods could be called from the read/write methods of Convertors and returned the associated context (or Lookup.EMPTY). Question is how to find the right lookup when in read/write method. For case of Reader/Writer it should be easy, the both could implement Lookup.Provider interface (yet to be done, but planned). For the non-argument method, there would have to be a method static void executeInContext (Runnable, Lookup); If the findContext (Reader/Writer) seems acceptable please add dependency to issue 26275
I like this way to prevent duplication of methods. findContext(Reader/Writer) - seems acceptable to me. Due to proposed DOMConvertor there should be also findContext(Element/Document). It is 4 static methods findContext. It is pretty much. So I tend to introduce just findContext(Object) or findContext(). But findContext(Object) seems to be too confusing.
target milestone -> 4.0
Any progress on this issue? There is more and more code in projects which deserves new convertors framework, but without having this resolved we can't use it. (e.g. iussue #26436, issue #23289)
Yes, we agreed offline on introducing protected static Lookup Convertor.findContext(Reader) protected static Lookup Convertor.findContext(Writer) protected static Lookup DOMConvertor.findContext(Document) protected static Lookup DOMConvertor.findContext(Element) and Lookup.Provider interface (issue #26275). So I am going to implement it ASAP.
protected static Lookup DOMConvertor.findContext(Element) was skipped. It is replacable with DOMConvertor.findContext(element.getOwnerDocument()) Implemented in: /cvs/core/settings/src/org/netbeans/spi/settings/Convertor.java new revision: 1.3; previous revision: 1.2 /cvs/core/settings/src/org/netbeans/spi/settings/DOMConvertor.java new revision: 1.3; previous revision: 1.2 /cvs/core/settings/src/org/netbeans/modules/settings/ContextProvider.j ava initial revision: 1.1 /cvs/core/settings/src/org/netbeans/modules/settings/InstanceProvider. java new revision: 1.4; previous revision: 1.3 /cvs/core/settings/src/org/netbeans/modules/settings/SaveSupport.java new revision: 1.6; previous revision: 1.5 /cvs/openide/src/org/openide/loaders/InstanceDataObject.java new revision: 1.131; previous revision: 1.130 /cvs/core/settings/manifest.mf new revision: 1.4; previous revision: 1.3 /cvs/core/settings/api/doc/changes/apichanges.xml new revision: 1.2; previous revision: 1.1
verified