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.
Related
While building the code getting package sun.security.action is not visible
Package sun.security.action is declared on module java.base, which does not export it to the unnamed module.
What should I do.
Kindly advice, Thanks in advance
Java 8 had no module system - everything is visible or just needs to get imported by archives in jdk (f.e. tools.jar).
Java 9 brought JMS and encapsulated some jdk classes.
In your case, see <JAVA_HOME>/lib/src.zip!/java.base/module-info.class:
exports sun.security.action to
java.desktop,
java.security.jgss,
jdk.crypto.ec,
jdk.incubator.foreign;
Your package isn't public but restricted to some other internal packages/modules.
There was a workaround by adding compiler option --add-exports=java.base/sun.security.action=ALL-UNNAMED at compile time to fix this limitation until version 16.
With version 17 and JEP 403 forget all hope:
It is not a goal to define new standard APIs to replace internal elements for which standard replacements do not yet exist, though such APIs could be suggested in response to this JEP.
Backwards compatibility and important frameworks have lower priority than jdk security - JCP makes strange decisions and works against the community sometimes -.-
I'm trying to switch from liquibase depedencies from 3.0.2 to 3.4.1 in a Java based tool but when running with Java 7 (tried different updates including latest 80) i'm getting strange exceptions like:
2015-11-13T11:55:43,351+02:00 ERROR java.lang.IllegalStateException: Cannot find generators for database class liquibase.database.core.MSSQLDatabase, statement: liquibase.statement.core.UpdateStatement#5232d51 - [pool-3-thread-1]
liquibase.exception.LockException: java.lang.IllegalStateException: Cannot find generators for database class liquibase.database.core.MSSQLDatabase, statement: liquibase.statement.core.UpdateStatement#5232d51
or
iquibase.exception.UnexpectedLiquibaseException: liquibase.exception.ServiceNotFoundException: liquibase.exception.ServiceNotFoundException: Could not find unique implementation of liquibase.executor.Executor. Found 0 implementations
at liquibase.executor.ExecutorService.getExecutor(ExecutorService.java:31) ~[liquibase-core-3.4.1.jar:na]
With Java 8 everything works fine.
Is this a known issue? Is there any documentation stating 3.4.1 works only with Java 8 (couldn't find anything).
Thanks,
Dan
It looks like you're experiencing the issue fixed in this bug report. If you upgrade to 3.5.x you should be okay.
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've got a problem with "javax.el.CompositeELResolver" which is used by TomEE's "javaee-api-6.0-5.jar".
Version information and svn-repository here:
http://mvnrepository.com/artifact/org.apache.geronimo.specs/geronimo-el_2.2_spec/1.0.2
Source of class CompositeELResolver here:
http://svn.apache.org/viewvc/geronimo/specs/tags/geronimo-el_2.2_spec-1.0.2/src/main/java/javax/el/CompositeELResolver.java?view=log
In the "invoke" method I get a null pointer exception because the for-loop iterates through the whole resolvers-array which has got fields with value "null". I suppose this is not avoidable because of the "add" method that doubles the array size if required but does not initialize any values. Shouldn't there be a check if the resolver is "null" in the "invoke" method before using it?
For comparison I ran my application with another javax.el implementation and it's working properly:
<dependency>
<groupId>javax.el</groupId>
<artifactId>el-api</artifactId>
<version>2.2</version>
</dependency>
Am I wrong with my supposition?
I found a similar-sounding issue here:
https://issues.apache.org/bugzilla/show_bug.cgi?id=50293
Is it possible that multi-threading causes my problem?
Solved.
TomEE uses version 1.0.2 of http://mvnrepository.com/artifact/org.apache.geronimo.specs/geronimo-el_2.2_spec
The bug is fixed in version 1.0.4
Based on the fixed geronimo el spec 1.0.4 version it is easy to fix the javaee-api-6.0-5.jar package.
Just download the newest jar file from here http://mvnrepository.com/artifact/org.apache.geronimo.specs/geronimo-el_2.2_spec/1.0.4
and change the javax.el package in javaee-api-6.0-5.jar with the files comes from geronimo el 2.2 spec 1.0.4 jar files
I did it using mc under linux browse the content and copy from one to another. And I tested and works perfect.
Of course you can do it with jar utils as well :-)
It was strange for me that this problem did not exist in 32 bit windows environment but only in 64 bit linux environment. Anyhow the fix solves the problem.
Hope that there will be a javaee-api-6.0-6.jar soon :-)
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...