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.
1. JDBCManager.getDefault().getDrivers() is called upon each startup, sometimes very early. It is caused by registering Derby and Pointbase when the appserver's J2EE platform is created. The J2EE platform can be created very early in the startup phase, sometimes even from ModuleInstall (it is triggered by opening the projects and adding their classpaths to GlobalPathRegistry). If you don't find another way to check that the Pointbase databases are registered, consider at least calling RegisterPointbase from the warmup only. 2. The registration of Derby and Pointbase happens in the AWT thread! The same for the creation of the Derby sample database. Consider replacing the SwingUtilities.invokeLater() calls in RegisterPointbase and PlatformImpl with RequestProcessor.getDefault().post().
For 1, I am the one who is called, so the issue is in J2EE server lazy init. For 2, I'll do the change, but this P2 bug will move to J2EE server (again?) Or projects module? Now, this bug is also incomplete since it does not provide any metrics (acceptable or not).
Fyi, the plugin does not implement the public void installed() public void restored() methods on org.openide.modules.ModuleInstall class, so the bug is clearly not there but in the J2EE platform area.
Re. #1: the J2EE platform is there mainly to provide libraries and source for them. As such it can be initialized whenever the libraries are needed. When a project is opened in the IDE, its classpath is added to GlobalPathRegistry, and when this happens SourceForBinaryQuery is asked to provide the sources for the binary classpath items. Since j2eeserver provides a SourceForBinaryQuesyImplementation, j2eeserver has to initialize all J2EE platforms it knows about and ask them for their libraries and sources. Therefore this bug is not caused by the initialization of j2eeserver. The bug is the appserver plugin code, whose PlatformImpl constructor is not supposed to do more that initialize the appserver's J2EE platform implementation. I don't consider the bug incomplete. At least a part of it (running long-duration tasks in the AWT thread) is clear. Can the database registration be moved from PlatformImpl to warmup? If not, why?
Re #2: I think this is the worse part and should be fixed. At the same time, the Javadoc of the registration method should clearly state the threading expectations (this is long running, call in this or that thread, don't call in this or that thread, ...). Andrei, can you please add the corresponding Javadoc? Re #1: I agree with Andrei's evaluation and it would be nice to fix this, however I don't think this part by itself is a P2. I don't consider this part critical for 5.0.
Updated the DerbySupport Javadoc to emphasis that the sample database should not be created in the AWT thread. Checking in DerbySupport.java; /cvs/db/derby/src/org/netbeans/modules/derby/spi/support/DerbySupport.java,v <-- DerbySupport.java new revision: 1.8; previous revision: 1.7 done
/cvs/serverplugins/sun/appsrv81/src/org/netbeans/modules/j2ee/sun/ide/j2ee/db/RegisterPointbase.java,v <-- RegisterPointbase.java new revision: 1.15; previous revision: 1.14
Thanks. Be warned though that the names of the XML registration files for drivers and connections are not publicly documented and could change at any time. But I'm not planning any changes in 5.0, so it will probably work for now. Marking as verified.