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 190692 - CV test org.netbeans.test.ide.GeneralSanityTest.testNoWrites is failing constantly on Windows.
Summary: CV test org.netbeans.test.ide.GeneralSanityTest.testNoWrites is failing const...
Status: RESOLVED DUPLICATE of bug 187023
Alias: None
Product: javacard
Classification: Unclassified
Component: Java Card (show other bugs)
Version: 7.0
Hardware: PC Windows XP
: P1 normal (vote)
Assignee: _ tboudreau
URL:
Keywords: TEST
Depends on:
Blocks:
 
Reported: 2010-09-30 11:50 UTC by Tomas Danek
Modified: 2010-10-08 14:32 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
log (128.51 KB, application/octet-stream)
2010-09-30 11:50 UTC, Tomas Danek 		Details
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 Tomas Danek 2010-09-30 11:50:50 UTC 
Created attachment 102210 [details]
log

seems to me like javacard is the culprit. 

full log attached.


junit.framework.AssertionFailedError: No writes during startup.
Writing any files to disk during start is inefficient and usualy unnecessary.
Consider using declarative registration in your layer.xml file, or delaying
the initialization of the whole subsystem till it is really used.
In case it is necessary to perform the write, you can modify the
'allowed-file-write.txt' file in ide.kit module. More details at
http://wiki.netbeans.org/FitnessViaWhiteAndBlackList
checkWrite: C:\space\hudson\workspace\CV-multi\label\XP-slave\testdistribution\qa-functional\work\org-netbeans-modules-ide-kit\userdir0\config\Services\Platforms
java.lang.Exception: checkWrite: C:\space\hudson\workspace\CV-multi\label\XP-slave\testdistribution\qa-functional\work\org-netbeans-modules-ide-kit\userdir0\config\Services\Platforms
	at org.netbeans.test.ide.CountingSecurityManager.checkWrite(CountingSecurityManager.java:416)
	at java.io.File.mkdir(File.java:1155)
	at org.openide.filesystems.LocalFileSystem.createRecursiveFolder(LocalFileSystem.java:259)
	at org.openide.filesystems.LocalFileSystem.createFolder(LocalFileSystem.java:221)
	at org.openide.filesystems.LocalFileSystem$Impl.createFolder(LocalFileSystem.java:545)
	at org.openide.filesystems.AbstractFileObject.createFolder(AbstractFileObject.java:415)
	at org.openide.filesystems.FileUtil.createFolder(FileUtil.java:849)
	at org.openide.filesystems.MultiFileObject.createFolder(MultiFileObject.java:1076)
	at org.openide.filesystems.FileUtil.createFolder(FileUtil.java:849)
	at org.openide.filesystems.FileUtil.createData(FileUtil.java:904)
	at org.openide.filesystems.MultiFileObject.createData(MultiFileObject.java:1151)
	at org.netbeans.modules.javacard.ri.platform.installer.RIPlatformFactory.create(RIPlatformFactory.java:230)
	at org.netbeans.modules.javacard.ri.platform.installer.RIPlatformFactory.access$100(RIPlatformFactory.java:89)
	at org.netbeans.modules.javacard.ri.platform.installer.RIPlatformFactory$1.run(RIPlatformFactory.java:197)
	at org.openide.filesystems.EventControl.runAtomicAction(EventControl.java:125)
...
Comment 1 _ tboudreau 2010-09-30 12:45:00 UTC 
This is by design.  Since the RI was not in the standard distro, we did not address this for 6.x.

Basically, the RI adds properties files that contain the fully qualified path to the RI JARs - they need to be used directly from Ant scripts.  There is no way to do this declaratively.

However, registration is delayed until 10 seconds *after* the main window opens.  Not a major issue.
Comment 2 Marian Mirilovic 2010-10-05 12:04:19 UTC 
Yarda, 
could you please help with this test ? Thanks in advance.
Comment 3 _ tboudreau 2010-10-05 15:10:35 UTC 
The approaches I can think of to fixing this would be:

 - Actually provide some general purpose infrastructure for things that need to write into $USERDIR/build.properties and other places after installation.  Anything that needs to write fully qualified paths into the NetBeans install needs this - otherwise projects are not buildable from the command-line).  The only reason we don't have this problem in JavaPlatform is because the default Java platform is available from system properties and a java binary must be on the system path or NetBeans itself wouldn't be running.

 - Find a way to move writing this stuff to the installer (ModuleInstall or something else will still have to check that it is really there, though)

 - Try to register a lazy fake-java-platform that replaces itself the first time something tries to use it (I prototyped this, but something in the Java modules was  aggressively trying to call all installed platforms after startup, so I think it cannot be lazy without some help from the Java infrastructure) - and if you do this, make sure fake classpath info or whatever you need to make it lazy isn't cached by the Java infrastructure and used later or things will break.

What is actually happening is this:
 - RI bundle contains a full install of the Java Card RI
 - Java Card platforms and cards are properties files in the sysfs
 - Those properties files are loaded directly by Java Card project Ant scripts - the customizers for Platforms and Cards simply read and write the data the Ant script uses
 - Java card projects get their entire definition of what card and platform to run on from them
 - The location to look them up in is stored by name in $USERDIR/build.properties - i.e. a Java Card project's ant script is looking for jcplatform.${platform.name}.location (I forget the actual property names) - which is a path on disk to the userdir
Comment 4 Petr Suchomel 2010-10-08 12:05:52 UTC 

*** This bug has been marked as a duplicate of bug 187023 ***
Comment 5 Petr Suchomel 2010-10-08 14:32:43 UTC 
Should be included in M2