Hi,
Sorry, I was refering to a couple adapters for IBM servers that are
not currently open source. There are other teams besides my own, but
the ones that I am referring to are available in WebSphere Application
Server Toolkit and Rational Application Developer.
Thanks,
Tim deBoer
WebSphere Tools - IBM Canada Ltd.
(905) 413-3503 (tieline 969)
deboer@xxxxxxxxxx
*Justin Chen <yung-chang.chen@xxxxxxxxxx>*
Sent by: wtp-dev-bounces@xxxxxxxxxxx
10/03/2005 07:44 PM
Please respond to
yung-chang.chen and "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
Hi Tim,
What are the non-generic server adapters support remote servers outside
of WTP?
Thanks,
Justin
Timothy Deboer wrote:
>
> 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
>
> *"Mike Reidy" <mike.reidy@xxxxxxxxxxxxx>*
> Sent by: wtp-dev-bounces@xxxxxxxxxxx
>
> 10/03/2005 12:40 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
> [wtp-dev] Remote Server Support
>
>
>
>
>
>
>
>
>
>
>
>
> 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 2^nd 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
>
>------------------------------------------------------------------------
>
>_______________________________________________
>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
------------------------------------------------------------------------
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev