Created attachment 744693 [details] service handling script For easier EAP service management on Windows it would be nice, if files "service.bat" and "service.conf.bat" would be part of native packages like: jboss-eap-native-utils-X.Y.win6.Z.zip/jboss-eap-6.1/modules/system/layers/base/native/sbin/ jboss-eap-native-utils-X.Y.win6.Z.x86_64.zip/jboss-eap-6.1/modules/system/layers/base/native/sbin/
Created attachment 744694 [details] service handling script
It's available in jboss-eap-native-utils build https://brewweb.devel.redhat.com/buildinfo?buildID=280254 which will be included with EAP 6.1.1.ER2 Is there a reason, why the following lines are needed in the service.conf.bat? set EAP_VERSION_MAJOR=6 set EAP_VERSION_MINOR=1 set EAP_VERSION_MICRO=1 set EAP_VERSION_PATCH=ER2 set EAP_VERSION=%EAP_VERSION_MAJOR%.%EAP_VERSION_MINOR%.%EAP_VERSION_MICRO%.%EAP_VERSION_PATCH% This effectively means we need to rebuild with every ER even if there are no changes. If it's not necessary, I am in favor of removing those.
Verified that "service.bat" and "service.bat.conf" is part of ER2 -> OK Vaclav, It is just for naming Windows service. I suggest remove EAP_VERSION_PATCH: 1. Remove line set EAP_VERSION_PATCH=ER2 2. Update set EAP_VERSION=%EAP_VERSION_MAJOR%.%EAP_VERSION_MINOR%.%EAP_VERSION_MICRO%.%EAP_VERSION_PATCH% -> set EAP_VERSION=%EAP_VERSION_MAJOR%.%EAP_VERSION_MINOR%.%EAP_VERSION_MICRO% Are you with it?
I would suggest also removing %EAP_VERSION_MICRO%, it's a convention, that for module paths, and naming of the distro major.minor version should be enough. Is this OK?
Ok, no problem.
It will be delivered with ER3.
One thing missing in comment 9. - For successful service installation ("service install") you have to set env. variable JAVA_HOME properly.
I've just found out about this bug, which is basically a duplicate of my bug 732889. That other one has a completely different service script, which GSS has been giving to customers (and make available in customer portal Solutions) over the last year :( The script on this bug doesn't appear to support domain mode (as the DC or HC), and uses the "load libjvm.dll" feature of prunsrv.exe rather than having it start the normal startup scripts. Having prunsrv.exe do that has a number of problems: 1) Having it invoke System.exit() sometimes causes problems where using the CLI to issue the ":shutdown" works better. 2) You can't change the Java options without re-installing the service. This could be a problem for the JBoss admins who aren't Windows admins 3) It hard-coded the name "commons-daemon-1.0.14-redhat1.jar", which I think will mean you need to re-install the service if you upgrade JBoss 4) All the instructions which tell someone to add configuration to standalone.{bat,sh} will not work as expected, and admins will need to realise they have to alter the service script and re-install.
Hi James, thank you for information. Ok, nevertheles we provide prunsrv.exe in a EAP natives utils package, so we need documentation for it. What about update doc with following way: - In a chapter "3.9.3. Configure JBoss EAP 6 as a Service in Microsoft Windows Server (Zip, Installer)" add new subchapters: 1. Install service with GSS script (or smth. like that) - add link + info how to work with it - mention it as preferred variant because of ... 2. Install service with prunsrv - it is actual text + wrap info from James - mention reason why could be usefull use installation by this way (development) What do you think?
Resetting the requires_doc_text flag to '?' pending a resolution on the handling of this.
A per email discussions, I updated the script I wrote and attached the new version to the original BZ 732889 As a sidenote: that BZ led to PRODMGT-219. Please see Comment 42 on BZ 732889 for the status/install instructions. Download the "v6" attachment which is z ip with the bat file inside. Execute the service_v6.bat to see the usage. As James mentioned in comment 13 here above, my script has: - domain mode support - uses normal JBoss config files, no need to reinstall the service when changing JVM settings - uses the CLI to cleanly shut down, so no hitting the issues sometime seen with System.exit() - no hardcoded dependency on the JBoss version, single script works with 6.0.0, 6.0.1, 6.1.0 etc - allows setting service log level - all install options configurable from the command line - documented with a "usage" screen It does however not check on JAVA_HOME, it expects the user to have set this as an environment variable if needed. If required it's easy to add of course.
This bug's release note is being marked for exclusion from the 6.1.1 Release Notes until all parties reach consensus and the new script passes QE verification. The associated topics have also been removed from the main documentation suite for the same reason.