I am using cloudify 2.7, the byon.xml config jdk is 1.6 bin, but now, my application need jdk 1.7, so I want to download jdk 1.7 bin version, but I did not find it, so I config jdk 1.7 gz and tar version in byon.xml, but cloudify agent can not install it.
I read cloudify document write:
/*
The following optional attribute contains the path from which the JDK will be downloaded. Default Linux values are : 32 bit
http: //repository.cloudifysource.org/com/oracle/java/1.6.0_32/jdk-6u32-linux-i586.bin 64 bit
http: //repository.cloudifysource.org/com/oracle/java/1.6.0_32/jdk-6u32-linux-x64.bin
But you can set it manually as follows :
(If you want to rely on the pre-installed JDK, set javaUrl to "NO_INSTALL")
*/
javaUrl "http: //my-pc:8080/java.bin"
so my question is how can I use cloudify pre-install jdk 1.7?
Cloudify uses Oracle JDK 6, though it should work using any compatible JDK.
As this is the JDK that Cloudify was tested with, I recommend that you keep using JDK 6 to run Cloudify, and install JDK 1.7 separately for your application. Cloudify does not install JDK 6 at the system level - it is not installed as a system package (like apt or yum) - it is just a tar/zip that is uncompressed. So you can simply have a preInstall lifecycle script that installs JDK 7, either at the system level or the user level.
Once JDK 7 is installed, you will probably need to edit your start script to add the JAVA_HOME environment variable and add the bin directory of JDK 7 to the PATH environment variable. This will not interfere with Cloudify's agent.
Related
I am trying to configure qt 5.6 on my ARM based NVIDIA Jetson Tk1 to use gstreamer version 1.6, which is located and installed in a folder:
/home/luca/gst_1.6
What I did was modify was the LD_LIBRARY_PATH and PATH variables to point to the /lib and /bin directories respectively of my installation folder.
However, the configuration script picks the system installed gstreamer (version 1.0) rather than the 1.6 version. How may I specify the script as to which gstreamer to pick?
I have searched all day in order to use Qt 5.4 or Qt 5.5.
I have two machines, one running Ubuntu 15 and the other Ubuntu 14, but got the same results.
I have installed the program through the download-online package, and now I have beautiful /opt/Qt/5.4/ and /opt/Qt/5.5 folders.
That's all. I am stuck in here. If I run qmake -version, the reply is:
Using Qt version 5.2.1 in /usr/lib/x86_64-linux-gnu
Also, if I run qtchooser -list-versions, I get:
4
5
default
qt4-x86_64 linux-gnu
qt4
qt5-x86_64 linux-gnu
qt5
I have to use SuperCollider 3.7 for an important project, and I need Q t5.4 or higher. Is there anybody who can tell me what to do after installing the package to make programs see Qt 5.4 or higher?
I even tried to build from the source code, but in that case init-repository doesn't work.
Luca
I have had the same problem different times, therefore my late answer.
You should create the file /etc/xdg/qtchooser/default.conf, and put the path to the bin and lib directory, for example:
/opt/Qt/5.5/gcc_64/bin
/opt/Qt/5.5/gcc_64/lib
Now this is the default configuration, and it is shown with qtchooser -l as such.
See man qtchooser:
/etc/xdg/qtchooser/*.conf
System-wide configuration files. Each has two lines, the first is the path to the binaries and the second is the path to the
Qt libraries. If a default.conf is provided, the settings from it will be automatically used in case nothing else is selected.
Launch any version of Qt Creator. It can be either the old one from previous install or the newer one.
Go to Projects/Manager Kits and add kits in which you are interested (Qt 5.4, 5.5 or the one which is install by default)
Open any project, code and build with any of the specified kits.
As I was digging in the right way to change the default choice for qt session in my old ubuntu 14.04 LTS, I did find this old topic as best match for my own question.
So here my answer for any 14.04 living in 2019 : the default package qmake point on qtchooser, which looks for its conf in /usr/lib/x86_64-linux-gnu/qt* directories
The default conf is in /usr/lib/x86_64-linux-gnu/qt-default/ .
If you haven't this, look at your "qtchooser -print-env" result to see what's your own path. I think that a good practice to set this as system default should be to create a link from the xdg default to your ubuntu standard default (as it works for me) :
sudo mkdir -p /etc/xdg/qtchooser/
cd /etc/xdg/qtchooser/
ln -s /usr/lib/x86_64-linux-gnu/qt-default/qtchooser/default.conf default.conf
As far I can see, there's no more things as "Managers Kits" in qtcreator
i have a folder with an old plone version 2.5 and i would restore it on mac os mavericks or ubuntu 12.04. I know, that this really old plone version need python 2.4. I get it form python.org for mac os x but i don't found anything for ubuntu 12.04. I tried to restore this dump but it's not easy without a good documentation for version 2.5.
How can i restore this dump?
Start with an installer from https://launchpad.net/plone/2.5/2.5.5 . That will take care of not only Python, but also handle other binary components.
Install Plone on the target server, then transfer any custom add-on Plone products from the source server. Test it.
When that's running, copy the Data.fs file from the source to overwrite the Data.fs on the target.
My development team recently was forced over to a remote development environment where we do not have full access to the servers. Before the change over we had a JAR that was running fine on Java 1.7 x64 along with JRE 7. When we moved over to the new server our JAR was running alright, but then one of the server admins "updated" our Java to an older version and uninstalled the one we were using. Don't ask me why, I don't know. I re-installed Java 1.7 and uninstalled 1.6 along with the JREs.
The following problem occurs at runtime, there are no build errors:
Registry key 'Software\JavaSoft\Java Runtime Environment\CurrentVersion'
has value '1.7', but '1.6' is required.
Error: could not find java.dll
Error: could not find Java SE Runtime Environment.
I've run the same JAR on my laptop with no issues. Both the server and my laptop have JDK 1.7 and JRE 7 in the respective %HOME% variables and system PATH. I've even reinstalled JRE 6 and placed it later in the system environment PATH variables with the same result.
I have also changed the registry back to look at 1.6 and it results in the following, which I looked up and it appears to be from having multiple Javas installed (leading back to my original problem):
Exception in thread "main" java.lang.UnsupportedClassVersionError: ... :
Unsupported major.minor version 51.0
I would appreciate any insight you all have as I have been looking over various forums but nothing seems to have exactly my problem. Also, this has happen on another server we are using as well. Thanks!
Update: No luck with recompiling the JAR to either 1.6 or 1.7 and matching the JDK. Also, why in the world would a newer version of Java break an older compiled version?
This happens when you somehow confused java itself. You are trying to run a java 6 VM where it found a JRE 7. It might show this problem even if you type in the command line just java or java -version in a misconfigured environment. The JAR is not the problem, except in the very unlikely case where the code in JAR is looking in the Windows Registry for that (which probably is not your case).
In my case, I had the java.exe, javaw.exe and javaws.exe from Java 6 in the Windows/System32 folder (don't know how it got to be there). The rest of the JDK and JRE where found in the PATH inside C:\Java\jdk_1.7.0\bin. Oops!
Just had the similar error when installing java 8 (jdk & jre) on a system already running Java 7.
Error: Registry key 'Software\JavaSoft\Java Runtime
Environment'\CurrentVersion' has value '1.8', but '1.7' is required.
Error: could not find java.dll Error: Could not find Java SE Runtime Environment.
My environment was set up correctly (Path & java_home correctly defined), but the problem arises from the way pre-8 Java installers worked, which is that they used to copy the three executables (java.exe, javaw.exe & javaws.exe) to the Windows system directory. These remain unless overwritten by a new pre-8 installation.
However the Java 8 installer instead creates symbolic links in a new directory, C:\ProgramData\Oracle\Java\javapath, pointing to the actual JRE 8 location.
This means that you'll actually run the old 7 exes but use the new 8 DLLs.
So, the solution is simply to delete the 3 Java exes, as above, from the windows system directory.
If you are running 32-bit Java on a 64-bit Windows, the exes would be in Windows\SysWOW64, otherwise in Windows\System32.
I've deleted java files at windows/system32 and I also have removed c:\ProgramData\Oracle\Java\javapath from the PATH variable, because there was 3 symlinks to java 1.8 files.
I had JDK 1.7 in the %JAVA_HOME% variable and java1.7/bin in the PATH.
PS1: My problem was between Java 1.7 and Java 1.8.
PS2: I can't add this as a comment to Victor's answer because I haven't enough points.
In the START menu type "regedit" to open the Registry editor
Go to "HKEY_LOCAL_MACHINE" on the left-hand side registry explorer/tree menu
Click "SOFTWARE" within the "HKEY_LOCAL_MACHINE" registries
Click "JavaSoft" within the "SOFTWARE" registries
Click "Java Runtime Environment" within the "JavaSoft" list of registries here you can see different versions of installed java
Click "Java Runtime Environment"- On right hand side you will get 4-5 rows . Please select "CurrentVersion" and right Click( select modify option) Change version to "1.7"
Now the magic has been completed
I don't know if anyone is still following this thread, but I recently had this issue when I tried to launch ActiveMQ 5.10 as a Windows service.
I didn't have a JAVA_HOME path set.
I had Java 6 and Java 7 installed, but the default version was v7. (ie if I opened a command window and types "java -version").
This is where the clue was - "java -version" returned "Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)" but I was had installed the Win32 service...
It turns out that if you use the Win32 wrapper on a 64-bit machine it somehow decides to use a different version of Java...
So my fix was to uninstall the 32-bit version of the wrapper and install the 64-bit version.
aversion on my machine; just habit I guess... But luckily I resolved the issue eventually...
For my Win7
Paradox was in being java.exe and javaw.exe in System32 folder.
Opening that folder I couldn't see them but using search in Start menu I get links to those files, removed them. Next searsh gave me links to files from JAVA_HOME
magic )
Change to directory with correct java.exe i.e. go to the required JDK version java.exe
cd C:/Program Files/Java/jdk1.7.0_25/bin
Run the java.exe from this directory, it has precedence over registry and $PATH settings.
java -jar C:/installed/selenium-server-standalone-2.53.0.jar
I solved this problem by uninstalling Java 1.8
The jar was compiled to be 1.6 compliant. That is why you get this error. Two resolutions:
1) Use Java 1.6
OR
2) Recompile the jar to be compliant for your environment 1.7
Using regedit, remove the entries corresponding to java 7. It will work.
How can I set my java jar application to use jre 6 instead of jre 7?
I'm doing this because there are some compatibility issue with the libraries I'm using if the application use jre 7.
Edit:
The application will come with its own installers (using advanced installer) that have a jre6 installer. But I don't know how to trace the installation folder of the jre6.
How can I trace it and make the jar file use the jre6?
You can do this from Advanced Installer much simpler. You have two options:
Force the package to use the JRE 1.6 found on the machine by going to "Virtual Machine" tab from Java Products page and setting the minimum and maximum JRE versions to 1.6
Add as bundle in the project from the same page the JRE for version 1.6. This means that Advanced Installer will automatically import in your package the JRE resources required for your application, thus increases the package size, and will install them in the application's install folder. This JRE bundle will be used only by your application and removed along with it.
When running your application using java.exe, you could provide the absolute path to a Java 1.6 installation. Something like:
absolute_path_to_java6_dir/bin/java -jar yourRunnableJar.jar
or
absolute_path_to_java6_dir/bin/java -cp .;yourJar.jar;otherJarFiles className
You could check the running JVM version when starting your application.
System.getProperty("java.version");
This way you could provide a meaningful explanation to end-user.