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's really no right or wrong here since this is almost a usability question, but from my experience most users familiar with starting a server and seeing console output would expect a similar console view - in this case probably one that does a tail on the server log file.

Thanks,
Tim deBoer
deboer@xxxxxxxxxx



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





Hi Tim,

Just getting back to this.  I tried to pull out the initialState=stopped
and that's a good first step.  As you mentioned, getting the log output
is one of the next steps I need to handle.  In most cases (barring user
changes or log rotation), pointing at a file would do what I need.  Is
the right approach to use a console and an image descriptor to do so?

Thanks,
Rochelle

Tim deBoer wrote:
>
> 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
> deboer@xxxxxxxxxx
>
>
> 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 [
mailto: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.
>  >> <
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
> <
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
>  >> 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



Back to the top