Feature/windows service collectors pr

[ReineLindqvist]

Summary

• Add WindowsServiceWrapper class with start()/stop() static methods for Apache Procrun (prunsrv.exe) integration
• Add dbxtune_service.bat script for installing/uninstalling/managing DbxTune collectors and DbxCentral as Windows services
• Add README_windows_service.md with setup instructions, examples, and troubleshooting
• Add setAppNameCmd() setter to DbxTune to support service wrapper's lifecycle (the existing stack trace detection doesn't work when launched through Procrun)

The wrapper hooks into the existing ShutdownHandler lifecycle — start() delegates to the appropriate main() method (which blocks on waitforShutdown()), and stop() calls
ShutdownHandler.shutdown() to signal graceful termination. No changes to the existing shutdown flow were needed.

Usage example:
dbxtune_service.bat install DbxTune__PROD_ASE ase --serviceUser DOMAIN\svcDbx -n config.conf -SPROD_ASE -Usa
dbxtune_service.bat start DbxTune__PROD_ASE

Note

I don't currently have a Windows machine to test this on end-to-end with Procrun. The implementation follows the Procrun jvm mode contract and reuses the existing shutdown infrastructure, but it hasn't been validated against an actual Windows service install/start/stop cycle. Would appreciate a review of the approach and any feedback before testing on a Windows environment.
Maybe need to add support for gMSA.

Test plan

• Verified ant compile — no new compilation errors (existing encoding issue in AseConfiguration.java is pre-existing)
• Install a collector as a Windows service with dbxtune_service.bat install and verify it appears in services.msc
• Start/stop the service and verify graceful shutdown via ShutdownHandler
• Test with --serviceUser parameter for domain account scenarios
• Test DbxCentral as a service

[goranschwarz]

Yes that could work!

BUT... when I new version of DbxTune is shipped, the list of JAR files is normally changed...
Which then means:

• You would need to reinstall or update every service (with the new list of JARS)

A workaround for this may be to use a loader.jar (with a MANIFEST.MF file), which holds all the jar files, which we depends upon!
But... when the MANIFEST.MF can not have wildcards in it...
and I do have some wildcards (to load "unknown" or "extra" JDBC Drivers, and also the Jetty and jaxb-ri JAR's)

So... Not sure this will "fly" to 100%
And also as I described to you in a mail...
It might be better to have a angel service (that is a C# app) that reads the ${HOME}/.dbxtune/dbxc/conf/SERVER_LIST and kicks of the various collectors it finds in there... (via a start/bat file)
But lets talk more about this... and what would be the best/most-flixible solution.