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.
Please rewrite the mounting of beans to use module layer instead of module.restored code. At least the timerbean should be provided in module layer. See usersguide for example how to do it. I talked with Trung about the problem and he tried to convince me that everything is more complicated than I see, so if you will encounter any problems, let me know, I'll be glad to help. But in general if you place the timerbean into module layer, you can delete GlobalJarFileSystem because it will be global from definition.
Yes, it is more complicated. Mounting the TimerBean.jar is a part of "beans autoloading" process. This way beans can be installed just by putting JAR files to beans directory (out of IDE). An important side effect is that it's ensured that all the JARs in beans directory are mounted. This is done also for beans already installed before - so theoretically we would not have to care about their JARs. Unfortunatelly this was not true so far due to problems with projects and Co., causing various neverending "TimerBean problems". The GlobalJarFileSystem is just another hack to deal with these problems. We used to listen to project opening before... Now (in last builds) this redundant mounting causes the JARs to be mounted again each time the IDE is started, because when autoloading is running, the filesystems are not restored yet, so the autoloading process thinks that the JARs are missing and mounts them. If we can rely on the JAR filesystem presence now and for the future, then we can modify the autoloading. But we still cannot avoid mounting new JARs during autoloading for beans *not* installed yet. (Then we had to cancel the autoloading completely.) This is also the case of the Timer bean during the first start. We can handle the TimerBean JAR using module layer, but then we would have to make some hack to exclude the TimerBean.jar from autoloading. But I hate to make another "TimerBean" hack. The simplest way would be to place the TimerBean.jar somewhere else than in "beans" directory, but where? Anyway, I think that the whole "TimerBean" stuff should be moved to usersguide module. It is just an example of bean, similar to other examples, so why it should be in Form Editor? Usersguide could install the JAR as well as the bean through the module layer. The only problem to solve is where to place the JAR... BTW we still need GlobalJarFileSystem for dynamically installed beans from JARs - unless there was another way how to create "global" filesystems (module layer is of course not usable here)... (Well, you were warned this is a bit more complicated...)
The form module causes significant problems to core trying to add its TimerBean.jar into repository each time the IDE starts. Because the core has to remove it when opening project. Please consider this as high priority issue for next development cycle.
I've made a TASK issue 18312 for tracking rewrite of "beans autoloading", Timer bean placement and behavior, and related issues (which I don't think to be Form Editor bugs in 3.3). *** This issue has been marked as a duplicate of 18312 ***
Resolved for 3.3.x or earlier, no new info since then -> closing.