Bug 960560

Summary: Add service.bat and service.conf.bat
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Jan Stefl <jstefl>
Component: BuildAssignee: Vaclav Tunka <vtunka>
Status: CLOSED CURRENTRELEASE QA Contact: Jan Stefl <jstefl>
Severity: unspecified Docs Contact: Lucas Costi <lcosti>
Priority: unspecified    
Version: 6.1.1CC: jlivings, jstefl, pkremens, rdickens, smumford, tfonteyn
Target Milestone: ER2   
Target Release: EAP 6.1.1   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Enhancement
Doc Text:
Included in JBoss EAP 6.1.1 is an easier way to configure JBoss EAP 6 as a service in Microsoft Windows Server. Before this enhancement, users had to create the service batch files themselves or perform steps included in the batch manually. Please refer to the _Configure JBoss EAP 6 as a Service in Microsoft Windows Server (Zip, Installer)_ section in the _Red Hat JBoss Enterprise Application Platform 6.1.1 Installation Guide_ for instructions.
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-05 09:39:05 UTC Type: Enhancement
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1006345, 1006346    
Description Flags
service handling script
service handling script none

Description Jan Stefl 2013-05-07 11:49:39 UTC
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: 


Comment 1 Jan Stefl 2013-05-07 11:50:04 UTC
Created attachment 744694 [details]
service handling script

Comment 3 Vaclav Tunka 2013-07-01 15:39:10 UTC
It's available in jboss-eap-native-utils build

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?

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.

Comment 4 Jan Stefl 2013-07-03 12:27:28 UTC
Verified that "service.bat" and "service.bat.conf" is part of ER2 -> OK


It is just for naming Windows service.
I suggest remove EAP_VERSION_PATCH:
1. Remove line set EAP_VERSION_PATCH=ER2
2. Update 

Are you with it?

Comment 5 Vaclav Tunka 2013-07-03 13:54:57 UTC
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?

Comment 6 Jan Stefl 2013-07-03 14:08:12 UTC
Ok, no problem.

Comment 7 Vaclav Tunka 2013-07-08 15:15:17 UTC
It will be delivered with ER3.

Comment 11 Jan Stefl 2013-08-06 06:37:51 UTC
One thing missing in comment 9.
 - For successful service installation ("service install") you have to set env. variable JAVA_HOME properly.

Comment 13 James Livingston 2013-08-20 05:59:29 UTC
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.

Comment 14 Jan Stefl 2013-08-20 06:34:19 UTC
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?

Comment 15 Scott Mumford 2013-08-21 03:27:49 UTC
Resetting the requires_doc_text flag to '?' pending a resolution on the handling of this.

Comment 16 Tom Fonteyne 2013-08-21 15:20:25 UTC
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.

Comment 17 Scott Mumford 2013-08-28 00:32:17 UTC
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.