I use Openshift for a small app.
In this app, I upload images and resize them and stores them in a database.
I use: BufferedImage bufferedImage = ImageIO.read(inputStream);
But today when I run this part of code I got this exception:
java.lang.UnsatisfiedLinkError: no awt in java.library.path
java.lang.ClassLoader.loadLibrary(ClassLoader.java:1886)
java.lang.Runtime.loadLibrary0(Runtime.java:849)
java.lang.System.loadLibrary(System.java:1088)
sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:67)
sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:47)
java.security.AccessController.doPrivileged(Native Method)
java.awt.Toolkit.loadLibraries(Toolkit.java:1657)
...
I do not know if the OpenShift team has done any upgrade lately. Last time I run that code was perhaps 6 months ago.
Do you guys have any solution?
Best regards
Fredrik
A rebuild, a redeploy and a restart solved the problem.
Really strange.
To me this sounds like a system thing and would not have to do with the app itself.
Best regards
Fredrik
Related
I'm trying to upgrade my applications from Liberty 18.0.0.1 to 18.0.0.2 but they all are now failing on:
java.lang.NoClassDefFoundError: javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter
...
stacktrace
the problem seems to be with ldapRegistry-3.0 - once that feature is enabled all jax-rs requests are failing. Once I remove ldapRegistry the code works fine, but I need this feature for my applications...
I've even built small example to demonstrate it, with single RestEndpoint /v1/api/employee : Sample project server config
Is this a bug, can I report it somewhere? or am I doing something wrong here?
Here is the server dump
Thank you
This seems to be caused by a subtle split package classloading conflict. I was able to reproduce this issue with Liberty 18.0.0.2 and the underlying exception looks something like this:
java.lang.NoSuchMethodException: javax.xml.bind.annotation.W3CDomHandler.createUnmarshaller(javax.xml.bind.ValidationEventHandler)
In this case it seems that javax.xml.bind.annotation.W3CDomHandler was loaded from classloader A, and javax.xml.bind.ValidationEventHandler was loaded twice -- once from classloader A and once from classloader B. The error we get here is caused by the JVM looking for javax.xml.bind.annotation.W3CDomHandler.createUnmarshaller(javax.xml.bind.ValidationEventHandler) where both classes are from classloader A, but instead it looks for a createUnmarshaller(ValidationEventHandler) method where ValidationEventHandler comes from classloader B.
This bug will be resolved in the next version of Liberty (18.0.0.3)
I am trying to use ActiveMQ 5.10.0 with SoapUI 4.6 and Hermes 1.14. I get the error below when I try and add a queue. I presume Hermes can't find the type IdGenerator in any of the loaded jars. Which are:
activemq-client-5.10.0.jar
geronimo-j2ee-management_1.1_spec-1.0.1.jar
geronimo-jms_1.1_spec-1.1.1.jar
Does anyone know where this class is defined? I looked for activemq-util.jar in the binary distribution but I did not find such a file.
Error:
java.lang.NoClassDefFoundError: Could not initialize class org.apache.activemq.util.IdGenerator
at org.apache.activemq.ActiveMQConnectionFactory.getClientIdGenerator(ActiveMQConnectionFactory.java:969)
at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:363)
at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:331)
at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:303)
at org.apache.activemq.ActiveMQConnectionFactory.createQueueConnection(ActiveMQConnectionFactory.java:260)
at hermes.impl.jms.ConnectionManagerSupport.createConnection(ConnectionManagerSupport.java:147)
at hermes.impl.jms.ConnectionManagerSupport.createConnection(ConnectionManagerSupport.java:92)
at hermes.impl.jms.ConnectionSharedManager.reconnect(ConnectionSharedManager.java:81)
at hermes.impl.jms.ConnectionSharedManager.connect(ConnectionSharedManager.java:91)
at hermes.impl.jms.ConnectionSharedManager.getConnection(ConnectionSharedManager.java:104)
at hermes.impl.jms.ConnectionSharedManager.getObject(ConnectionSharedManager.java:142)
at hermes.impl.jms.ThreadLocalSessionManager.connect(ThreadLocalSessionManager.java:190)
at hermes.impl.jms.ThreadLocalSessionManager.getSession(ThreadLocalSessionManager.java:570)
at hermes.impl.jms.AbstractSessionManager.getDestination(AbstractSessionManager.java:460)
at hermes.impl.DefaultHermesImpl.getDestination(DefaultHermesImpl.java:367)
at hermes.browser.tasks.BrowseDestinationTask.invoke(BrowseDestinationTask.java:141)
at hermes.browser.tasks.TaskSupport.run(TaskSupport.java:175)
at hermes.browser.tasks.ThreadPool.run(ThreadPool.java:170)
at java.lang.Thread.run(Unknown Source)
This is very old but in case anyone else is trying to get this spun up... don't use the built in HermesJMS that comes with SoapUI. Apparently there's a bug in it that doesn't play nice with ActiveMQ v5.8 and following [I tried 5.11 & 5.13 and had the issue. The cheating fix is to install the standalone [I had to get it from sourceforge].
The sourceforge jar is installed with [assuming version 1.14]: java -jar hermes-installer-1.14.jar
Once installed you can tie this version to soapui or launch it with the bat/sh file. I still had issues with ActiveMQ version 5.13 but version 5.11 worked for me.
The IdGenerator class is located in the activemq-client jar. Here is the result of a search in the source tree:
/activemq-client/src/main/java/org/apache/activemq/util/IdGenerator.java
There's been no recent changes so I'd guess that the error is misleading and that it's actually some other missing dependency that's being loaded when the class is created. Is there more information in the log or a 'caused by exception' ?
For whom it may interest. This is kind of common issue I come accross from time to time. I call it jar version incompatibility. I was getting exception in title and other funny exceptions when using latest (but not actively developed) hermes 1.14 and currently latest Apache Active MQ 5.14. I've found out after a long struggle that it is fixed by using an older version of Active MQ - like 5.3.
I'm trying to upgrade an application to Java 7 from Java 6 and I'm getting a new exception that isn't present when running the application under Java 6.
Here's the first section of the stack trace:
java.lang.ClassCastException: java.lang.String cannot be cast to org.jboss.serial.finalcontainers.IntegerContainer
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readInt(DataContainer.java:1044)
at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:310)
at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:845)
at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
at org.jboss.serial.persister.RegulrObjectPersister.defaultRead(RegularObjectPersister.java:273)
at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:845)
at org.jboss.serial.persister.ObjectInputStreamProxy.readObjectOverride(ObjectInputStreamProxy.java:68)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:364)
at java.util.ArrayList.readObject(ArrayList.java:733)
at sun.reflect.GeneratedMethodAccessor352.invoke(Unknown Source)
I found this JBoss bug, which is supposedly fixed...
https://issues.jboss.org/browse/JBSER-128
but the version it's fixed in (1.0.6.FINAL) hasn't been released yet:
https://issues.jboss.org/browse/JBSER
Has anybody run into this that could suggest a workaround?
The application runs in JBoss 6.0.0.
PS I am aware that JBoss 6 is past its EOL and not tested with Java 7.
Well, you could build the release yourself from the tag in the SVN repo. Or if you're really trusting (or want to do a quick experiment) download the binary I built (here, won't promise they stay online though).
Just replace all occurrences of the jar in the JBoss distribution and don't forget to enable the fix with system property
-Dorg.jboss.serial.sync_binary_formats=true
As highlighted here
https://issues.jboss.org/browse/JBSER-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
Anyhow for me this worked for Vectors at least (there's other potential problems, but not being able to transfer CCHashMaps I'll survive ;) ).
I found a workaround solution for my problem. Since Java 7 changed the serialization behavior of Vector, I changed to ArrayList (which did not change) and the problem has been resolved.
Hope this helps somebody out there struggling with the same issue.
I am tearing my hair out trying to figure out how to run the simplest Apache Mina tutorial.
I am running the tutorial on Netbeans 6.9 on Ubuntu and it keeps saying the following error
even I have added the necessary jar files to the compile-time libraries folders in Netbeans.
Exception in thread "main"
java.lang.ExceptionInInitializerError
at minatimeserver.MinaTimeServer.main(MinaTimeServer.java:29)
Caused by: java.lang.RuntimeException:
Uncompilable source code - package
org.slf4j does not exist
at org.apache.mina.core.service.AbstractIoService.(AbstractIoService.java:51)
... 1 more
I have downloaded slf4j-log4j12-1.6.1.jar and slf4j-api-1.6.1.jar and placed them in the compile-time libraries folder too but the error still remains. I have also tried with slf4j-1.5.11
Any person who has solved this problem? Please help me or I'm going bald in no time!
Thanks in advance!
Yakult121
slf4j-log4j12-1.6.1.jar and slf4j-api-1.6.1.jar are runtime libraries.
Add them to your class path not to your compile-time libraries else it will try to compile your jar files.
Also See
What's the difference of compile time libraries and run time libraries in java?
Apache mina uses slf4j-api-1.6.1.jar, adding slf4j-api-1.6.1.jar to class path will resolve the issue.
Well, I also had faced same problem. What I did was, I unjarred the mina-core-2.x that is on the main page of the apache project. When things failed, I changed downloaded mina-core-1.1.7 and everything worked fine. Of course, you have to make sure that you set the claspath correctly.
i have a strange problem. I have an ICEFaces(1.8.2) + Facelets application im working on and every time i make a change to it and deploy i must restart Glassfish(2.1.1) else i get a "java.lang.ClassCastException" on my entities. The error message is :
java.lang.ClassCastException: za.co.africanpulse.rms.frontend.domain.Menuheader cannot be cast to za.co.africanpulse.rms.frontend.domain.Menuheader
If i restart Glassfish as said above all is ok... but this is getting kinda irratating. I dont quite know what exactly you would like me to post so that my problem is easier identified / understood. Anyways any help will be most appreciated.
Many many thanks
You should probably open an issue with the GlassFish project: https://glassfish.dev.java.net/servlets/ProjectIssues.
StackOverflow isn't really designed to be a bug reporting/analysis tool.
That said... someone might have run into this and you could 'Get Lucky'...
Edit 1:
For example, this query: http://www.google.com/search?q=glassfish+icefaces+facelet+classcastexception
Netted this hit: http://seamframework.org/Community/HelpOnSeam220ICEfaces181AndGlassfish21
which looks like it may be useful.
When the web.xml servlet version is below 2.5 and jsf is still at 1.1 specified in the faces-config.xml then strange persistence related issues will arise. In my case entities could not be cast to themselves..???
After changing servlet version and jsf version i could successfully inject EntityManagers into my DAOs...