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 32850 - Insufficient handling of custom data for read-only files
Summary: Insufficient handling of custom data for read-only files
Status: RESOLVED WONTFIX
Alias: None
Product: serverplugins
Classification: Unclassified
Component: Infrastructure (show other bugs)
Version: 3.x
Hardware: PC All
: P3 blocker (vote)
Assignee: Pavel Buzek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-04-14 08:16 UTC by Milan Kuchtiak
Modified: 2004-01-12 10:08 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Milan Kuchtiak 2003-04-14 08:16:16 UTC 
There isn't mechanism how to prevent the changes in Custom 
Data properties when the files for writing are read-only.

The setValue() methods (from Custom Data property sheet) 
changes the property and fires the customDataModified() 
method. From that method - there is no way how to veto the 
change.
Comment 1 Nam Nguyen 2003-04-15 22:30:36 UTC 
Probably there will be no need to veto custom data values if they are
presented as read-only (grayed-out) when the underlying files are
non-writable? 

If so, I think we should change this issue description to something to
the effect that j2eeserver should have a way to let server plugin know
(during call to recreate plugin *Item or ConfigBean objects) that the
file underlying the given ConfigInputStream is read-only.  The plugin
should check for this and present the sheet set properly to prevent
users from start editing non-writable data.
Comment 2 Peter Liu 2003-04-15 23:30:44 UTC 
Unfortunately, greying out properties doesn't work because we have no
way to ungrey them if the underlying files become writable. Besides I
think it is a nice convenience feature to allow the user to type
something and be prompted to make the file writable. 
As for vetoing property changes, I agree it is the right way to go. In
fact, there is a way for SchemaToBean to generate beans that have
vetoable properties. We've discussed this before but decided it is too
big and too risky to do for Nevada. Currently, the way we are handling
this is to refresh the DataObject by invalidating it.  I am not all
that happy with this approach  because it blows away the entire
property sheet unnecessarily. But at least, it gets rid of the changes
made by the users.
Comment 3 Milan Kuchtiak 2003-04-16 10:00:03 UTC 
Thank You Peter for explanation how Oakland team handles the read-only
Custom Data.

However I don't think it is a bad idea to prevent custom data from
editing by making properties read-only. The ant module does it and it
is probably using the FileChangeListener.
Comment 4 Petr Jiricka 2004-01-12 09:50:49 UTC 
Pavle and Milane, is this still relevant? It was filed against the
previous version of the API.
Comment 5 Milan Kuchtiak 2004-01-12 10:08:11 UTC 
The mechanism of handling server custom data has been changed.
The issue is not relevant any more.