Hi Andrew!
I finally had the time to look at this. It seems there is a bug - and a simple workaround.
The bug is that the code path is not at all updated unless the relup contains an instruction for at least one of the application's modules.
The workaround is to use the {update_paths,true} option to release_handler:install_release/2. The documentation for this option says:
"The option {update_paths,Bool} indicates if all application code paths should be updated (Bool==true), or if only code paths for modified applications should be updated (Bool==false, default)."
Since your application is indeed updated, the path should of course have been updated anyway. I will correct this for OTP R14B04.
Regards
/siri
2011/6/20 Siri Hansen
<[hidden email]>
Hi Andrew - thanks for reporting this. I will have a look at it.Regards
siri@otp
Hi,
Code path of application can specify to old location after release upgrade.
It's possible if we change only vsn of application, no erlang code of
modules is changed. (In my case under priv directory I have JavaScript code).
Generated relup doesnt contains instructions for reload application...
no 'load_object_code,{OurApp,NewVsn,Mods}'.
After release upgraded we have:
application:loaded_applications()
....
{OurApp,Description,NewVsn}
....
but
code:priv_dir(OurApp) points to old location.
If relup contains {OurApp,NewVsn,[]} then location of application is correctly updated.
Andrew Gopienko
ThreeLine LLC
erlang-bugs mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-bugs
_______________________________________________
erlang-bugs mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-bugs
Locked
