Tim,
Ok…I retested with my changes taken
out of org.eclipse.wst.core.Server you are 100% correct, they are
unnecessary. So what I am planning to do now is;
i)
Create a
dummy main that will satisfy the requirements of <start> command within
the serverdefinition.
ii)
Create a
dummy shutdown that will satisfy the requirements of <
stop > command within the serverdefinition
iii)
In the
case of a startup triggered by a remote server the org.eclipse.jst.server.generic.core.internal.GenericServerBehaviour.setupLaunch()
will not do any check that the ports are in use.
iv)
In the
case of a startup being triggered by local server and the server definition describes
this server as remoteable (supportsRemoteHosts="true") will not do
any check that the ports are in use (we could be connecting to an already running
server started within Eclipse or indeed from command line etc.)
v)
We will
let the PingThread determine if the remote or local server is up and running in
ii) and iii)
Does this seem reasonable? Or should the
main and shutdown be smarter?
From:
wtp-dev-bounces@xxxxxxxxxxx [mailto:
wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Timothy Deboer
Sent: 04 October 2005 00:29
To: General
discussion of project-wide or architectural issues.
Subject: Re: [wtp-dev] Remote
Server Support
Hi,
The
changes to org.eclipse.wst.server.core.internal.Server are actually not
required - it is setting up defaults which should automatically be overwritten
when the user picks a hostname. Outside of WTP we actually have a couple of
(non-generic) adapters that support remote servers, so the wst.server framework
should already support this unless you run into any special cases.
For
the server states, I'm not convinced that we need new ones. We've seen two
types of servers with similar requirements - in one case we used the same
states and just used different text in the UI, and in the other there is a
background thread that just updates the state between STARTED, STOPPED, or
UNKNOWN. Unless we are expecting large delays when trying to connect, do we
really need to have new states or display it any different to the user? If I'm
not thinking along the same lines as you, a state diagram might help to clear
things up.
In
either case, please open a bug for this support, and so that we can track any
changes. Even if you aren't done enough of your investigation to submit a patch
or requirements, we can continue the discussion there or even assign the bug to
you for now. :)
Arthur
- The API you're suggesting already exists.
org.eclipse.wst.server.core.util.SocketUtil.isLocalhost() returns true if the
hostname is local, taking into account the various forms of localhost and DNS
lookup.
Thanks,
Tim
deBoer
WebSphere Tools - IBM Canada Ltd.
(905) 413-3503 (tieline 969)
deboer@xxxxxxxxxx
Arthur Ryman/Toronto/IBM@IBMCA
Sent
by: wtp-dev-bounces@xxxxxxxxxxx
10/03/2005 02:43 PM
Please
respond to
"General discussion of project-wide or
architectural issues."
|
|
To
|
"General
discussion of project-wide or architectural issues."
<wtp-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
Re: [wtp-dev] Remote Server Support
|
|
Mike,
Seems like hostname != localhost
is not a
safe way since there are other ways to refer to your local machine, e.g.
127.0.0.1, or use the actual hostname, e.g. at work I'm
ryman.torolab.ibm.com.
Why not add a property to explicitly indicate local support?
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@xxxxxxx
Hello WTP-Dev,
I am working on a patch to enable use of remote servers with the Generic Servers
from WTP, with this in mind I have already taken out the hard-coded
"localhost" hostnames in the classes
org.eclipse.wst.server.core.internal.Server and
org.eclipse.jst.server.generic.core.internal.GenericServerBehaviour and
replaced them with calls to the method
org.eclipse.wst.server.core.IServer.getHost() which is now working. Also
I have created a server definition for a server type that has a property of
supportsRemoteHosts="true" so that I can see a servertype when I
change the hostname. I can now create a local version and a remote
version of my server type, and I can even start my local server.
Where I am now is that I have got to a point that when I try to run my remote
server ie. (my connect to a remote server server) it is running though a piece
of code in
org.eclipse.jst.server.generic.core.internal.GenericServerBehaviour.
setupLaunch()
that checks that the ports for the server are not in use and this is a problem
for connecting to a remote server as this check is irrelevant, instead I would
like to disable this check and anything else that is specific to using a server
on a local machine in the remote case. What would be an acceptable way of
doing this? Would hostname != localhost be enough to determine the server
is a connecting to remote server rather than running a local instance of a
server?
I had an idea that I might be able to create new states for the server called
org.eclipse.wst.server.core.IServer.STATE_DISCONNECTED,
org.eclipse.wst.server.core.IServer.STATE_CONNECTING,
org.eclipse.wst.server.core.IServer.STATE_CONNECTED,
org.eclipse.wst.server.core.IServer.STATE_DISCONNECTING and use these instead
of the org.eclipse.wst.server.core.IServer.STATE_STARTING,
org.eclipse.wst.server.core.IServer.STATE_STARTED, org.eclipse.wst.server.core.IServer.STATE_STOPPING
and org.eclipse.wst.server.core.IServer.STATE_STOPPED in the case of a remote
server. Checks for these states would be added to the ones of the start
server and in the case of the remote server we will progress through this 2nd
set of states.
What I would like to hear from you is;
i)
Is this a good
idea?
ii)
Would you have a rough idea of how
many places these states would be set and read?
iii)
Would there be many complications to
adding this new sequence of states?
iv)
Would a fix like this be acceptable
to you guys? If not can you suggest to me an alternate way I might
approach this?
Thank you for all your time and effort,
Mike Reidy.
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev