After upgrading to JRE 1.7.0_13 my Applet is not running anymore. I get the following Security Exception:
basic: Fortschritts-Listener hinzugefügt: sun.plugin.util.ProgressMonitorAdapter#25a091
basic: Ausnahme: Bad applet class name.
ExitException[ 3]java.lang.SecurityException: Bad applet class name
at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
basic: Fortschritts-Listener entfernt: sun.plugin.util.ProgressMonitorAdapter#25a091
The tricky thing is the applet is not loaded from the webserver but installed in JRE lib/ext directory.
I think 'Bad applet class name' has been introduced with _013 because I don't find any information about it. The message does not give me any hint about what to change.
Below is the embedding of the applet in the Web page.
<embed table="some param" anzahl="506"
type="application/x-java-applet"
code="ArtefakteApplet.class"
name="artefakteApplet"
id="artefakteApplet"
height="550" width="1020">
Anybody an idea what to do?
..installed in JRE lib/ext directory.
Don't do that. Sun warned us not to for years before Oracle bought them.
Anybody an idea what to do?
The first thing to do is move the applet from that location to a public, accessible directory and try it again. Also, don't use the embed element. deployJava.js is offered as the reliable way to embed an applet.
Related
I am turning to SO here as my last resort, since my situation has been so illogical that I am at my wits end, even google can't get me a relatively close response.
I'll have to be very chronological. I am maintaining an application in Eclipse. The way application changes apply to the website is when I deploy appropriate .ear and .war files in the jboss test server.
I was relatively new to this whole process, so while learning on this, I stumbled upon occurrence I simply cannot logically comprehend.
1) I made some changes to the application (let's call it changeset_1
for convenience), created appropriate .ear and .war files, deployed
them to the jboss server.
2) Website was returning error 500. No biggie, I thought, let's deploy working files back to server. It returned the same error as if I
didn't deploy originals at all.
3) Restarting jboss server did not accomplish anything.
4) Frustrated, I thought of creating alternate files from the latest deployment directory. So I stored working project directory in the folder neighboring workspace folder used by eclipse. Then I started a new instance of Eclipse, and name new folder as a main namespase (old instance still uses old namespace folder).
5) In a new instance, I did not do any changes, I was just following
the same steps as before to create appropriate .ear and .war files and
deployed them as is to the server.
Now here is an interesting part
After performing steps above, I went to the test site link, and what I saw was: All changes from changeset_1 which I made originally in the first step successfully applied! At the same time, my last deployment was completely ignored.
Can anyone please point me in the right direction on how to approach such situation? Do I miss some kind of fundamental understanding on how all this stuff operates?
I literally don't have any more place to turn to... Unless I could not comprehend such incident to the point I could not explain it properly to google and it was giving me wrong results. Any help is really appreciated!
PS: I will do my best to provide any additional details if needed.
IMPORTANT EDIT
I initially thought I might've missed or misunderstood something, so I have recreated the scenario above for the second time. And for the second time I got the same outcome. Which no longer makes it an accident, but persistent occurrence.
EDIT 2
Upon request, here is a full error log in log file
2016-10-20 08:11:34,492 WARN
[org.jboss.detailed.classloader.ClassLoaderManager] (http-0.0.0.0-8080-1)
Unexpected error during load of:gov.ca.chp.cvs.struts.forms.CVSForm
java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:63)
at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:572)
at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:532)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:530)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:507)
at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:251)
at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:150)
at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:265)
at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1119)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:798)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:441)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.apache.struts.config.FormBeanConfig.formBeanClass(FormBeanConfig.java:358)
at org.apache.struts.config.FormBeanConfig.createActionForm(FormBeanConfig.java:212)
at org.apache.struts.util.RequestUtils.createActionForm(RequestUtils.java:292)
2016-10-20 08:11:34,492 WARN
[org.jboss.detailed.classloader.ClassLoaderManager]
(http-0.0.0.0-8080-1) Unexpected error during load of:gov.ca.chp.cvs.struts.forms.CVSForm
java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:63)
at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:572)
at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:532)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:530)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:507)
at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
Rootcause: "java.lang.UnsupportedClassVersionError: Bad version number in .class file" comes when you compile a Java class in higher version of Java Compiler and run it on lower version of JRE.
Read more: http://javarevisited.blogspot.com/2011/12/bad-version-number-in-class-files-cause.html#ixzz4NjV9ORkF
This question might have been asked earlier on SO, and please be assured I did check all the available solutions. Was still unable to get it to run
My problem is exactly as described in this post Shared native library in Tomcat UnsatisfiedLinkError
Standalone Java application is running perfectly well. However with Tomcat(9) it fails to run and throws
java.lang.UnsatisfiedLinkError: third_party.org.chokkan.crfsuite.crfsuiteJNI.swig_module_init()V
at third_party.org.chokkan.crfsuite.crfsuiteJNI.swig_module_init(Native Method)
at third_party.org.chokkan.crfsuite.crfsuiteJNI.<clinit>(crfsuiteJNI.java:87)
at third_party.org.chokkan.crfsuite.Tagger.<init>(Tagger.java:39)
I know that my DLL is being loaded, also I checked that the folder my dll is in, is in the PATH variable. I have also checked the classes being loaded and the DLL is infact being loaded.
I have noticed 3 types of UnsatisfiedLinkError at SO
1) java.lang.UnsatisfiedLinkError: third_party.org.chokkan.crfsuite.crfsuiteJNI.swig_module_init()V
2) java.lang.UnsatisfiedLinkError: third_party.org.chokkan.crfsuite.crfsuiteJNI.swig_module_init()B
3) Where the class loader is loading twice.
I believe the V , at the end does signifies something. But I am not able to figure out exactly what?
One of the accepted answers in the SO post I shared above claims it has something to do with version. I do not understand how is that an acceptable solution since it works perfectly well when run as a standalone java application.
Wasted a lot of time already, any help is appreciable.
Thanks
Chahat
I faced with the same issue. I finally find the solution. It works for me.
First, I instaled libLBFGS and crfsuite. You can find the instruction here (http://www.chokkan.org/software/crfsuite/manual.html). The libcrfsuite.so will be install in /usr/local/lib
Second, I edit tomcat config in order to load native library. I create setenv.sh in tomcat bin folder, set CATALINA_OPTS variable with content :
export CATALINA_OPTS="-Djava.library.path=/usr/local/bin:/usr/local/lib"
Finally, I used custom ServletContextListener and explicitly load libcrfsuite.so by System.load(). I go this link to download lib (https://github.com/vinhkhuc/jcrfsuite/tree/master/src/main/resources/crfsuite-0.12)
I had a similar problem but not with Tomcat.
I ended up copying the logic from one of their classes and simply invoking:
static {
try {
CrfSuiteLoader.load();
} catch (Exception e) {
throw new RuntimeException(e);
}
}
I need to create an Applet that can load a com method, for this purpose I used the java com bridge (jacob) deal with the com dll, and My Environment is set as follow:
os:win7x64
IDE:Eclipse32bit-version
COM DLL:BPIKeyCOM.dll 32-bit version
com bridge : jacob1.17-32bit version
server: Tomcatv7.0
I put jacob.dll under C:\Windows\System32 and jacob.jar under WEB-INF\lib
When I run the project, it's working fine in Eclipse. But when deployed on the web, the following error messages appear:
java.lang.NoClassDefFoundError: com/jacob/activeX/ActiveXComponent
at Fmain.Ikeycheck(Fmain.java:180)
at Fmain.init(Fmain.java:73)
at sun.applet.AppletPanel.run(AppletPanel.java:435)
at java.lang.Thread.run(Thread.java:724)
Caused by:
java.lang.ClassNotFoundException: com.jacob.activeX.ActiveXComponent
at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:219)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:152)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)...
It looks like this message is talking about that it can't find com/jacob/activeX/ActiveXComponent.class, but I don't understand how.
I've already searched for many solutions and tried to solve it, but it still keeps showing this error message, I use to do sigh jar, make sure the classpath is correct, and even try to change the policy file...etc. But still, it's not working!
You've installed the dll and jacob.jar into your Java Web container; unfortunately, that is not the user's web browser (e.g. Applet Container). You need to add the dll and jacob.jar file into the applet jar. You should probably also read this. It's also important to point out that if your users install a 64-bit jdk, or aren't running Windows - then your Applet will not work.
Have a look at the example provided with jacob:
e.g.
jacob-1.17_src.zip\jacob-1.17\samples\com\jacob\samples\applet
This is a nice example how it works - it even has a readme.txt with a full description inside...
I have installed R 3.0.1 and Eclipse Kepler. (I have installed StatE to run R-script through and Eclipse R-console with no problem.) However, I cannot seem to get a java program to run. I'm posting my issues to see if anyone else has encountered them or can help me understand what I'm doing wrong. After installing R, rJava (through R), and eclipse, I ran the RJavaEclipse Plugin from studytrials.com. Then I configured the paths to the appropriate libraries or .dll.
When I try to run the rtest.java file that comes with the rJava JRI, I get the following error:
Cannot find JRI native library!
Please make sure that the JRI native library is in a directory listed in java.library.path.
java.lang.UnsatisfiedLinkError: no jri in java.library.path
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at org.rosuda.JRI.Rengine.<clinit>(Rengine.java:19)
at rtest.main(rtest.java:61)
When I try to run via the run tab in eclipse -> run configurations -> R -> rtest, I get a pop-up warning that says:
R_HOME must be set or R properly installed (\Software\R-core\InstallPath registry entry must exist).
So, following the advice that so many on SO give, I tried to find the answer in the warning message.
I found the path information in Eclipse (and Windows) was pointing to the correct locations both in the library and in the R run configuration:
(C:\Users\csnyder\Documents\R\win-library\3.0\rJava\jri\x64;C:\Program Files\Java\jre7\bin\server;C:\Program Files\R\R-3.0.1\bin\x64)
These paths also match the windows environmental paths.
So, I'm at a loss. If anyone has any suggestions on what my issue might be, I would greatly appreciate it. Please comment if you require any additional information.
I had the exact same problem on Linux. In essence, this set up is not updating java.library.path properly and the linkage to the JRI jars fails. I started by printing the path to the console with:
System.out.println(System.getProperty("java.library.path"));
And got this:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
To guarantee that Eclipse updates java.library.path correctly at run time, the Native library location item must be set to the folder containing the JRI jars (/usr/local/lib/R/site-library/rJava/jri in my case):
Just select the item and click Edit... to change its value.
you can try to add the jri.dll(in your rJava/jri/x64 package) on the System environment variable path,like this:(sorry I cann't put the picture on it )
in that way ,then restart your IDE and just run your test.
we are haunted by occasional occurences of exceptions such as:
com.google.gwt.user.client.rpc.SerializationException: Type 'xxx' was not assignable to 'com.google.gwt.user.client.rpc.IsSerializable' and did not have a custom field serializer.For security purposes, this type will not be serialized.: instance = xxx
at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter.serialize(ServerSerializationStreamWriter.java:610)
at com.google.gwt.user.client.rpc.impl.AbstractSerializationStreamWriter.writeObject(AbstractSerializationStreamWriter.java:129)
at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter$ValueWriter$8.write(ServerSerializationStreamWriter.java:152)
at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter.serializeValue(ServerSerializationStreamWriter.java:534)
at com.google.gwt.user.server.rpc.RPC.encodeResponse(RPC.java:609)
at com.google.gwt.user.server.rpc.RPC.encodeResponseForSuccess(RPC.java:467)
at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:564)
at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:188)
at de.softconex.travicemanager.server.TraviceManagerServiceImpl.processCall(TraviceManagerServiceImpl.java:615)
at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:224)
at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
at org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:419)
at org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpAprProtocol.java:378)
at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1508)
at java.lang.Thread.run(Thread.java:619)
The application is normally running fine. The indicated class implements Serializable (the whole object graph).
So far the only patterns / observations are:
we seem to have the issue only when the application is used inside an iframe
the problem seems to happen when a new version of the application has been deployed
running firefox in privacy mode (disabling all caches etc.) doesn't fix the problem
Any ideas?
Holger
did you check http://code.google.com/webtoolkit/doc/latest/tutorial/RPC.html#serialize
the article says:
It has a default (zero argument) constructor with any access modifier (e.g. private Foo(){} will work)
I'm allways forgetting zeroargument const. when I am making a serializable object :D
Very possible reason - older version of client is still cached in browser. It sends rpc requests, but server is already restarted and have newer versions of rpc files (*.symbolMap)
I encountered the problem when I used Tomcat6 + Devmode in Ubuntu Lucid amd64. Using com.google.gwt.user.client.rpc.IsSerializable instead of java.io.Serializable seemed solved the problem.
I assume you're running the application on localhost and in hosted mode? If so, you might want to keep an eye on the work directory (or the equivalent directory if you're not running the application in a tomcat server). Check the webapp's folder for serialization policiy files (*.gwt.rpc).
It's possible they're not loaded correctly, the only workaround we have found so far, is to restart your server after each serialization fault.
The problem is due to the fact GWT will generate its serialization policy files at run time, assuming you're running in hosted mode. In compiled mode, GWT will generate all necessary files at compile time. AFAIK, tomcat's unable to load in the resource files at run time and hence will not include the serialization files each time they are needed for the first time.
When restarting the server, tomcat's able to pick up the previously generated file and hence you shouldn't receive the same error after restarting.
Can you verify this?
If you are running on JBoss, this might be due to the fact that the previously deployed application is not deleted when undeployed. To fix this, you must modify the following file in JBoss:
${JBOSS_HOME}/server/default/deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xml
and set the following attribute to true: deleteWorkDirOnContextDestroy
When the previously deployed application is not cleaned up, GWT can be confused about which RPC file it needs to load and you end up with those SerializationException
I had the same problem and I found a solution from another person:
"There is a possibility that you have a class which implements Serializable and you have an attribute field within that class which is not Serializable hence you might be getting this exception."
Many thanks to that person :)
My advice is to make all fields (which are not primitive types) in your class to implement Serializable also! This solved my problem.
This problem occurs when a GWT 2.5 application is compiled using JDK 1.7. GWT 2.5 supports JDK 1.6 and using this version of JDK will fix this issue.
So the RPC files are unique because they are loaded by servlets as well as being used in GWT. See http://code.google.com/webtoolkit/release-notes.html#Release_Notes_1_4_59 where it says "This file must be deployed to your web server as a public resource, accessible from a RemoteServiceServlet via ServletContext.getResource()"
Is it possible the new application is being reloaded dynamically and getResource is failing in some way? Does restarting the application fix things?
I've had the same error and fix this by clean the browse cache and navigation history.
I was getting a SerializationException also but I was also seeing this error showing up right before the serialization exception:
[uptimereports/2.340102563369350884].:
Example : error : cannot find template
registration-confirmation.vm
It turned out to be a problem finding my velocity template. Once I fixed that problem the SerializationException stopped showing up, so if you follow Kerem's advice and still have problems, look for other exceptions in your log.
The best way to know the exact issue is to compile your code using -logLevel DEBUG or TRACE and check inside Validating Units. I am sure you would be able to find out the exact issue with line numbers as well.
First make sure you have a 'clean' serializable class ie empty constructor, no inner classes implementing serializable and use GWT Serializable class instead of Java Serializable class.
Then simply open your site in an Incognito tab (Chrome) solves the problem. Local browser cache causes loading old rpc files.
I had this problem when running SuperDevelopmentMode with a setup where codeserver was not on the same host as tomcat server. I had codeserver on my host, while tomcat running in the docker container. It turns out in such setup app server cannot get the right serialization policy files, so quite similar as described by thomaux in one of answers above, just different setup.
I had to add -Dgwt.codeserver.port=9876 to start parameters of tomcat as described here. This causes GWT SuperDevMode to switch to mode of getting serialization policy files through network. Still the url is hardcoded in com.google.gwt.user.server.rpc.RemoteServiceServlet#getCodeServerPolicyUrl as
"http://localhost:" + codeServerPort
so you have to make sure that your tomcat can reach codeserver on that port, by tunneling or routing the traffic if necessary. Alternative is to hack GWT code to allow changing that localhost to something else too, but this doesn't look clean and secure.