J2eeserver module provides Tools|Servers dialog and Servers node in Services tab that is only used for J2EE/Java EE server. This proposal describes how to make it possible to reuse this UI for other types of servers, such as PHP web servers and rails servers. One motivation is to provide simplified and uncluttered UI. Another motivation is to naturally integrate servers that support multiple technologies, such as GlassFish v3 (rails, j2ee, php). Another possibility is to reuse the same UI for database servers. There is currently no support for them except the ad-hoc support for Java DB.

User Interface

  • All server nodes should be under Servers
  • There should be one common Add Server action and wizard that would list all server types, e.g. Local PHP server, Mongrel, GlassFish v2, GlassFish v3, Tomcat, etc. (of course only if you have full NetBeans, otherwise just the server types supported in your installation, e.g. Ruby only, PHP only)
  • GFv3 must able to show only 1 node with all 3 flavors.


  • General server API should be designed at the level of registering nodes into Servers node and Tools Servers dialog and items into Add Server action.
  • It is up to each server to decide how it shows its subnodes and v3 should show subnodes for all types of content it supports.
  • PHP should have a concept of php server api, rails should have a similar concept of rails server api, GF v3 should implement both (and j2eeserver api).
  • Internally v3 plugin should be implemented by a "core" module and separate plugins for php, rails, j2ee. Those of them that will be installed will provide subnodes and will implement integration APIs, like j2eeserver api and phpserver api.


  • Should support server instance persistence (otherwise, each server instance provider will have to write own persistence code, probably all duplicating each other)
  • Does ServerInstance need a getLookup() method? Current can work around this by using Lookup on root node accessible via getRoot().
  • My intent is that server instances would add the flavors (j2ee, ruby, etc.) they support to lookup and server consumers would iterate servers to look for type they want via lookup. (Can implement this second half as shared helper code in common server API)

Overall module layout

The following picture shows module dependencies and usages for the current state (simplified). File:currentAPI_CommonServerAPI.jpg

Next picture shows the target state (not necessarily for 6.1). Server module is used by the IDE UI (not depicted). The Ruby API and PHP API are imo not yet well established afaik (please correct if wrong). There would be possible improvement in establishing some common support API for all three frameworks, however this should be done after some experience with that and in clean way (don't think this should be done for 6.1).

In order to not to make picture confusing there is missing bridging dependency between j2eeserver and server module preserving the backward compatibility of the j2eeserver. File:commonAPI_CommonServerAPI.jpg


Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo