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 26076

Summary: [api] Provide location context to convertors
Product: platform Reporter: Jan Pokorsky <jpokorsky>
Component: -- Other --Assignee: Jan Pokorsky <jpokorsky>
Severity: blocker CC: jtulach, rmatous, sdedic, vstejskal
Priority: P1 Keywords: API
Version: 3.x   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Exception Reporter:
Bug Depends on: 26275    
Bug Blocks: 23289    

Description Jan Pokorsky 2002-07-29 11:23:34 UTC
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.

I would propose to add 2 methods to Convertor class 

public Object read ( r, Lookup env) throws IOException, ClassNotFoundException
public void write ( 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.

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.
Comment 1 Jaroslav Tulach 2002-08-05 09:29:09 UTC
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
Comment 2 Jan Pokorsky 2002-08-05 10:47:28 UTC
I like this way to prevent duplication of methods.

findContext(Reader/Writer) - seems acceptable to me.
Due to proposed DOMConvertor there should be also 

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.
Comment 3 Jan Pokorsky 2002-08-05 13:58:43 UTC
target milestone -> 4.0
Comment 4 Vitezslav Stejskal 2002-08-15 12:09:27 UTC
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)
Comment 5 Jan Pokorsky 2002-08-20 15:27:32 UTC
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.
Comment 6 Jan Pokorsky 2002-09-03 19:53:11 UTC
protected static Lookup DOMConvertor.findContext(Element)
was skipped. It is replacable with

Implemented in:

new revision: 1.3; previous revision: 1.2

new revision: 1.3; previous revision: 1.2

initial revision: 1.1

new revision: 1.4; previous revision: 1.3

new revision: 1.6; previous revision: 1.5

new revision: 1.131; previous revision: 1.130

new revision: 1.4; previous revision: 1.3

new revision: 1.2; previous revision: 1.1
Comment 7 Jan Pokorsky 2003-07-15 14:39:42 UTC