It's OK to move this functionality to the Runtime tab.

Created node in Runtime tab that proxies to settings and has actions
Start and Stop. See also issue 19499

Verified in NB 3.4 dev build 200206070835.

I would like to reexamine the decision to put the HTTP 
Server node to the Runtime tab. IMO, the internal server 
should not be a user-visible feature, rather, it should be 
something that just works in the background (when needed).

The presence on the Runtime tab makes the tab 
unnecessarily complicated. Furthermore, many users confuse 
the internal server with the server that is used for 
running web applications.

So, should we remove the internal server from the Runtime 
tab ?

Unfortunately, our attempts to hide this server in the past have not
gone well.  When there is a problem, the user must search (usually
unsuccessfully) in the Tools > Options window in order to find the
HTTP server options. Also, other modules may be using this feature, so
hiding it may not work well for them. Hiding it also makes it more
difficult to document--granted, if it were truly "invisible" it should
not be documented, however I don't think that is the case.  Since this
server uses a resource (the Port number), there needs to be a sensible
explanation to the user.  Having the HTTP Server visible provides this
explanation.

Putting the HTTP Server in the Runtime tab makes it more visible than
it was before.  I agree that it could be confusing, so perhaps we
should consider moving it under the "server registry" node so that it
doesn't clutter the top level of the runtime tab hierarchy.  Having it
closer to the Tomcat/Internal server node may actually help to explain
that it is indeed a different server than the internal tomcat server
(and needs to use a different port number).

Jeff, let's answer the following questions first:
1) What user-visible functionality does the embedded HTTP 
server provide ?
2) What customizations does the user typically need to do 
in the server's settings ?

My answers to these questions are the following:
1. None
2. The user shouldn't need to do any customizations - if 
they do, then that's a bug. Things should just work out of 
the box.

From these answers, I infer that we don't need to show the 
HTTP server settings to the user.

If we do show it (again, this is not what I prefer), then 
we should choose such a name that would make it clear that 
this is NOT the server for running web applications - how 
about "Interoperability Server" or "Internal Connection 
Service" ?

It should definitely not be under the server registry, as 
the server registry is defined as registry of servers 
which can run the user's Web/J2EE applications. The 
embedded server does not fulfil this requirement.

1. The internal HTTP Server provides the ability to view Javadoc in
your system browser.  It may also provide many other features that I
don't know about since 3rd party modules may use it.
2. Ideally, the user should not have to configure it.  It should start
up automatically (which it sometimes does not, if the module developer
did not start it--which is what happened during our early access since
the HTTP monitor module did not automatically start it).

Unfortunately, things break if the user tries to start another server
with the port number we've chosen for the internal server.  We cannot
detect if the user is attempting to use the chosen port number for
another server external to the IDE (and then automatically change
ours), so I think we must at least provide a way for the user to
change the port number.  We can't assume that just because we found an
unused port when the IDE started up that the user may not want to
start another service with that port number while the IDE is running.

I see your point about putting it under the server registry, and I
guess I can understand why it shouldn't go there.  I agree that
changing the name from simply "HTTP Server" to something like "HTTP
Connection Service fro Internal Use" might be better.  The name still
has to convey that this service uses a public port number so that the
user may have a clue as to what might be conflicting with the port
that they want to use for some other service.

More replies:

Using the server for Javadoc - the server is certainly 
used when viewing Javadoc, but viewing Javadoc is not 
PROVIDED by the server - it is provided by the Javadoc 
module. The use of the server is an implementation detail 
of the Javadoc module. Saying that the server provides 
viewing Javadoc would be like saying that the OpenAPIs 
provide editing Java files. That's not true, editing Java 
files is done by the Java editor, the OpenAPIs only enable 
it in the background. The situation with the server is 
analogous.

About the conflict with another process and giving the 
user the ability to resolve the conflict: the very same 
arguments hold for the OpenFile server - it also has a 
port which may conflict with another process. Moreover, 
the OpenFile server does not detect if the port is already 
taken, and does not autoincrement its port number, which 
makes the possibility of conflict bigger. So why are you 
worrying so much about the embedded HTTP server and not 
worrying at all about the OpenFile server ?

It looks like we agree on changing the name, now what 
should the name be ? How about "Connection Service for 
Internal Use" ? Isn't that too long ? Or just "Internal 
Connection Service" ?

OK.  To close this discussion, it seems like you've agreed that we
can't totally hide the HTTP server right now.  Therefore, we should at
least give it a name that distinguishes it from the internal Tomcat
web server.  I personally like "Connection Service for Internal Use"
and I don't think that is too long.  "Internal Connection Service"
seems to similar to "Internal Web Server" to me.  The words "for
Internal Use" more clearly indicate to application developers using
the IDE that this item is for the IDE's own functions.  It should also
help module developers identify that this is a resource that they can
use for their modules.

I was not aware of the OpenFile server, so perhaps I need to look into
it and file a bug about it's behavior.  Obviously, I'm only worrying
about the HTTP server, since it is a part of the product that I'm
familiar with, and have experienced it's problems personally :-(

To be honest, I am not all that thrilled by the 
term "Connection Service for Internal Use", mainly because 
the meanings of "internal" and "connection service" are 
ambiguous, I would say that the improvement in clarity 
over "Internal HTTP Server" are minimal.
One more comment I cannot resist to make - I do not think 
that the argument about suitability for module authors is 
very improtant, since module writers are difinitely not 
the target user base we should be designing the product 
for.

Ian, I agree we should not target module authors.

As for the name, do you have any suggestions ? (I don't 
like names which contain words HTTP or Server, as people 
confuse that with the server that is used for running web 
apps.)

Well, hmm. Looking at the problem description, I still do not agree
that there is a need to make the HTTP Server configuration more
visible. What is the user scenario? Putting it to the runtime tab
expects that it will be used frequently and repeatedly, I do not think
this is the case.

It is a set of settings and settings have a standard place to be in -
Tools | Options. One could argue that the user has hard time finding
colors configuration for the editor - we are not talking about putting
this into the runtime tab, so why shoudl we do it for HTTP Server?

Yes, I completely agree with Ian on this. Now we need to 
convince Jeff :-)

Still, the user confusion happens even if the item is just 
in IDE settings. I've heard people say "I can't run my 
JSP. I've tried to change the port number of the internal 
HTTP server in IDE settings, but none of the ports I tried 
works."

I would be happy if we could somehow be consistent with how we 
addressed these issues.  Port numbers are always going to be 
user resources, so it would be great if we could present the 
complete list somewhere and allow the user to modify some, if 
necessary.  It's not critical to me for the list to be on the 
Runtime tab, if it is in Tools > Options, that would be 
fine--as long as it is documented.  In addition, when the IDE 
encounters a port conflict, then we need consistent messages 
that convey to the user what has happened and how to fix it.  I 
intend to file some bugs against the Open File Server to 
address this.

Agreed, makes sense...