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.
Created attachment 95656 [details] Thread dump I created a web project and then went throigh the Make Sharable wizard by specifying the Libraries folder, and ran into this deadlock.
Likely caused by fix of issue 180468. Code is not easy to follow - I've started refactoring it. There seems to be too much listening on file changes and current synchronization is redundant as well.
The initial refactoring I've started ended up with almost complete rewrite of two classes involved - ModelUnit and JsfModelImpl. I tested it on in several scenarios including one from issue 180468 and everything seems to be working according to JSF spec. Code is more readable, perform better and couple of corner cases are handled correctly compared to previous version. One thing I wonder Marek is that JsfModel has property change listening support but (and I might be wrong) I did not find anybody listening on the changes. Maybe it is not necessary to listen on changes in JsfModel and instead always ask for current value as needed? On the other hand if I start IDE and start code completion for in EL while IDE is still starting up then I'm given "No Suggestions" instead of "Please Wait". 426a58799988
> One thing I wonder Marek is that JsfModel has property change listening support > but (and I might be wrong) I did not find anybody listening on the changes. > Maybe it is not necessary to listen on changes in JsfModel and instead always > ask for current value as needed? On the other hand if I start IDE and start > code completion for in EL while IDE is still starting up then I'm given "No > Suggestions" instead of "Please Wait". > > 426a58799988 I'm not caching the data from JsfModel in any way so I do not think I should use the listeners. The completion always calls MetadataModel.runReadAction() and call getElements() inside. The bahaviour I would expect is that <T extends JsfModelElement> List<T> getElements( Class<T> clazz) is blocking if there model is not initialized yet and/or the scanning is in progress. Possibly it could be fixed by adding the "wait classpath scan finished" before the model access. The listeners would probably make sense if there was some kind of higher level model build on top of the JsfModel which would require to be synced, something like a visual editor which incorporates the metamodel data. Ads would know more.
OTOH I didn't check how fast/slow is the getElements() itself. If the model doesn't cache the data itself and always do the analysis it would be worth of caching the metadata for example in the JSFBeanCache (which doesn't cache anything right now) and flush the cache upon the model's property change.
Fixing failing unit tests (some code was wrong and some tests needed to be fixed): 0316c07a890b 6f4b3c4a45a6