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.
There is no easy way how to execute module code at the end of startup when modules & winsys are up and running. Common trick is to listen to windowOpened from main window used - in autoupdate to check for updates after some delay - in Java support to start CP scanning - in core to start warmup with some delay OTOH this does not solve timing and mutual dependencies well. It would be better to have a registration point for hooks that will be executed in defined order.
Projects are another potential client - the Broken References dialog should appear after the main window is shown. See issue #50140.
I think we can find many potential users of such an API without looking too hard...
Yarda, can this be achieved with now after your openide split (and RunLevel)?
The runlevel works, but is not part of org.openide.modules API. Shall I move it?
After discussion with jlahoda, rkubacki and mkleint we came to following conclusion: Usecase: There is a need to execute a piece of code as soon as the module system is visible. Moreover the code needs to run in "exclusive" mode, if there is more of such codes scheduled, only one can run at given time. Right now there is no need for priorities, but in future there may be. The code is usually (but not all the time) going to display a dialog or manipulate swing components in other ways, so running in AWT thread is likely an advantage. Scenario: The solution seems to be tight a lot to window system (as the only piece of code that knows when it is really visible) so the proposal is to add WindowManager.invokeExclusively(Runnable). The modules that wish to display a dialog on startup would then override ModuleInstall.restored() and inside it they would use the invokeExclusively method knowing that they will be called as soon as the main window is shown. Then they can use regular DialogDisplaer method to do whatever they want inside the runnable (which runs in AWT thread). If all modules that (potentially) display a dialog on startup use the invokeExclusively to show their dialogs and block for the result, user will see only one dialog at a time. Also modules that do not care when their dialogs are shown, can use the invokeExclusively method anytime, it will work even if the windowsystem has already been initialized and will invoke the runnable asap. Assigning to Milos, to implement this and CCing apireviews, as this is going to be an API change, so if you do not like the solution, speak soon to save useless work.
The key phrase in Yarda's proposal seems to be: > called as soon as the main window is shown This sounds like an NB API to do exactly what J2SE API's already do. I'm currently responding to a window opened event to perform some tasks which really need to be performed before the main window is opened (I'm hiding some menus in the menubar). Currently, the main window comes up with the undesirable (from my projects point of view) menus displayed. They are immeditately removed, but not before they are displayed and the user sees them disappear. Will this API change that? From that one sentence above, it doesn't sound like it will. It just sounds like a replacement for what we're already doing (and I think others are as well).
1. I do not think this is a replacement, otherwise I would close this as wontfix. But if you insist, I am fine with closing it. 2. You want hook to hide toolbars and menus? You must be kidding! Do it in layer with _hidden files as described in the docs.
There is a need for a similar functionality in the J2EE area. Our use case is that when NetBeans starts with a clean userdir we need to create a sample database and register it in Databases in the Runtime tab. We obviously can't use ModuleInstall for this, and we can't make the creation lazy (like create the database when the user expands the Databases node). Our Runnable shouldn't run in the AWT thread though, since creating the database is a potentially long task. And scheduling from AWT to a RequestProcessor breaks the Runnable exclusivity. I guess java support's classpath scanning use case is similar. Of course, if posting to a RP is considered OK, we're fine with that.
To abadea: I don't think you should be registering databases unconditionally during startup! Sounds like an unnecessary performance hit. Consider finding some other "hook" that would make for an appropriate time to do this work - e.g. the first time a J2EE-related project is opened.
We already considered some other hook, of course. About 5 people for the last 3 days have been working on this.
To jglick: this would be done only for the Sun Java System App Server + NetBeans bundle, where it is very likely the database will be needed, since the J2EE tutorials use it. In the "plain" NetBeans the database will be created only when needed, that is when the user registers a Sun appserver instance. The lazy hook has it own problems and is bad usability. Imagine the NetBeans is started and looks initialized, you work for a while, then go to the Runtime tab and expand the Databases node (or create a J2SE project) and it starts creating a database. Looks weird to me. The performance hit is around like one second.
To pjiricka: Will you be publishing an API including when your hook will be run? I'd like to know if it will meet my products requirements (running before the main window opens).
First, what abadea describes is different then the rest of requirements described here in that it inly runs at the very first start. We would be happy to use any other solution if it was available. Maybe updater? For lazy init usability is only one of the problems. The other thing is that doing things in a way that they work nice for lazy initialization at N different places is a lot of work (non blocking calls, progress UI, etc.). This is OK when it is really needed, but considering that the used abadea described only happens ONCE - on the very first start - not on every start, I think that lazy inicialization is too complex.
This is duplicate of enhancement 67934, which I implemented and integrated recently. Please see 67934 for more details about implementation. *** This issue has been marked as a duplicate of 67934 ***