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 207463 - getInputStream in AWT from maven.model.pom.POMModelFactory.getModel(POMModelFactory.java:79)
Summary: getInputStream in AWT from maven.model.pom.POMModelFactory.getModel(POMModelF...
Status: RESOLVED FIXED
Alias: None
Product: projects
Classification: Unclassified
Component: Maven (show other bugs)
Version: 7.2
Hardware: All All
: P3 normal (vote)
Assignee: Milos Kleint
URL:
Keywords: PERFORMANCE
: 192478 (view as bug list)
Depends on:
Blocks: 206311
  Show dependency tree
 
Reported: 2012-01-18 15:22 UTC by Petr Cyhelsky
Modified: 2012-03-26 23:06 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 184535


Attachments
stacktrace (5.40 KB, text/plain)
2012-01-18 15:22 UTC, Petr Cyhelsky
Details
patch with reworked api for customizer pom editing (171.57 KB, patch)
2012-03-05 10:28 UTC, Milos Kleint
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Cyhelsky 2012-01-18 15:22:17 UTC
Build: NetBeans IDE Dev (Build 20120118-ab16ccd545a5)
VM: OpenJDK 64-Bit Server VM, 20.0-b11, OpenJDK Runtime Environment, 1.6.0_22-b22
OS: Linux

User Comments:
cyhelsky: on go to type




Stacktrace: 
java.lang.IllegalStateException: getInputStream invoked in AWT
   at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FileObj.getInputStream(FileObj.java:219)
   at org.openide.filesystems.MIMESupport$CachedFileObject.getInputStream(MIMESupport.java:402)
   at org.netbeans.modules.openide.filesystems.declmime.DefaultParser.parse(DefaultParser.java:134)
   at org.netbeans.modules.openide.filesystems.declmime.XMLMIMEComponent$SniffingParser.sniff(XMLMIMEComponent.java:266)
   at org.netbeans.modules.openide.filesystems.declmime.XMLMIMEComponent.acceptFileObject(XMLMIMEComponent.java:83)
   at org.netbeans.modules.openide.filesystems.declmime.MIMEResolverImpl$FileElement.resolve(MIMEResolverImpl.java:690)
Comment 1 Petr Cyhelsky 2012-01-18 15:22:20 UTC
Created attachment 115028 [details]
stacktrace
Comment 2 Jaroslav Tulach 2012-01-26 07:15:23 UTC
The first method that can avoid the I/O is 
org.netbeans.modules.maven.model.pom.POMModelFactory.getModel(POMModelFactory.java:79)
in my opinion.
Comment 3 Milos Kleint 2012-02-06 13:11:14 UTC
Jesse, reading your comment in http://netbeans.org/bugzilla/show_bug.cgi?id=192051#c5 I'm wondering the there is a XAM requirement to start the transaction on AWT thread or can be any thread. Can such off-AWT transaction be modified in AWT thread?

I'm tempted to move all XAM stuff to off-AWT and call all base AWT invokations with invokeAndWait()
Comment 4 Milos Kleint 2012-02-07 07:16:56 UTC
ideally one would rewrite the entire customizer code so that instead of directly modifying the model, one would create just commands that will be triggered only at the end. However one looses the capability of panels to react to other panel changes, like a panel enabling a given technology could be modifying the source level as well.
Comment 5 Jesse Glick 2012-02-14 17:42:25 UTC
(In reply to comment #3)
> is [there] a XAM requirement to start the transaction on AWT thread
> or can be any thread - Can such off-AWT transaction be modified in AWT thread?

I am really not sure, just be very careful with this code as it is easy to introduce regressions. Perhaps XAM itself needs to be patched, since it seems to track the thread that starts a transaction.
Comment 6 Milos Kleint 2012-03-05 10:28:00 UTC
Created attachment 116344 [details]
patch with reworked api for customizer pom editing

attached a patch that reworks how pom files are edited within the customizer. instead of one looong XAM transaction that spans across the visibility of the customizer and gets the model modified immediately, we now collect just ModelOperation instances that get saved only at the end of the customizer.
Comment 7 Milos Kleint 2012-03-05 10:42:11 UTC
Notable changes: 
1. introduced non-compatible ModelHandle2 API class that supersedes the old ModelHandle one. While the old signature is present, it will not work at runtime when someone attempts to modify the now read-only model.
2. org.netbeans.modules.project.uiapi.CustomizerDialog now wraps all store Listeners into a filesystem atomic action next to the existing project write mutex. That way both the main and Category's store listeners are persisted together and no event firing intervenes as it did before, eg. when the maven project started reloading while the web support was still persisting something.


Added people on CC who own modules registered as friend (anyone know the contact for javeleon stuff?)
Please review the patch  and let me know if you were using the ModelHandle api and if so, how. Those who have sources in nb.org main repository should have their sources changed by me, please review that as well.
Comment 9 Quality Engineering 2012-03-20 12:53:04 UTC
Integrated into 'main-golden', will be available in build *201203200400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/3c90e614c5c4
User: Milos Kleint <mkleint@netbeans.org>
Log: #207463 redesign the customizer apis, only collect pom modifying operations during the dialog lifetime, eventually later write them all at once.
Comment 10 Jesse Glick 2012-03-26 23:00:01 UTC
If the old ModelHandle no longer works, better to just delete it.
Comment 11 Jesse Glick 2012-03-26 23:06:36 UTC
*** Bug 192478 has been marked as a duplicate of this bug. ***