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.
Editorial comment: I am opening this defect to replace issue 53482 which is unclear (to me). That issue described a "solution" without decsribing the problem. Numerous comments in the bug and in separate e-mails have clarified the problem statement. I want this issue to have a clear issue description BEFORE proposing a solution. Problem description: If the user installs NetBeans and the App Server from rpm's or solpkg's the domains directory for the app server is write protected. When the user starts NetBeans and wants to do J2EE development, they need to register a server instance. Currently, the plugin presents data that allows the user to register a domain which they cannot start or stop as their "default" choice, if they enter the "root" installation info for the app server. Note: this may be the ONLY app server installation information available to the user. The user is told that the instance will be treated as a remote instance. [This message is correct, but not very useful. 55725] The user can start working with J2EE development at this point. The user cannot test/debug the code that they have developed, since their projects are targeted to a server instance that they cannot start. Work-around: The user needs to use the create-domain command (outside the IDE) to create a useful domain/instance, register this new "useful" domain with the IDE and retarget their projects. The additional steps have a strong, negative effect on the initial out-of-the-box experience for users.
Please verify that this DEFECT describes the ISSUE that 53482 described A solution for, initially
who should verify this? I need a name there ...
I expect Ludu, Pavel and TDT to validate that I have distilled the various comments and e-mail threads into an accurate problem statement. I expect Petr B. to take a look at it and validate that the problem statement is the one that 53482 would be a solution for.
Checked in changes to the closed source side to address this issue. Need to update the scrambled bit in the NB repository. Here is a summary of what happens: If the user doesn't have read access to any <as-install-dir>/domains/*/config/ domain.xml files the plugin looks for a config/domains.xml file in the subdirectories of the USER DIR. If none are found, the plugin computes a random port for the admin port. The plugin fills in the location field as 'localhost:<port-value>'. It also prefills the domain directory (with USER DIR) and name field (myDomain1). When the user enters the admin username and password, they see a message: Click Next to create domain. The next page presents the other configurable ports, which have initial values computed. The finish button is enabled. Clicking Finish creates a domain.... If this initial private domain/instance is created in the USER DIR, the create functionality is disabled... there are too many error conditions that need to be handled. If the domain cannot be created, the instance should not be registered. The user gets to see the output of the create-domain command, so they can try again and avoid port conflicts (which are the most common cause of failure for the create-domain). Checking for port conflicts is very expensive. Doing it twice is even worse...
I integrated the fix. We might have some EOU issues, but not P2. So closing this one and waiting for comments now.
v rc2/solaris