Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Vuze 5.7.3.0 Installer BUG OS X
#1
Please FIX the following Installer Bug from Vuze for MAC OS X ASAP, it has been if Vuze for already 3 !!!!!! versions BUT wasn't there BEFORE.

When i install Vuze 5.7.3.0 and alse previosly reported 5.7.2.0 & 5.7.1.0, it places an unvisible folder in my /applications/ folder which i see because I have invisible files always visible, .install4j/ it is named. Obviously /Applications/ is not the place for such a folder & the name of the folder suggests it's leftovers from a bad installer. However this folder seems a needed part for Vuze 5.7.1.0 & Up, in previous Vuze applications 5.7.0.0 & Lower this folder was placed in the Vuze.app application itself, a much better location for this folder & it's files. If you do need such a location outside the App this folder name is bad & suggests it's not main files from Vuze but maybe merely needed for auto update features.

So I Cleanup my Applications folder, remove  .install4j/ &  can't open Vuze any more. Vuze is a very tiny 255KB Application.

I also looked in my /library/... folder for a folder containing the Vuze executables & the Java 8 however i can't find any folder containing this, thats because all is in the .install4j/ folder in my /Applications/ folder.


If the contents of .install4j/ is needed by vuze, i think something is wrong. This folder should not exist, even not during install. I think you also added an /applications/Uninstall Vuze.app for this, if you place everything inside /applications/vuze.app/ like before an uninstaller would not be neccesarry, The location of an uninstaller should be on the diskimage (dmg) together with the installer, you unnessecarry clutter the /applications/ folder.

I suggest the contents of .install4j/ should be either;
-Inside /Applications/vuze.app/ (like before)
or

-In a folder named /Lbrary/Application Support/Vuze/

Deffinetly NOT in an hidden folder, deffinetly NOT inside /Applications/ unless inside /Applications/Vuze.app/

I hope this will be looked at & fixed asap. I planned stopping use Vuze until further notice But found a solution myself. 


My Solution:

!!!!!!!!!! However My Solution tends to fail atm so i stopped using Vuze !!!!!!!!!

Install Vuze 5.7.0.0 - this version still installs correctly, all file's are inside the Vuze.app bundle
Let this update to 5.7.1.0 but not to 5.7.2.0 & Up since install procedure change.
Then start moving individual files from the .install4j/ & java.app folders from 5.7.3.0 to 5.7.1.0 to manually update this.I have to mention to not move the Plist files but rather manually edit changes in the original.

Edited the plist file so the Vuze version shown in Finder is 5.7.3.0 Not 5.7.0.0
This should be a complete update, but ismall changes might still exist in the plist & other text files.
I now should have a working copy of Vuze 5.7.3.0 in my /Applications but it still thinks it's version 5.7.10 & still wants to update.

!!!!!!!!!! However My Solution tends to fail atm so i stopped using Vuze !!!!!!!!!


Now i should be able to run Vuze 5.7.3.0 without the installer mess that has no reason to be, i also proof this with my solution. Why did you make such a mess while you only needed to update your working installer from Vuze 5.7.0.0 ??????

!!!!!!!!!! However My Solution tends to fail atm so i stopped using Vuze !!!!!!!!!

My solution is not for the random user, my luck is that i am somewhere between the random & the power user & was able to do this but what i did was delve into places where no normal user should come. Therefor the User need a good installer from you, not a difficult solution from me.

!!!!!!!!!! However My Solution tends to fail atm so i stopped using Vuze !!!!!!!!!
Reply
#2
I would really like to know if this bug is accepted & being worked on.

I really feel the current situation is unacceptable & I have proposed several solutions;

- Return to previous situation where the file's are installed within the Vuze.app bundle which is placed in the user selected location during install & has a default location in /Applications/ - BEST SULUTION -

- Place the folder inside /library/Application Support/Vuze/ or /library/vuze/ & keep it visual instead of hidden.

- Do a bit of both of the above, place the files needed to run Vuze & not 3th party inside Vuze.app, Place the Java bundle in /Library/Application Support/ or in /library/Java/JavaVirtualMachines/ & name it correctly ( jre-x.y.z.jre See Oracle.com Mac Java JRE-JDK downloads)

