I'd like to use FXCanvas from the package javafx.embed.swt as shown in this example: http://docs.oracle.com/javafx/2/swt_interoperability/jfxpub-swt_interoperability.htm# But all I can find is javafx.embed.swing package. javafx.embed.swt is simply not existant. What am I doing wrong ? I use java8u5. Is there a special download nessessary or is there a different version of java that contains that package ??
thanks for any hint!
Thorsten
This because the package javafx.embed.swt was moved from the /lib/ext/jfxrt.jar to /lib/jfxswt.jar. You need to add this last explicitly to see the FXCanvas class.
This is the link to the issue: Separate javafx.embed.swt from jfxrt.jar
The JavaFX SWT embedding classes are in the jre/lib directory.
$ java -version
java version "1.8.0_20-ea"
Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b14, mixed mode)
$ pwd
/Library/Java/JavaVirtualMachines/jdk1.8.0_20.jdk/Contents/Home/jre/lib
$ ls jfxswt.jar
jfxswt.jar
$ jar tvf jfxswt.jar | grep FXCanvas.class
18702 Mon May 12 21:52:14 PDT 2014 javafx/embed/swt/FXCanvas.class
I've never used SWT in JavaFX so I don't really know anything about how to use it. If you would like more assistance, post to the e(fx)clipse forums for advice - they are experts on such matters.
Also refer to the version of the documentation which matches the version of Java you are using:
8 JavaFX Interoperability with SWT.
Related
Following this suggest: Hazelcast access using CLI I tried to run Hazelcast console in the following way:
1) Downloaded file hazelcast-client-X.Y.Z.jar
2) Run
/path/to/java -cp "/path/to/hazelcast-client-X.Y.Z.jar" com.hazelcast.client.console.ClientConsoleApp
and I got
Error: Could not find or load main class com.hazelcast.client.console.ClientConsoleApp
Any suggest?
Thanks
ClientConsoleApp is not included in hazelcast-client.jar. Use hazelcast-all.jar instead. I just checked the latest version and ClientConsoleApp works fine.
$ java -cp hazelcast-all-3.12.jar com.hazelcast.client.console.ClientConsoleApp
Apr 12, 2019 9:02:15 AM com.hazelcast.config.AbstractConfigLocator
INFO: Loading 'hazelcast-client-default.xml' from the classpath.
Apr 12, 2019 9:02:18 AM com.hazelcast.client.HazelcastClient
...
I wrote a simple shell script to automate the process of:
Downloading the correct version of hazelcast-all-<version>.jar (containing the ClientConsoleApp class),
Creating the appropriate hazelcast-client.xml file for connecting to the cluster: https://github.com/YongJieYongJie/hazelcast-cli, and
Running the appropriate java command actually connect to the cluster.
Hope this proves helpful.
(Note: This is based on discussion over at this question: Hazelcast access using CLI)
I have an Alfresco installation I'm trying to get to work.
When I run, it displays an error:
Cannot find Alfresco Repository on this server. (Does this application have access to alfresco-global.properties? Does this application have cross-context permissions?)
Alfresco : Cannot find Alfresco Repository on this server has the same error message and was apparently answered by saying "You're trying to use MySQL instead of [the default] Postgres; install the requisite MySQL JDBC driver."
I have a setup that was intended to use Postgres (I'll happily use MySQL instead if someone tells how to do that and it works). $TOMCAT_HOME/lib contains the following, including what looks like one Postgres driver:
annotations-api.jar jasper.jar tomcat-dbcp.jar
catalina-ant.jar jsp-api.jar tomcat-i18n-es.jar
catalina-ha.jar org tomcat-i18n-fr.jar
catalina.jar postgresql-9.4.1211.jre7.jar tomcat-i18n-ja.jar
catalina-tribes.jar servlet-api.jar tomcat-jdbc.jar
ecj-4.4.jar tomcat7-websocket.jar tomcat-util.jar
el-api.jar tomcat-api.jar websocket-api.jar
jasper-el.jar tomcat-coyote.jar
Relatedly, I have:
$ /usr/local/websites/alfresco/java/bin/java -version
java version "1.8.0_111"
Java(TM) SE Runtime Environment (build 1.8.0_111-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.111-b14, mixed mode)
What can/should I do next?
Thanks,
The $TOMCAT_HOME/lib directory is the proper directory for your database driver JARs.
The other file that is very important is your alfresco-global.properties file. It resides in $TOMCAT_HOME/shared/classes.
If this is a manual install of Alfresco (meaning you set up Tomcat on your own) you may have to set up the /shared classloader which involves updating Tomcat's configuration.
The docs have more info.
I just checked out the newest JOGL from git://jogamp.org/srv/scm/jogl.git and installed it.
The installation seems ok. I did run "ant junit.run" and saw 3d graphics.
However, when I tried to compile some example code, I kept getting errors about GLAutoDrawable. It says:
symbol: method getHeight()
location: variable glautodrawable of type GLAutoDrawable
I'm running RHDL 6.5:
$ lsb_release
LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
$ uname -a
Linux oc5088881832.ibm.com 2.6.32-431.21.1.el6.x86_64 #1 SMP Tue Jun 3 19:11:40 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux
This is my java version:java -version
java version "1.7.0_55"
OpenJDK Runtime Environment (rhel-2.4.7.1.el6_5-x86_64 u55-b13)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
And this is my classpath:
# For JOGL
export CLASSPATH=/usr/local/JOGL/gluegen/build/gluegen-rt.jar:$CLASSPATH
export CLASSPATH=/usr/local/JOGL/jogl/build/jar/jogl-all.jar:$CLASSPATH
export LD_LIBRARY_PATH=/usr/local/JOGL/jogl/build/lib:$LD_LIBRARY_PATH
For your reference, I am compiling this example:
http://jogamp.org/wiki/index.php/Using_JOGL_in_Java_Web_Start
It seems like either I missed something in my classpath or this version of JOGL didn't implement getWidth in GLAutoDrawable...
Please can someone let me know what I did wrong?
GLDrawable.getWidth() and GLDrawable.getHeight() have been renamed GLDrawable.getSurfaceWidth() and GLDrawable.getSurfaceHeight() when adding the support of HiDPI: GLDrawable.java
GLAutoDrawable extends GLDrawable. Please rather post your questions about JOGL on our official forum. Best regards.
I followed the instructions from here and when I executed sudo cp /opt/dcm4chee-psql-2.14.7/bin/dcm4chee_init_redhat.sh /etc/init.d/dcm4chee on server, it appeared the follow:
15:25:36,602 WARN [BasicMBeanRegistry] javax.management.MBeanRegistrationException: preRegister() failed: [ObjectName='dcm4chee.archive:service=WADOService', Class=org.dcm4chex.wado.mbean.WADOService (org.dcm4chex.wado.mbean.WADOService#234f79cb)]
15:25:36,602 INFO [WADOService] Registration is not done -> stop
15:25:36,606 ERROR [MainDeployer] Could not create deployment: file:/opt/dcm4chee-2.17.2-mysql/server/default/deploy/dcm4chee-wado-service.xml
org.jboss.deployment.DeploymentException: - nested throwable: (java.lang.reflect.InvocationTargetException)
at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:196)
at org.jboss.system.ServiceController.install(ServiceController.java:226)
at sun.reflect.GeneratedMethodAccessor19.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at sun.proxy.$Proxy4.install(Unknown Source)
at org.jboss.deployment.SARDeployer.create(SARDeployer.java:251)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
Do anyone know what is the problem?
I am right now trying to install dcm4chee on CentOS and I experienced the same problem. When I was looking for a solution I saw your message here, as well as your message on the newsgroups with some hints about possible causes and solutions.
It would be interesting to point from here to the newsgroups thread with answers and additional information, since that could help to other users having the same problem
In short: The problem is WADO service unable to start due to the JAI Image IO library not being properly installed.
You should download the 64 bit version of the library for Linux, extract the files and replace just the original (32 bit) ones from those that you downloaded.
$ cp clibwrapper_jiio.jar $DCM4CHEE_HOME/server/default/lib
$ cp jai_imageio.jar $DCM4CHEE_HOME/server/default/lib
$ cp libclib_jiio.so $DCM4CHEE_HOME/bin/native
Now, your DCM4CHEE installation should be able to run on your 64 bit Linux machine.
In addition to #jap1968 fix, please verify the Java version you are using typing java -version on console.
If you are using Java 8+, install a Java 7 SDK and configure DCM4CHEE to use it adding at line 106 of $DCM4CHEE/bin/run.sh the following line (modify it to match your Java 7 directory):
JAVA=/etc/alternatives/java_sdk_1.7.0/bin/java
I was considering if a java project could produce 2 jars: one for java7 and one for java6, yes, the source code might use some some java7 new features.
so to generate the java6 jar, the command line would be like:
javac -target 1.6 -bootclasspath jdk1.6.0\lib\rt.jar -extdirs "" MyApp.java
Unfortunately,
It simply emits an error:
javac: target release 1.6 conflicts with default source release 1.7
According to this document, it should be possible for jdk6 vs jdk5, anybody knows why it doesn't work in jdk7 vs jdk6? did I do something wrong, or is it just officially not supported?
Thanks.
AFAIK, the source and target have to be the same. Even for Java 6. The only exception is the source can be 1.1 and the target 1.0.
Given there is little difference in the JVM between the latest JVM for Java 6 and Java 7, I suggest you consider upgrading. Also Java 6 will be, End Of (free) Service in Nov 2012, which three months from now...
Even if it were possible it's generally a bad idea - if you want to be sure your code will work on java 6 then you have to build it on java 6. Each new version of java introduces new classes in the class library, and adds new methods to existing classes, and even if you set your java 7 compiler to generate 6-compatible bytecode it won't catch cases where you call a 7-only method.