Small bug in WF10 Windows service installation

[nickarls]

Was there any special reason for moving the service scripts from ./bin to /docs/contrib/scripts? The directory sounds a bit like "some random user handed us some scripts and we didn't know where to put them" ;-)

Anyways, if you try to run the "service install" it complains that "Please check that this script is located in the bin\services\ directory". So you copy/move the scripts there but now there is a "file not found" because

if "%PROCESSOR_ARCHITECTURE%"=="AMD64" (

  echo Using the X86-64bit version of prunsrv

  set PRUNSRV="%JBOSS_HOME%\bin\service\amd64\wildfly-service"

) else (

  echo Using the X86-32bit version of prunsrv

  set PRUNSRV="%JBOSS_HOME%\bin\service\wildfly-service"

)

the directory in the script is service and not services so either place should be edited so that match...

[ctomc]

well you should move/copy contents of whole folder to bin/service as it is written in service.bat itself.

and yes all init scripts ware moved to docs/contrib as they are not 100% developed/supported by WildFly team as they are community contributions we don't always know how to fix.

We are not experts on all OS integration so better to leave it out to community itself, we like to help as much as possible but there are limits.

[nickarls]

I was referring to the extra "s" in /bin/services since the script itself later on expects to find stuff in in bin/service

[ctomc]

Nicklas Karlsson wrote:

I was referring to the extra "s" in /bin/services since the script itself later on expects to find stuff in in bin/service

Ups, missed that one, must be lack of coffee for past few days 

That definitely needs to be fixed.

[nickarls]

Goodie, thanks.

But about the scripts. I guess you're not selling EAP like

Sales rep: "Hey, we've got this really neat application server that will take care of all your needs".

Customer: "Cool, how do you run it? From the command line?"

Sales rep: "Umm, we're not really sure, depends on the OS. Perhaps some user has managed to get one running and shared the code"

(and the same scripts should work for the community edition anyway)

[ctomc]

I've send PR to address this issue and few others https://github.com/wildfly/wildfly-core/pull/1421

Well about scripts in general it is hard to maintain all of them especially when most of the team are java devs not system admins that are proficient in scripting for lots of different platforms and distributions and combination of them.

I know it is bad excuse but that is the truth. We do try our best to maintain our main scripts (non service/initd/sysv) to work on various platforms out there.

You would be surprised what wide array of platforms we get issues reported for, it is sometimes almost hard to believe there are so many solaris, hp-ux, aix and other non-common platforms there where scripts need to work. If you add to mix all there various archs & versions of OS you get the idea of the amount of work(frustration) is needed to make it work for everyone.

Every feature we add to one script, needs to be added to all platform variants and tested on bunch of systems

To extend that also for service scripts it would hard/insane

Said all that, for product (EAP) there is usually different set of service scripts that come with platform specific natives to make it work.

And most of that we cannot include in upstream for various reasons.  But now we are at debate over some beer