Menu
▾
▴
#281 wrapper.jar is not registered with Restart Manager (Windows Installer / MSI)
Hi,
This is about uninstalling the wrapper service on the Windows Platform when it was installed as part of an MSI.
During the initialization phase of the uninstall the MSI pops up a message warning the user that it encountered locked files (wrapper.jar) and that a reboot will be needed to finish the uninstall process. During the execute phase of the uninstall the wrapper service will be stopped and after that the wrapper.jar not be locked anymore. So in the end the MSI is able to delete all files and does not need a reboot. But the warning message should have never be shown.
What I think happens (theory) is that the wrapper.exe does not register itself with the restart manager or does not register the wrapper.jar as an additional resources with it.
So during initialization when the Restart Manager looks for locked files, it sees the wrapper.jar being locked, but doesn't know it's held by the service. Therefore it brings up the message about the necessary reboot.
It would be great if this could be fixed in the service.
Thanks,
Sandra
Related
Sandra,
Do you have a test program which we can use to easily reproduce this?
We will look into it on our end as well, but I want to make sure we are seeing the same problem.
Cheers,
Leif
Sandra,
I need to figure out how the RestartManager API works, but it looks like there is a "Session" which defines all the file used by an application. You are wanting to register all of the dependent files used by the Wrapper within that session. Is that correct? It looks like this is done using the RmRegisterResources function.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa373663%28v=vs.85%29.aspx
I am not clear on whether the Wrapper would start its own session, or whether you will want to call the Wrapper with a session handle as an argument and then ask the Wrapper to register all of its files.
The scope of which files you need to add the session is also quite broad with the Wrapper and it will only be possible for us to handle this part way for a given wrapper.conf file. We know that the Wrapper will lock the wrapper.exe, wrapper.dll, and wrapper.jar files, as well as any pid, lock, and log files that the Wrapper generates. But the Wrapper will also launch a JVM and thus all files related to that will also be locked indirectly by the Wrapper.
We will be able to register any jar files mentioned directly within the wrapper.conf on the classpath. But many applications also load and thus lock secondary jar files whose classpaths are defined elsewhere. It is not going to be possible for us to track those down without actually starting the application.
Please let me know your thoughts as far as your knowledge on this subject goes.
Cheers,
Leif
The full API is here:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa373649%28v=vs.85%29.aspx
The home is here:
http://msdn.microsoft.com/en-us/library/windows/desktop/cc948910%28v=vs.85%29.aspx
Hi Leif,
First off, thanks for looking into this already. That's awesome support!
I'm an Install Engineer and not experienced with the integration of
RestartManager awareness on the application side, but what I thought has to
happens on a high level is this:
At initialization time of an Install/Uninstall the MSI looks at all the
files it has to install and checks if any of them are locked. If it finds a
locked one, it asks the Restart Manager if it is registered. If yes, it
knows it will be able to shut this app/service down later in the Execute
sequence. If it finds a file that is locked and needs to be updated, but is
not registered, it does not know how to remove the lock and therefore tells
the user that a reboot will be necessary later on.
This is where we run into the problem with the wrapper.jar and get the
prompt from the MSI.
To get into a little more detail, but don’t take it for granted since I did
not have to implement any of this yet, it’s just my guess on what has to
happen
App side:
RegisterApplicationRestart(..)
using RmRegisterResources(..)
wm_endsession ?)
Installer side: (this is all taken care of by the MSI engine, no additional
code on my side necessary)
installed/updated
RmGetList (?)
Hope this sheds a bit more light on this problem. And please take it with a
grain of salt, this is just how I understood the whole thing has to work. I
don’t know for sure.
If you have something to test, I’m happy to help. And to your question,
entries for extra jars in the wrapper.conf would work fine for me.
Sandra
On Wed, Aug 28, 2013 at 3:30 AM, Leif Mortenson mortenson@users.sf.netwrote:
Related
Bugs: #281
I am having the same problem as Sandra. From what I have found so far, all this information appears to be more or less correct.
Restart Manager will look at the Component table and check the Key Path File. If this is locked by a service and that service is in the ServiceControl table with that Component then it will know that the service will be stopped and the lock will be released.
As Leif pointed out the problem is that the service in this case will start the JVM. It is the JVM that has a lock on certain files. Since the JVM will not be in the ServiceControl table Restart Manager will not be aware of this transitive dependency. The MSI logs will show:
I'm yet to find out how to do this correctly with MSI. The only workaround seem to be adding a custom action prior to InstallValidate which will stop the service.