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 [EMAIL PROTECTED] From: [EMAIL PROTECTED] To: "General discussion of project-wide or architectural issues." <[email protected]> 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 > [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 > <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 _______________________________________________ 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