Please answer this, Developers
Reply
#3
There's very little we can do about it. Our install builder, Install4j, decides where to put the Java runtime. For whatever reason, Install4j will not install a system-wide JRE in the usual place (ie /usr/bin/java). I believe it doesn't place it in the Vuze.app because that would invalidate the signature of the app (since the java component is sometimes downloaded on demand and can change). Apps with invalid signatures usually get removed from the firewall and often pop up warnings about the App not being safe :(

We do have an option to build an installer that will use the existing system-wide Java. We don't usually provide these, since we can't guarantee a random user will have Java already on their Mac, or if they have the recommended minimum version. Here's the installer if you wish to try it

http://cf1.vuze.com/installers/Vuze_Inst...emJava.dmg

-Tux


(07-28-2016, 10:02 AM)albert2 Wrote: I would really like to know if this bug is accepted & being worked on.

I really feel the current situation is unacceptable & I have proposed several solutions;

- Return to previous situation where the file's are installed within the Vuze.app bundle which is placed in the user selected location during install & has a default location in /Applications/ - BEST SULUTION -

- Place the folder inside /library/Application Support/Vuze/ or /library/vuze/ & keep it visual instead of hidden.

- Do a bit of both of the above, place the files needed to run Vuze & not 3th party inside Vuze.app, Place the Java bundle in /Library/Application Support/ or in /library/Java/JavaVirtualMachines/ & name it correctly ( jre-x.y.z.jre See Oracle.com Mac Java JRE-JDK downloads)

Please answer this, Developers
Reply
#4
Hello Arron,

First of all i like to thank you for the responds you made.

I'm sorry to hrar however that this cant be solved since it's Install4j, your install builder, which you must have updated betwwen building Vuze 5.7.0.0 & 5.7.1.0 since the first still makes a Vuze.app bundle that includes all files & the later places files in the hidden folder or as i found out lately in /Users/Shared/Library/ApplicationSupport/Vuze/... when you select to install Vuze.app in another location then the /Applications/ folder ( i tried /Users/Me/Desktop/Vuze/ )

 I know why install4j wont install a system-wide JRE in the usual *nix place (ie /usr/bin/java). It's because this location is since OS X 10.10 not writable anymore because the new feature System Integrity Protection. See https://support.apple.com/en-us/HT204899 or https://en.wikipedia.org/wiki/System_Int...Protection for indept information. However you still should have some options available, /usr/local/... , /library/... & ofcourse /Applications/... 

I think the best solution is like i said before to find an option for install4j to place the files in /Library/Application Support/Vuze/... & maybe the JRE itself in /Library/Java/JavaVirtualMachines/ . If you will keep placing them in /Applications/ i still strongly appose against a hidden folder & believe this folder should not be named "install4j" but has an informational name like "VuzeFiles" , "VuzeSupport" or "VuzeReqFiles", etc., if the filename starts with "Vuze...." it will alse be convinencely placed next to Vuze.app in the Finder.

I had no trouble with the firewall & Aple's Gatekeeper feature, see https://support.apple.com/en-us/HT202491 or https://en.wikipedia.org/wiki/Gatekeeper_(OS_X) , which is the feature in OS X, since 10.8 i think, that checkes for Developer & Application signatures & refuses to run invalid signed or not signed Applications. However you can choose to overrule this feature by ctrl-clicking the application & selecting Open from the menu, i can't recall if i did this for Vuze or not so i might have done this as early as with Vuze 5.0.x.x or even earlier. So Vuze 5.6.x.x & 5.7.0.0 was running fine on OS X 10.10 with both security feature's from Apple enabled & i cannot see why Install4j suddently needed to change the lcations of some of the files. 

Besides that there are also other files that a prune to be updated automaticly without Vuze itself actualy be updated which are the 3 internaly placed plugins, ofcourse the Vuze jar file, but this has been placed outside vuze already & the JRE as you already mentioned, but if i recall corectly the plugins are still placed in the Vuze.app bundle.

Some more about the Java JRE; As you mentioned you cant put Java in /usr/bin/java/ which is the default *nix location but OS X has an alternative place for Java (as it has always had since OS X 10.0, until OS X 10.5 or 6 this has always been /system/library/java/... ), which is /library/Java/JvaVirtualMachines/ . However i found it very difficult to use wih the Oracle provided installers. Oracle provides 2 JRE installers & 1 JDK installer for OS X, most users will go for the JRE installer which is an Instaler Package Bundle & distributed in a DMG package, this installs the JRE in the non default location /library/Internet Plug-ins/JavaAppletplugin.plugin bundle & has it's own updating system however is not system widely recognized, however using the right Java starter Application it is useable by Java Apps like Vuze (So the installer you provide me might be able to use this). However the other 2 installers provided by Oracle which are for the JRE.tar.gz archive & for the JDK again a DMG containing a installer Package, only the last one is able to install a system wide recognized Java which is the JDK. This is something Oracle should change since here there are several problems; Why does Oracle provide a JDK installer package & a JRE Archive insstead of an installer package for the non plugin based JRE & the filename of this systemwide JDK/JRE should in my opinion change to not include the version number & i'd prefere it to be just liks to the Java installed in the plugin which has an update system; The problem however is that the System OS X should be told during install about this JDK/JRE system wide location, Oracle included a CLI command for this which is in the installer package & doesn't get installed, "tools" , it gets executed by the installer postflight script, i was unable to find the right parameters to use it myself. This is something Oracle should fix.

I hope this was informational for you. I will have a look at the provided installer that use the systemwide Java & i still hope you might provide a better installer to the general public in upcomming releases. 
(07-28-2016, 10:47 AM)'ArronM' Wrote: There's very little we can do about it. Our install builder, Install4j, decides where to put the Java runtime. For whatever reason, Install4j will not install a system-wide JRE in the usual place (ie /usr/bin/java). I believe it doesn't place it in the Vuze.app because that would invalidate the signature of the app (since the java component is sometimes downloaded on demand and can change). Apps with invalid signatures usually get removed from the firewall and often pop up warnings about the App not being safe :(

We do have an option to build an installer that will use the existing system-wide Java. We don't usually provide these, since we can't guarantee a random user will have Java already on their Mac, or if they have the recommended minimum version. Here's the installer if you wish to try it

http://cf1.vuze.com/installers/Vuze_Inst...emJava.dmg

-Tux


(07-28-2016, 10:02 AM)'albert2' Wrote: I would really like to know if this bug is accepted & being worked on.

I really feel the current situation is unacceptable & I have proposed several solutions;

- Return to previous situation where the file's are installed within the Vuze.app bundle which is placed in the user selected location during install & has a default location in /Applications/ - BEST SULUTION -

- Place the folder inside /library/Application Support/Vuze/ or /library/vuze/ & keep it visual instead of hidden.

- Do a bit of both of the above, place the files needed to run Vuze & not 3th party inside Vuze.app, Place the Java bundle in /Library/Application Support/ or in /library/Java/JavaVirtualMachines/ & name it correctly ( jre-x.y.z.jre See Oracle.com Mac Java JRE-JDK downloads)

Please answer this, Developers

 
Reply
#5
Hello Again Arron,

I tried the installer for Vuze that will use the system wide Java installer.

However this installer has a bug.

An error occurred:
java.lang.UnsatisfiedLinkError: cm.install4j.installer.platform.win32.Registry.getValue0(ILjava/lang/String;I)java/lang/Object;

Error Log file:

Exception:

In action "LeapCheck [Run script]" (screen "Startup"), property "Script":
java.lang.UnsatisfiedLinkError: com.install4j.runtime.installer.platform.win32.Registry.getValue0(ILjava/lang/String;Ljava/lang/String;I)Ljava/lang/Object;
at com.install4j.runtime.installer.platform.win32.Registry.getValue0(Native Method)
at com.install4j.runtime.installer.platform.win32.Registry.getValue(Registry.java:64)
at com.install4j.api.windows.WinRegistry.getValue(WinRegistry.java:197)
at com.install4j.api.windows.WinRegistry.getValue(WinRegistry.java:53)
at com.vuze.install4j.InstallUtil.getHKCUorHKLM(InstallUtil.java:2383)
at com.vuze.install4j.InstallUtil.regAnyKeyExists(InstallUtil.java:2342)
at com.vuze.install4j.InstallUtil.regKeyExists(InstallUtil.java:2334)
at com.vuze.install4j.InstallUtil.hasUninstallRegistry(InstallUtil.java:2395)
at com.install4j.script.I4jScript_Internal_12.eval(I4jScript_Internal_12.java:2)
at com.install4j.script.I4jScript_Internal_12.evaluate(I4jScript_Internal_12.java:*28)
at com.install4j.runtime.installer.helper.Script.evaluate(Script.java:33)
at com.install4j.runtime.installer.ContextImpl.runScript(ContextImpl.java:188)
at com.install4j.runtime.installer.ContextImpl.runScript(ContextImpl.java:182)
at com.install4j.runtime.beans.actions.control.RunScriptAction.execute(RunScriptAction.java:34)
at com.install4j.runtime.beans.actions.SystemInstallOrUninstallAction.install(SystemInstallOrUninstallAction.java:29)
at com.install4j.runtime.installer.ContextImpl$7.executeAction(ContextImpl.java:1668)
at com.install4j.runtime.installer.ContextImpl$7.fetchValue(ContextImpl.java:1659)
at com.install4j.runtime.installer.ContextImpl$7.fetchValue(ContextImpl.java:1656)
at com.install4j.runtime.installer.helper.comm.actions.FetchObjectAction.execute(FetchObjectAction.java:14)
at com.install4j.runtime.installer.helper.comm.HelperCommunication.executeActionDirect(HelperCommunication.java:272)
at com.install4j.runtime.installer.helper.comm.HelperCommunication.executeActionInt(HelperCommunication.java:247)
at com.install4j.runtime.installer.helper.comm.HelperCommunication.executeActionChecked(HelperCommunication.java:185)
at com.install4j.runtime.installer.helper.comm.HelperCommunication.fetchObjectChecked(HelperCommunication.java:168)
at com.install4j.runtime.installer.ContextImpl.performActionIntStatic(ContextImpl.java:1656)
at com.install4j.runtime.installer.InstallerContextImpl.performActionInt(InstallerContextImpl.java:151)
at com.install4j.runtime.installer.ContextImpl.performAction(ContextImpl.java:1103)
at com.install4j.runtime.installer.controller.Controller.executeAction(Controller.java:367)
at com.install4j.runtime.installer.controller.Controller.executeActions(Controller.java:333)
at com.install4j.runtime.installer.controller.Controller.handleCommand(Controller.java:194)
at com.install4j.runtime.installer.controller.Controller.handleStartup(Controller.java:116)
at com.install4j.runtime.installer.controller.Controller.start(Controller.java:73)
at com.install4j.runtime.installer.Installer.runInProcess(Installer.java:59)
at com.install4j.runtime.installer.Installer.main(Installer.java:46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.exe4j.runtime.LauncherEngine.launch(LauncherEngine.java:65)
at com.install4j.runtime.launcher.MacLauncher.main(MacLauncher.java:67)

System properties:

java.runtime.name=Java™ SE Runtime Environment
exe4j.moduleName=/Volumes/Vuze 5.7.2.0 Installer/Vuze Installer.app
sun.boot.library.path=/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib
java.vm.version=25.101-b13
i4j.jreBundle=/Library/Internet Plug-Ins/JavaAppletPlugin.plugin
gopherProxySet=false
java.vm.vendor=Oracle Corporation
java.vendor.url=http://java.oracle.com/
path.separator=:
java.vm.name=Java HotSpot™ 64-Bit Server VM
file.encoding.pkg=sun.io
user.country=BE
sun.java.launcher=SUN_STANDARD
sun.os.patch.level=unknown
install4j.exeDir=/Volumes/Vuze 5.7.2.0 Installer/
java.vm.specification.name=Java Virtual Machine Specification
user.dir=/Volumes/Vuze 5.7.2.0 Installer/Vuze Installer.app/Contents/Resources/app
java.runtime.version=1.8.0_101-b13
jdk.lang.Process.launchMechanism=POSIX_SPAWN
i4j.ownBundlePath=/Volumes/Vuze 5.7.2.0 Installer/Vuze Installer.app
java.awt.graphicsenv=sun.awt.CGraphicsEnvironment
java.endorsed.dirs=/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/endorsed
os.arch=x86_64
java.io.tmpdir=/var/folders/dv/f2wn_ffx5hbf3skdw56xkd080000gn/T/
line.separator=

java.vm.specification.vendor=Oracle Corporation
os.name=Mac OS X
sun.java2d.noddraw=true
sun.jnu.encoding=UTF-8
java.library.path=/Users/Me/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.
sun.awt.enableExtraMouseButtons=true
java.specification.name=Java Platform API Specification
java.class.version=52.0
sun.management.compiler=HotSpot 64-Bit Tiered Compilers
os.version=10.11.6
http.nonProxyHosts=local|*.local|169.254/16|*.169.254/16
user.home=/Users/Me
user.timezone=Europe/Brussels
java.awt.printerjob=sun.lwawt.macosx.CPrinterJob
file.encoding=UTF-8
java.specification.version=1.8
java.class.path=/Volumes/Vuze 5.7.2.0 Installer/Vuze Installer.app/Contents/Resources/app/i4jruntime.jar
user.name=dannyvancamp
java.vm.specification.version=1.8
sun.java.command=com.install4j.runtime.launcher.MacLauncher
java.home=/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home
sun.arch.data.model=64
user.language=nl
java.specification.vendor=Oracle Corporation
awt.toolkit=sun.lwawt.macosx.LWCToolkit
java.vm.info=mixed mode
java.version=1.8.0_101
java.ext.dirs=/Users/Me/Library/Java/Extensions:/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/ext:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java
sun.boot.class.path=/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/resources.jar:/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/rt.jar:/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/sunrsasign.jar:/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/jsse.jar:/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/jce.jar:/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/charsets.jar:/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/jfr.jar:/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/classes
install4j.appDir=/Volumes/Vuze 5.7.2.0 Installer/Vuze Installer.app/Contents/Resources/
java.vendor=Oracle Corporation
file.separator=/
java.vendor.url.bug=http://bugreport.sun.com/bugreport/
sun.font.fontmanager=sun.font.CFontManager
sun.io.unicode.encoding=UnicodeBig
sun.cpu.endian=little
install4j.systemLanguage=nl
socksNonProxyHosts=local|*.local|169.254/16|*.169.254/16
http://ftp.nonProxyHosts=local|*.local|1...169.254/16
sun.cpu.isalist=
Reply
#6
Post Updated for Vuze 5.7.3.0 which still has a bad installation procedure on OS X
Reply
#7
(07-28-2016, 10:47 AM)'ArronM' Wrote: There's very little we can do about it. Our install builder, Install4j, decides where to put the Java runtime. For whatever reason, Install4j will not install a system-wide JRE in the usual place (ie /usr/bin/java). I believe it doesn't place it in the Vuze.app because that would invalidate the signature of the app (since the java component is sometimes downloaded on demand and can change). Apps with invalid signatures usually get removed from the firewall and often pop up warnings about the App not being safe :(

We do have an option to build an installer that will use the existing system-wide Java. We don't usually provide these, since we can't guarantee a random user will have Java already on their Mac, or if they have the recommended minimum version. Here's the installer if you wish to try it

http://cf1.vuze.com/installers/Vuze_Inst...emJava.dmg

 

This installer worked fine on macOS 10.11.6 with JRE 1.8 installed in the system, without installing another copy of the environment in the /Applications/.install4j folder. It installs Vuze 5.7.2.0 correctly and it even updates to 5.7.3.0 without any issue. However, if I update to 5.7.4.0 from the app, the installer rebuilds the .install4j directoty and ignores again the JRE system install. 

Can you please provide an installer for Vuze 5.7.4.0 that uses the system version of Java? If you could put a link for these installers on the wiki, for experts that do not want to have multiple copies of the JRE on their system, that would be great. 

Thanks for your assistance,
Alberto
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  BUG: Search For Existing Files... deletes matches! (DATA LOSS) FeRDNYC 0 470 06-20-2017, 10:30 PM
Last Post: FeRDNYC
  Force Re-Check 99.9% Bug itseeu 1 557 03-20-2017, 06:05 PM
Last Post: ekstasee



Users browsing this thread: 1 Guest(s)