Alain, Temporarily remove the ServiceControl\@Start and install. Then use the service control manager and start. See what errors are reported, diagnose, and tweak the installation. Once your service starts when installed, replace the @Start attribute. I didn't see anything special done when jsl.exe was passed an "install" switch, but I didn't walk the code in a debugger either. If you have spaces in your installation directory path (such as the space between Program and Files) you may need to update your ServiceInstall\@Arguments to be Arguments="-ini "[#fileClientCommModuleJslConfig]"" Blair Murri > From: afor...@cmu.edu > To: jacob.hoo...@greenheck.com; wix-users@lists.sourceforge.net > Date: Thu, 20 Jun 2013 17:09:30 -0400 > Subject: Re: [WiX-users] Uninstall restart issue > > Anyone out there have any ideas about our problem below? > > I'm thinking anyone with experience using WiX or the Windows Installer with > JSL or a Java-based service are best positioned to know how to solve this. > > Alain > > -----Original Message----- > From: Alain Forget [mailto:afor...@cmu.edu] > Sent: June 19, 2013 19:12 > To: 'Hoover, Jacob'; 'General discussion for Windows Installer XML toolset.' > Subject: RE: [WiX-users] Uninstall restart issue > > I've implemented Blair's 2nd suggestion, and the services do seem to get > installed, but I don't think they're being installed correctly, because the > services then cannot start and the installer fails. > > I think the -install argument of jsl.exe does some other special things to > wrap the Java program and install it as a service than the ServiceInstall > does, which is why it worked when I was installing the service using jsl.exe > directly, instead of trying to do it with ServiceInstall. > > Any ideas are welcome, and I can provide any logs you think would help. > Here's a snippet of what my service-related WiX looks like now: > > <Component Id='compClientCommModuleJslConfig' Guid='MYGUID1'> > <File Id='fileClientCommModuleJslConfig' > Name='jsl_ClientCommModuleServiceConfig.ini' DiskId='1' > Source='jsl_ClientCommModuleServiceConfig.ini' KeyPath='yes' /> </Component> > <Component Id='compClientCommModuleJslExe' Guid='MYGUID2'> > <File Id='fileClientCommModuleJslExe' > Name='MyClientCommModuleService.exe' DiskId='1' Source='jsl.exe' > KeyPath='yes' /> > <ServiceInstall > Id="servInstClientCommModule" > Name="MyClientCommModule" > Arguments="-ini [#fileClientCommModuleJslConfig]" > Description="My Client Communication Module" > DisplayName="My Client Communication Module" > ErrorControl="normal" > Start="auto" > Type="ownProcess" > Vital="yes" > > > </ServiceInstall> > <ServiceControl > Id="servClientCommModule" > Name="MyClientCommModule" > Remove="uninstall" > Start="install" > Stop="both" > Wait="yes" > /> > </Component> > > > -----Original Message----- > From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] > Sent: June 19, 2013 16:13 > To: afor...@cmu.edu; 'General discussion for Windows Installer XML toolset.' > Subject: RE: [WiX-users] Uninstall restart issue > > I don't think so, assuming you are having a unique EXE per service. I think > what Blair was saying is the issue of having the same exe name (single > component) in multiple services. I think what you need is a component per > file, with the exe of each of the services (unique copy for each) and their > related ServiceInstall/ServiceControl elements in a component. > > -----Original Message----- > From: Alain Forget [mailto:afor...@cmu.edu] > Sent: Wednesday, June 19, 2013 1:16 PM > To: Hoover, Jacob; 'General discussion for Windows Installer XML toolset.' > Subject: RE: [WiX-users] Uninstall restart issue > > I agree that one file per component is best, but would doing so conflict with > Blair's 2nd solution for registering my services such that the uninstaller > can wait for the StopServices step to release the other files in use before > deciding that a restart is required? > > > -----Original Message----- > From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] > Sent: June 19, 2013 14:10 > To: afor...@cmu.edu; 'General discussion for Windows Installer XML toolset.' > Subject: RE: [WiX-users] Uninstall restart issue > > No, a component can only have one key path, be it a file, directory, or > registry entry. Any time the key file changes, the component will be > serviced. If you have the exe being the key file and it never changes, then > your jar files will never be updated unless you are doing a major upgrade > with REP scheduled early (which in effect removes the old version before > installing the new version). > > Personally I would place each file in its own component, in case you ever > want to do a minor upgrade or patch in the future. > > -----Original Message----- > From: Alain Forget [mailto:afor...@cmu.edu] > Sent: Wednesday, June 19, 2013 12:51 PM > To: Hoover, Jacob; 'General discussion for Windows Installer XML toolset.' > Subject: RE: [WiX-users] Uninstall restart issue > > Oh, I see, so if we make a Component contain multiple files, any time any one > of those files are changed, the installer will uninstall and reinstall the > entire component, and all the files therein (assuming I understand > correctly). This is fine for our purposes, and we are already only doing > MajorUpgrades for simiplicity, so this all sounds good. > > Once I do it, I'll post back to let you know how it turns out. > > > -----Original Message----- > From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] > Sent: June 19, 2013 13:30 > To: afor...@cmu.edu; General discussion for Windows Installer XML toolset. > Subject: RE: [WiX-users] Uninstall restart issue > > One file per component is the most flexible for maintenance, but depending on > your patching/upgrade plan it may not be needed. If the key file to the > component is a 3rd party exe (and all of your jars were within this > component), then you would have to have RemoveExistingProducts scheduled > early, and you could only ever do major upgrades (unless you are going to > recompile their exe after incrementing the version info). > > -----Original Message----- > From: Alain Forget [mailto:afor...@cmu.edu] > Sent: Wednesday, June 19, 2013 12:12 PM > To: 'General discussion for Windows Installer XML toolset.' > Subject: Re: [WiX-users] Uninstall restart issue > > You're quite right; after installing our software, there is a separate > jsl.exe process for each of our services. One disturbing thing I've noticed > is that if I then reboot the computer after installing our software, then > open the Task Manager and press the Show Processes from All Users button, the > Task Manager UI becomes unresponsive, even though it will still update the > visible processes' statuses. Once our software is uninstalled, bringing up > the Task Manager and pressing Show Processes From All Users works fine. Odd > that this does not happen immediately after installing, but before > restarting. But anyway, one problem at a time, in case what we're doing now > will fix it. > > I will try your 2nd suggestion: > > <Component Id="ClientCommModuleService"> > <File KeyFile="yes" Name="ClientCommModuleService.exe" Source="jsl.exe"/> > <ServiceInstall Name="MYCLIENTClientCommModule" Arguments="-ini > [#jsl_ClientCommModuleServiceConfig.ini]" ...> > ... > </ServiceInstall> > <ServiceControl Name="MYCLIENTClientCommModule" Stop="both" .../> > ... > </Component> > > One question: I assume that all the class files used by each service should > still be in their own parent Component (as the tutorials strongly advocate), > or should all files used by a given service be in the the same parent > Component as the service (i.e. be placed at the last "..." in the above code)? > > Alain > > -----Original Message----- > From: Blair Murri [mailto:os...@live.com] > Sent: June 19, 2013 09:08 > To: 'General discussion for Windows Installer XML toolset.' > Subject: Re: [WiX-users] Uninstall restart issue > > I looked at the source code from the jsl website and what they are doing is > installing whichever jsl*.exe binary as the service executable (passing '-ini > <config-file>' as the argument), and loading the java.dll file from the > selected java runtime after parsing the config file, then using jni to > connect the service control manager callbacks and api to the java classes. > > Restart manager (and its predecessor) is going to look at the EXE binary that > was used to start each process holding files of interest. It also checks to > see if each process of interest is a service or not, treating each slightly > differently. > > Windows Installer doesn't easily share the same service binary for multiple > services from different components due to the requirement that the component > defining a service have its keypath be the service binary, which is the > reason I used a pattern of reusing the jsl.exe binary into multiple target > binary files (one for each service). > > Blair > > > From: afor...@cmu.edu > > To: wix-users@lists.sourceforge.net > > Date: Tue, 18 Jun 2013 17:31:25 -0400 > > Subject: Re: [WiX-users] Uninstall restart issue > > > > Hm, interesting. Assuming you are right and this is what's going on, I > > don't think all four services are sharing jsl.exe, because it is only used > > to create (or remove) Java-based services. Wouldn't the exe actually be > > java.exe, because my services are Java programs? If so, I'm not sure how to > > tell if a running java.exe is for our services or some other Java-based > > software. > > > > I am currently travelling, but will look more closely into what the > > services' exe is. As an insanity check, I assume that should be in the Task > > Manager process list, or must it be found elsewhere? > > > > If the exe is java.exe, and not jsl.exe, how do you think that might affect > > your other proposed solutions (which I like, if I can get them to work and > > understand them more fully)? > > > > Alain > > > > -----Original Message----- > > From: Blair Murri [mailto:os...@live.com] > > Sent: June 18, 2013 04:22 > > To: 'General discussion for Windows Installer XML toolset.' > > Subject: Re: [WiX-users] Uninstall restart issue > > > > Restart manager in your situation is probably working something like this: > > > > Look at each component that is being removed Look at each and every > > file in each of those components Look at each and every process > > holding any of those files open? > > Is that process's binary the keypath of any component that contains a > > ServiceConfig that will be stopping that service in this transaction? If > > so, eliminate this process as one that will cause a reboot. > > If there are any processes left over, prompt for user decision (since a > > reboot could happen). > > > > If after actually running the transaction none of the files are still open > > when they are deleted then no actual reboot will be requested (or executed) > > as a result of files-in-use (despite the dialog). > > > > I'm guessing in your case that all four services are sharing one executable > > (jsl.exe) and that executable isn't the keypath of one or more of the > > components supplying the ServiceConfig stop directives. Thus, restart > > manager doesn't find the service(s) and thus doesn't know how the restart > > will be avoided (since none of the processes can use restart manager's > > "freeze dry" method since all of them in your case are services). > > > > To address this one remedy would be to restructure along these lines: > > > > <Component Id="ClientCommModuleService"> > > <File KeyFile="yes" Name="ClientCommModuleService.exe" > > Source="jsl.exe"/> > > <ServiceControl Name="MYCLIENTClientCommModule" Stop="both" .../> > > ... > > </Component> > > <CustomAction Id="cmdInstallClientCommModuleService" .../><!-- > > reference #ClientCommModuleService.exe instead of #jsl.exe in defining this > > CA--> <InstallExecuteSequence> > > <Custom Action="cmdInstallClientCommModuleService" > > ...>$ClientCommModuleService>2</Custom> > > </InstallExecuteSequence> > > > > repeat for each of the remaining three services. > > > > A big problem with using JSL this way is that is that it is a form of > > Self-Reg (and all the evil that entails). A much better (more reliable and > > repeatable) way would be to identify each of the elements from your .ini > > service config files related to service configuration and copy them into > > the appropriate places in the ServiceControl & ServiceInstall (and their > > child elements) along the lines of this: > > > > <Component Id="ClientCommModuleService"> > > <File KeyFile="yes" Name="ClientCommModuleService.exe" > > Source="jsl.exe"/> > > <ServiceInstall Name="MYCLIENTClientCommModule" Arguments="-ini > > [#jsl_ClientCommModuleServiceConfig.ini]" ...> > > ... > > </ServiceInstall> > > <ServiceControl Name="MYCLIENTClientCommModule" Stop="both" .../> > > ... > > </Component> > > > > Even better would be to write a Wix Extension to wrap this second pattern > > and contribute it to the JSL project so they could maintain it (since the > > "-ini" argument (and how that file is parsed) is their implementation > > detail) which would parse the INI file at build time to fill in all the > > service related pieces (that way data is never entered twice). It could > > even select jsl.exe or jsl64.exe automatically based on whether the > > component was 32- or 64-bit, or include the debug version if debug is > > defined, or whatever). > > > > Blair Murri > > > > > > ---------------------------------------------------------------------- > > -------- This SF.net email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > > _______________________________________________ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > ---------------------------------------------------------------------- > > -------- This SF.net email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > > _______________________________________________ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows:
Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
