The problem about tomcat is java.All other modules are detected by process name, but there is no tomcat but only a java-process.The only way Ive seen is to check for a process "java.exe" and than check, if it has 3 listening connection. Not beatyful but it works (more or less).Since this detection is not always 100% working I added that "Force start/Force stop" options.

I wanted to provide a possible workaround for the tomcat process issue.

There is a free program called launch4j that allows for wrapping java applications and specifying a custom process name: http://launch4j.sourceforge.net/It has versions that work on Windows, Mac and Linux.

I tried it out to see if it would work with the latest XAMPP windows beta and its seems to work well for me.

It creates an XML file with configuration options. I put the wrapped EXE and the config file in the root tomcat directory for testing (xampp/tomcat). Below is what I setup in the program to get it to work:

Hackattack: sorry I didnt answer earlier.Thanks a lot for your comments and your work. Sure this is an interesting idea.But i think there are enough dependencies and different supported windows systems and so possibible problems in that whole port of xampp and the controlpanel3, so we should not bring such new components in it. If there is a status blinking or a wrong status display for tomcat i think we can live with it and it should be acceptable, isnt it?

What about using a built-in Windows tool like tasklist. It is a CMD utility that can list all the available processes running, PIDs, etc and I think it comes with all versions of Windows (at least XP onward). You could use it to search for the java processes like so:

You could do a check before launching Tomcat taking note of all currently running java processes and pipe the output somewhere for processing. When you start Tomcat, you could do another check and take note of the new java process that appears. You could then monitor just that PID. I don't actually use Tomcat but I thought I would throw a few ideas out at least.

Actually as a developer, I understand the problem of looking into the Java sandbox - the problem IS that it's a sandbox (or a blackbox, if you prefer). I guess in some ways you could say - (LOL) "maybe Sun did TOO GOOD a job isolating it."

Anyway, I'm pretty juiced to see the new VC9 compiles, that will solve some issues for those who want to bring in 'alien components' they may find wandering around on the Net. Won't solve ALL issues, and may complicate providing answers to 'why won't that work', just like the identically named libraries and Java instance problems.

Soon we will all look back on 32 bit machines and OS's, like we do on 16 bit Windows 3.11 (or DOS or 8 bit CP/M)

dmsclz wrote:May I ask why you recommended that cport-program? This feature is included in xampp-control3 ("netstat"). Anything missed there?

This nice little GUI contains at a glance all the information one could require to investigate port use with the additional features of being able to manipulate via the File menu the processes plus the ability to close a selected TCP connection if required for testing an XAMPP installation error.

I also like the ability of it to flexibly refresh at varying intervals set by a config setting, then you can spot opening and closing of ports by various processes in real time.

I have found that a GUI is preferable to most Windows users over a command console program like netstat.exe for example, which is now thankfully in a GUI form in the XAMPP Control Panel V3, but netstat has a limited function capability over the more comprehensive Curr Ports utility for those seeking explicit information about a port and it's user.

Remember that cports.exe file (Curr Ports) was called upon for 'ports in use' in previous versions of XAMPP in the included xampp-portcheck.exe utility.

Thanks for the log file fix, I will download and test - what was the problem?

Best wishes.

Last edited by Sharley on 22. July 2011 02:26, edited 1 time in total.