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">
<serverType
...
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
[EMAIL PROTECTED]
From:
[EMAIL PROTECTED]
To:
"General discussion of project-wide or architectural issues."
<[email protected]>
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>> On Behalf Of [EMAIL PROTECTED]
>> 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.
>> <https://glassfishplugins.dev.java.net/issues/show_bug.cgi?id=53>
>>
>> The bug was originally filed in the eclipse bug system:
>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=244878> 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:
>> <http://www.eclipse.org/newsportal/article.php?id=16737&group=eclipse.w
>> 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:
http://dev.eclipse.org/mhonarc/newsLists/news.eclipse.webtools/msg17107.html
> 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.
Thanks,
Rochelle
>
> Cheers,
> Larry
>
>> Thanks for any advice you can provide,
>> Rochelle
>>
>> _______________________________________________
>> wtp-dev mailing list
>> [email protected]
>> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>
> _______________________________________________
> wtp-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/wtp-dev
