quick question; is it possible and reasonable to run different Artemis ActiveMQ versions with different JDK versions?
There are currently two separate Artemis-Services on my VM running different Artemis versions (2.4.0 not cool, I know :/ and 2.16.0).
Now I want to upgrade the 2.16.0 to 2.21.0 which would mean, that I also need a new JDK version. The problem is I still have to provide a customer with the 2.4.0 version.
Can I run the 2.21.0 with JDK 17 and the 2.4.0 still with JDK 8?
The Java-Version seems to be referenced in the artemis-service.xml as %JAVA_HOME% which is a windows environment variable and outputs either JDK 17 or JDK 8.
Could I just switch this variable to a local env, similar to ARTEMIS_INSTANCE in the artemis-service.xml or is this not an intended use?
So the new artemis-service.xml would look something like this:
...
<env name="ARTEMIS_INSTANCE_ETC_URI" value="file:/C:/ApacheMQ/BROKER/etc/"/>
<env name="ARTEMIS_DATA_DIR" value="C:\ApacheMQ\BROKER\data"/>
<env name="JAVA_V17" value="C:\PATH_TO_JDK_17"/>
<logpath>C:\ApacheMQ\BROKER\log</logpath>
<logmode>roll</logmode>
<executable>%JAVA_V17%\bin\java.exe</executable>
...
Obviously one of the JDK versions wouldn't be properly installed but just residing in a folder.
Yes, I know this is more of a dirty workaround, but would it be an option in principle?
Your solution will works, an alternative could be to use the full path to define the executable element, i.e.
<executable>C:\PATH_TO_JDK_17\bin\java.exe</executable>
Related
I am trying to build some source code on ubuntu 16.04 where one of the classes relies hierarchy_simplify_point_set.h header file, which is part of CGAL's point set package. After following instruction on the installation page, I have installed libcgal-dev and libcgal-qt5-dev via apt-get. The package manager has installed libcgal-dev 4.7 which should include the point set library. However, the particular header file seems to be missing (it seems to have some files from the point set library and not others - I am looking in /usr/include/CGAL). Does anyone know what I am doing wrong?
ps: For good measure, I have already tried uninstalling and reinstalling both the packages, but no luck.
This header has been introduced in CGAL 4.8 while it seems you are using CGAL 4.7.
You can get the latest version of CGAL here. Since the latest versions can be used as a header-only library, simply extract the release archive somewhere and set CGAL_DIR to that location when calling cmake to configure your example and it should work directly.
I searched this forum already, no working answer is found for my case:
I installed java 1.8
I downloaded the binary version of zookeeper-3.5.5 from https://www.apache.org/dist/zookeeper/zookeeper-3.5.5/apache-zookeeper-3.5.5-bin.tar.gz
I changed the zoo_sample.cfg to zoo.cfg, no changes made to the cfg
I tried to start zookeeper as root:
[root#pocdnr1n1 apache-zookeeper-3.5.5-bin]# bin/zkServer.sh start conf/zoo.cfg
I received error in log:
Could not find the main class: org.apache.zookeeper.server.quorum.QuorumPeerMain. Program will exit.
Thanks.
I think I have found the root cause, posting it here for future readers:
The culprit is Java.
I had an old java version on the node, this can be verified by running java -version
In my case the java was 1.6, what I did is to reset the environment to add the new java 1.8 to it:
# export JAVA_HOME=/opt/jdk1.8.0_151
# export JRE_HOME=/opt/jdk1.8.0_151/jre/
# export PATH=$PATH:/opt/jdk1.8.0_151/bin:/opt/jdk1.8.0_151/jre/bin
You should add the PATH to the .bash_profile so that it becomes permanent.
Now after that you run source .bash_profile, now you have set java 1.8 as the default java. again, you can confirm that by running java -version
Run your zookeeper again and it will be started as expected.
The common missings here are:
downloaded the non-binary zookeeper
java is too low (1.6 doesn't work, 1.8 is recommended)
environment should be set to ensure java 1.8 is picked up as default version
I hope this helps.
If you look at ZooKeeper Administrator's Guide - Required Software for 3.5.5 it says:
ZooKeeper runs in Java, release 1.7 or greater (JDK 7 or greater, FreeBSD support requires openjdk7).
which affirms what you found out. Your Java version was too low.
What worked for me was rebuilding with ./gradlew jar -PscalaVersion-2.13.10
I was using kafka straight from source from github.com/apache/kafka and that step was given to me when I cloned a fresh copy of the repo to start from scratch.
I had done a git pull on my old version, so it broke the dependencies, which I forgot I must have at one point installed.
Under Windows 7 x64, when I try to profile an x86 executable with the latest version of Dependency Walker (2.2.6000) the profiling process always hangs at a certain point. Most of the time the last DLL that is loaded is c:\windows\syswow64\URLMON.DLL, so it seems that something inside that DLL is causing a problem. Profiling the same executable on Windows 7 x86 works flawlessly.
I have googled quite extensively, but couldn't come up with a solution to the problem. One suggestion that I found was to uninstall IE 8 or IE 9 and replace it with IE 7, but this doesn't really help. The only effect that I can observe is that with IE 7 the profiling process hangs at a different DLL (iertutil.dll, if I remember correctly, also from the system's syswow64 folder).
So my question is: How can I get Dependency Walker to profile x86 applications on x64 Windows 7? Of course, it would also be nice to know why the problem exists in the first place :-)
Some final notes:
I am using the x86 version of Dependency Walker because I want to profile an x86 executable
Running Dependency Walker as administrator does not help
All profiling options marked as "may fail on WOW64" are disabled
The executable I am currently using as a test case to reproduce the problem is the Sumatra PDF viewer (download link) because it is a simple .exe that does not need installation
Updated instruction based on #Stone Free's comments
The download link you need has changed to:
https://www.microsoft.com/en-us/download/details.aspx?id=42273
Go down to the 2. Install WDK 10 section and select the download:
Locate and run the Wdk setup (wdksetup.exe) from stage 2, then choose the download option rather than install.
Once completed locate and run DownloadLocation\Windows Kits\10\WDK\Installers>"Windows Driver Kit-x86_en-us.msi"
Then you will find Dependency Walker at:
C:\Program Files (x86)\Windows Kits\10\Tools\x64\depends.exe for the 64 bit version
C:\Program Files (x86)\Windows Kits\10\Tools\x86\depends.exe for the 32 bit version
Which is Dependency Walker version 2.2.10011 built 2015-10-29
A handy tool is to use https://github.com/juntalis/depends-launcher which is a simple launcher for Dependency Walker that determines the platform (x86|x64|ia64) of an windows image (dll, exe, etc) and launches the appropriate version of depends.exe to view its dependencies. It's main purpose is for use in a context menu entry to easily view an image's dependencies.
The latest currently known version of Dependency Walker seems to be the 2.2.10011 from 2015-10-29 (links below).
It was deployed with some Windows Development Kit for Windows 10 but the version that it contained is not available anymore from the Microsoft Pages and all the newer Versions does not contain it anymore for unknown reason.
Maybe because also the latest versions have some Problems with the Dynamic-Link Library Redirection or other performance issues. (Using dependency walker under windows 10 seems to be a lot more slow and cumbersome than at previous windows versions - but still great tool for the job)
Following Versions are available:
2.2.10011 (2015-10-29)
unofficial available from this development blog - download at own risk
https://zzz.buzz/2017/05/18/download-dependency-walker/
2.2.9600 (2013-08-22)
available through the WDK 8.1
https://www.microsoft.com/en-us/download/details.aspx?id=42273
after installation present in C:\Program Files (x86)\Windows Kits\10\Tools\[Arch]\depends.exe
2.2.6000 (2006-10-28)
available from official authors website
http://www.dependencywalker.com/
Potential replacement:
For simple tasks the Github project lucasg/Dependencies may be worth to be checked out. But it currently does not support profiling a running app to debug broken runtime dependencies as depends.exe can do.
I've had to switch to using a GitHub project: Dependencies.
As of Windows 10 1809 (10.0.17763) I'm unable to run even depends.exe version 2.2.10011 included in 10.0.10586.0 WDK.
I ran into the same problem and I discovered it is fixed in the latest version of Dependency Walker. I compared 2.2.6000 versus 2.2.8288 and the problem exists in the former but not the latter. However, you will probably have to wait for the Windows 8 WDK to be released to the public in order to get the latest version.
I want my jruby 1.6.1 installation to operate with ruby 1.9 mode only. I want to uninstall or surely disable the support for 1.8.7 because I do not want to pull my hair out if I forget to set the environment or the command line parameter somewhere.
And also! I have another JRuby (1.5.1) installation on my machine which I want to keep there in safety using ruby 1.8.7. I would like to have ruby 1.9 compatibility when (and only when) I choose "c:\opt\jruby-1.6.1" as "Ruby platform" in NetBeans, or I set my PATH to include "c:\opt\jruby-1.6.1\bin", and so on.
All words in one: I want to lock my jruby installation to a ruby version regardless of the environment. Or is there a jruby 1.6.1 installer with ruby 1.9 exclusively? If not, why not? Should I even wish for that?
You can specify the JRUBY_OPTS environment variable: JRUBY_OPTS = --1.9
If you do it in your Windows system environment variables it will always apply anywhere a JRuby executable runs.
If you only add it to your Netbeans project properties then you could have it different depending on which configuration you select. e.g. Don't set it for your JRuby 1.5.1 configuration.
You cannot have it change automatically just by changing your PATH environment variable though.
As asked and answered here, python has a useful way of deployment without installers. Can Java do the same thing?
Is there any way to run Java's jar file without installing jre?
Is there a tool something like java2exe (win32), java2bin (linux) or java2app (mac)?
You can use Launch4j for this. Well documented and easy to use. While the resulting program still needs a JRE to run, you don't have to install the JRE on the target system. You can just copy it with your application and tell Launch4j were to find it or just wrap it up with everything else.
For creating native executables, you can use Excelsion Jet, which compiles Java to native code. We used it for a project at work, and we had to perform zero modification to the original source code (which targetted Sun's JDK).
you can embbed the JRE inside your application and create a setup or installation for your application.
You can have a look at
http://www.bearcave.com/software/java/comp_java.html
You might get it what you want.
You might want to check out how Eclipse does it - it has a native .exe that can use a local (to the installation) JRE.
You might be able to get some luck with GCJ - haven't tried it myself.
You can do it with NetBeans and a couple of tools. The result is a standalone installer that packages everything you need, so your software can run without installing JRE. It is also completely portable, because it install your software on AppData, that is, it does not need privileges to be installed. Maybe you can even configure the installation path, or you can install it on your own PC, locate the folder and copy it to distribute your software in that way.
Check the Answer I made on different post
You can use jlink to create your own customized jre which would contain only those dependencies which are needed for execution. This deployment method is really efficient. please follow **this**link for one such example.