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>
>
<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
------------------------------------------------------------------------
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev