Bug 40739 - OutputStream FileObject.createAndOpen(String nameWithExt)
OutputStream FileObject.createAndOpen(String nameWithExt)
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Filesystems
3.x
All All
: P2 (vote)
: 7.0
Assigned To: Jaroslav Tulach
issues@platform
: API, API_REVIEW_FAST, THREAD
Depends on: 40738
Blocks:
  Show dependency treegraph
 
Reported: 2004-03-03 19:28 UTC by Jaroslav Tulach
Modified: 2010-09-11 03:37 UTC (History)
4 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
FileObject.createAndOpen and impl and test (8.87 KB, patch)
2010-09-03 14:25 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2004-03-03 19:28:39 UTC
In order to fully exploit the benefits of mutual
stream exclussion when issue 40738 is implemented
there is a need for another small improvement. The
issue 40738 solves problems with reading improper
content of a file when it is being written, but
there is often a chance that one could read a file
before it is being written to. Right now one can
create new data file:

FileObject fo = FileUtil.createData (...);

and only then can lock the file and obtain the
output stream:

fo.getOutputStream (fo.getLock ());

during this time another object can grab the
stream and try to read from this, not yet
initialize file. In order to solve this an API
extension is proposed:

final class FileUtil.OpenedHandle {
  public final FileObject file;
  public final FileLock lock;
  public final OutputStream os;
}

OpenedHandle FileUtil.createOpenedData (...);

that would create a data file, locked it and
returned an output stream to write to it. The file
created event should probably be fired only after
the stream is closed. If clients used this method,
they could safely assume that no other part of
infrastructure is reading their files prior they
are fully finished.
Comment 1 Jesse Glick 2004-03-08 12:08:42 UTC
BTW suggest that FileUtil be reserved for convenience methods and that
the proposed class be put elsewhere.

Seems like this and issue #40738 are just special cases of the need
for a proper threading model (and lock system) for Filesystems. IMHO
we could probably just synchronize all Filesystems methods on a single
lock and get reasonable performance and a much simpler API and impl,
for example.
Comment 2 _ ttran 2004-07-11 20:39:51 UTC
-> future, not for D of course
Comment 3 Antonin Nebuzelsky 2008-04-15 17:13:29 UTC
Reassigning to new module owner jskrivanek.
Comment 4 Jaroslav Tulach 2010-04-27 15:47:24 UTC
If this shall be implemented then I suggest:

FileUtil.createAndOpen(..., AtomicReference<FileObject> file, AtomicReference<FileLock> lock, AtomicReference<OutputStream> os);

but unless really needed, there is no big reason to implement this method nobody is going to use in near future.
Comment 5 Jesse Glick 2010-04-27 19:07:20 UTC
A simpler signature would be something like

public final OutputStream [FileObject.]createAndOpen(String child);

e.g.

Document doc = ...;
FileObject folder = ...;
OutputStream os = folder.createAndOpen("newfile.xml");
try {
  XMLUtil.write(doc, os, "UTF-8");
} finally {
  os.close();
}

This would be used quite widely, I think. Currently you have to not only create the new FileObject as a separate step, but also wrap the whole block in an AtomicAction, which is rather clumsy. This pattern (sometimes forgetting the AtomicAction) is repeated many times throughout project system code.
Comment 6 Jaroslav Tulach 2010-04-28 07:48:59 UTC
Sounds much better.
Comment 7 Jesse Glick 2010-04-28 18:58:29 UTC
Is there an easy way to ensure that the FileCreatedEvent is fired only after OutputStream.close() is called? Wrapping the body of createAndOpen in an AtomicAction of course will not suffice, since the stream is closed after this method returns. And just suppressing the FileCreatedEvent (permitting the FileModifiedEvent to be fired upon stream close) is not good since some listeners may be checking only for FCE. I suppose you could suppress the FCE during the body of the method, and then also set some internal flag so that stream close fires FCE rather than FME?
Comment 8 Jaroslav Tulach 2010-05-03 10:06:12 UTC
As soon as the getOutputStream is opened, nobody else is allowed to read file's content. So even if I do not manage to delay the FileCreated event, nobody shall have a chance get access to unfinished data.

I'll do this for next release.
Comment 9 Jaroslav Tulach 2010-09-03 14:25:24 UTC
Created attachment 101855 [details]
FileObject.createAndOpen and impl and test
Comment 10 Jaroslav Tulach 2010-09-09 08:47:13 UTC
I'll integrate tomorrow.
Comment 11 Jaroslav Tulach 2010-09-10 05:45:28 UTC
core-main#c04673028299
Comment 12 Quality Engineering 2010-09-11 03:37:47 UTC
Integrated into 'main-golden', will be available in build *201009110000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/c04673028299
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #40739: FileObject.createAndOpen


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo