>________________________________ > From: André Warnier <a...@ice-sa.com> >To: Tomcat Users List <users@tomcat.apache.org> >Sent: Sunday, April 29, 2012 2:18 PM >Subject: Re: How to run Tomcat as Service on windows start up.
>> Mark Eggers wrote: >> NetBeans will complain that it cannot find the startup.bat and shutdown.bat >> required to do these tasks if you install the service. > > Presumably then, you could replace startup.bat and shutdown.bat > by similarly-named .bat files which respectively do >net start "Apache Tomcat" >and >net stop "Apache Tomcat" >(to keep it simple) > I suppose you could. I don't know how intrusive NetBeans' investigation of the scripts are. In Windows Vista and Windows 7, UAC might become a problem. I'm not a Windows person, so I'd have to investigate this. > Similarly, it should be possible to create .bat files which run the Tomcat > wrapper tomcatX.exe with the appropriate arguments to start, stop, or run > Tomcat in debug mode. From my recollection of the service, don't you have to configure the service for debug using the service configuration program? I'm not sure how you would handle that through NetBeans, since I believe it simply does what start.bat / catalina.bat require (pass the debug argument to catalina.bat). So, you might need a single startup.bat and shutdown.bat that would determine which service to run, and which service was running . . . . > > No ? > >(Although, if I understood the OP's request correctly, the point here would > be to start Tomcat as a service as soon as Windows starts. So presumably, > the necessity of having a "startup.bat" is not evident anymore). It's a little unclear as to what the OP request is. It sounds like the OP has two requirements: 1. Deal with Tomcat in a development environment using NetBeans To me this means starting, stopping, debugging, launching with the security manager, etc. That's hard to do when you don't own / completely control the service. The same problem exists in Linux. People want a system-wide Tomcat but want to use NetBean's deploy and debug facilities. There are all sorts of interesting permissions problems with this. NetBeans operates by deploying a context.xml file as [app-name].xml in the appropriate Engine/host directory. The application is actually run out of [project-name]/build. This works fine, and you can do a lot of dynamic updates in this fashion. What happens when the user of the IDE doesn't have access to post a context. xml to the appropriate directory? What happens when Tomcat doesn't have access to read a user's [project-name]/build directory? So for this use case, it's far easier and cleaner to maintain your own copy of Tomcat that can be registered, managed, and controlled by NetBeans. 2. Demonstrate works in progress to other developers Putting aside for the moment that turning development box into a demonstration server may not be a good thing, it's sometimes handy. For this I was recommending a system-wide Tomcat (run as a service). You then just use the manager application to update it with the latest demonstration-ready software. I think this has a few advantages. You don't show off intermediate (and potentially embarrassing) code. The service is up regardless of whether you're developing or not (OP's original request). . . . . just my two cents. /mde/ --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
