Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] how to synchronize start/stop state in server adapter

Hi Rochelle,

There are a number of factors that play into this, mostly dealing with what form of 'reconnecting' your server supports and how you want to enable it. The actual implementation is really just how you implement the methods in ServerBehaviourDelegate to provide this behaviour. Here are the basics:

* Server adapters can have an initial state before they are initialized. Since the server may be started before the tools, you'll probably want to remove this optional line from the serverTypes extension point so that the state will be determined dynamically:

<extension point="org.eclipse.wst.server.core.serverTypes">
       initialState="stopped" <-- remove

* ServerBehaviourDelegate.initialize() gives you a chance to initialize your adapter. More importantly, it also provides an opportunity to add a listener to the server's state (or a thread to poll the state) and continually update the state within the tools. Depending on the server, this could mean polling an HTTP port, connecting via JMX, or using some other mechanism. Typically this listener will set the initial state using setServerState() and then update periodically when it notices changes on the server.

That's literally all there is to get the basic behaviour. However, there are some other things to think about:

* Does publishing need to be done differently in this mode?

* If the tools didn't launch the server you won't have a console. Does your server output to a file that you can read and display in a console, or is there another way to get the console output?

* When you connect to a server in debug mode, you'll want to call setMode() and then reattach the debug process. This usually involves creating a fake debug launch and connecting it to the server.

* Can you implement stop and restart if you didn't create the process? Most servers have some form of API to be able to do this from another process.

* Remote servers add another wrinkle. The methods you need to implement are the same, but the underlying implementation may need to be different - e.g. displaying a console may not be as easy as looking at a local file.

* Do you need separate implementations for some methods in  local launch, local connect, and remote connect? Maybe remote support isn't necessary or you can simplify to a single implementation.

I hope this helps. Please let me know if you have any questions.
Tim deBoer

From: raccah@xxxxxxxxxxxx
To: "General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
Date: 08/29/2008 06:00 PM
Subject: Re: [wtp-dev] how to synchronize start/stop state in server adapter

Larry Isaacs wrote:
>> -----Original Message-----
>> From: wtp-dev-bounces@xxxxxxxxxxx [
>> On Behalf Of raccah@xxxxxxxxxxxx
>> Sent: Wednesday, August 27, 2008 6:20 PM
>> To: General discussion of project-wide or architectural issues.
>> Subject: [wtp-dev] how to synchronize start/stop state in server
>> adapter
>> I'm working on the GlassFish plugin for eclipse and have had a bug
>> filed
>> against the plugin about keeping the server state in eclipse
>> synchronized with starts/stops outside of eclipse.
>> <>
>> The bug was originally filed in the eclipse bug system:
>> <> and rightfully
>> redirected to the glassfish plugins one.
>> My question is about the comment in the eclipse bug by Tim deBoer:
>> "The WTP server framework does support this, and several server
>> adapters
>> take advantage of it. Depending on the situation & support of the
>> adapter, some will automatically reconnect to the server on startup and
>> display the correct status, or at least allow some interaction."
>> I would like to know *how* to make the server adapter take advantage of
>> it, especially because I asked a similar question on the newsgroups a
>> while ago and thought I understood from the response that it was not
>> really possible:
>> <
>> ebtools#16737>
> My answer assumed you were referring to Tomcat plug-in behavior in general, which I can see now was a bit off target.  There are a number of issues that make "reconnecting" difficult for the WTP Tomcat plug-ins.  What is possible for glassfish depends on what it supports.  If you can post some details to the thread above (or in a new thread) about how the glassfish plug-ins interact with the server, I and others can try to respond, more appropriately this time.
> Also, I think that the main complaint that is spawning this discussion is contained in this thread:
> Feel free to respond in that thread as well.

Larry, thanks for your response on this thread and the others and the
pointer to the other discussion.  I will post more there, but if Tim can
weigh in (here, there, or in the bug report) on what was meant by his
comment, that would definitely help me.


> Cheers,
> Larry
>> Thanks for any advice you can provide,
>> Rochelle
>> _______________________________________________
>> wtp-dev mailing list
>> wtp-dev@xxxxxxxxxxx
> _______________________________________________
> wtp-dev mailing list
> wtp-dev@xxxxxxxxxxx
wtp-dev mailing list

Back to the top