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...
Related
I work still view month on a project with RapidClipse 4.0
I deployed on the production server several versions of the project war files. Everything worked fine.
After the last deployment I got a blank screen after loading the application URL
For the server I use a docker container with following setting:
Apache Tomcat/8.5.43, JVM: 1.8.0_222-b10, 3.10.105, amd64
My first thought was: "ok you did something wrong in your code.. turn back and every thing is fine.... :-((
It wasn't !!
I used several versions which runs fine befor.
I stopped the application, redeployed it and deleted it.
Then I deployed an older version....and once again a version older..a.s.o
Non of the versions which worked fine befor did work again.
I got every time the same result: after loading the application a blank white screen.
So far so bad:
I tried to look into ../conf/server.xml if deployment parameter is set correctly:
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
looked fine!
I enhanced the cache by:
$CATALINA_BASE/conf/context.xml added following code:
<Resources cachingAllowed="true" cacheMaxSize="100000" />
also without success.
I tried to look in catalina.out: There is still nothing helpfull:
14-Aug-2019 20:29:21.087 INFO [http-nio-8080-exec-6] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive [/usr/local/tomcat/webapps/RC_07.war]
14-Aug-2019 20:29:31.190 INFO [http-nio-8080-exec-6] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/usr/local/tomcat/webapps/RC_07.war] has finished in [10,102] ms
after debug in browser I got following:
257ms Processing time was 134ms
257msReferenced paintables: 6
283msEstablishing push connection
300msCould not load theme from http://myIP:8888/RC_07/VAADIN/themes//styles.css?v=7.7.13
310msPush connection established using long-polling
I searched also in the history of the docker container an found that this problem (300ms....) still persists from beginning, over all versions I deployed before.
Out of this, I assume, that this could not be the reason, too.
Or am I wrong?
I searched around this VAADIN Problem and found a lot, but I was not able to solve it. The styles.css file are still in place on the server.
I am wondering on ..../VAADIN/themes//styles.css...
the double slash in error message.
But in my code I couldn't find similar.
Also the buildpath in eclipse includes the folder structure like expected.
Now I am at the end!
I am confused, how I should go ahead to figure out the reason for this behavior, or much better to fix it.
Any idea/ help would be welcome!!
Thank you in advance
rgds
OpaHeinz
After long research, togehter with RapidClipse support we found the solution.
I had two issues:
1) unknown how, we assume, that there was an error in the MainUI xml file.
After resetting with and high of view and layout, and turning back to setting before,
the page elements were visible again in design view.
2) there is a parameter for the theme under MainUI properties - misc -
This parameter was set, but without content. This results in a code line: this.setTheme("");
After resetting this, a deployment was possible like before.
Everything is fine now.
Thanks again to RapidClipse support.
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've performed an update from typo3 4.7.20 to 6.2.15. The process worked fine and there were no critical errors while running the install tool.
The frontend looks fine but the backend is broken:
I've removed all uncompatible extensions before I run the update. I've also checked all settings in the installationtool und deleted the temp/cache folder first.
I've got the feeling that the error is caused by the TemplaVoila! extension, I'm using v. 1.9.8. Firebug does not shows any error.
Does anyone had a similar problem and have already solved it?
Thank you very much!
I have come across this one multiple times. More often it is because there is a broken TBE_STYLES. I suggest you look around for $TBE_STYLES in your typo3conf folder and disable it for the time being. Most likely it will be in the extTables.php or some other file which is included dynamically.
seems BE is working, but you css does not got loaded.
check your 'web inspecter' to see if you get errors on loading CSS.
clear your cache (remove everything in typo3temp) and try again
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.
Trying my hand at CDI for the first time. I'm using Glassfish v3. When I deploy my app, I get the following failure:
java.io.IOException:
com.sun.enterprise.admin.cli.remote.RemoteFailureException:
Exception while loading the app :
org.glassfish.deployment.common.DeploymentException:
java.lang.IncompatibleClassChangeError:
com.example.arizona.client.ArizonaService
and
com.example.arizona.client.ArizonaService$App
disagree on InnerClasses attribute
at
com.fuhrer.idea.glassfish.server.GlassfishServer3.doParseResponse(GlassfishServer3.java:28)
at
com.fuhrer.idea.glassfish.server.GlassfishServer3Base.parseResponse(GlassfishServer3Base.java:156)
at
com.fuhrer.idea.glassfish.server.GlassfishServer3Base.invoke(GlassfishServer3Base.java:127)
at
com.fuhrer.idea.glassfish.server.GlassfishServer3Base.handleDeployment(GlassfishServer3Base.java:78)
at
com.fuhrer.idea.javaee.server.JavaeeServerInstance$2.run(JavaeeServerInstance.java:131)
I should mention that I'm not even actually using injection, or any other CDI features yet. This is just trying to get the dependencies straightened out.
I've had the same issue, but with Weld in Tomcat. Problem for me was caused by changing an inner class definition to a normal class. Resulted, in my case, in having the old innerclass still in the classes directory but with a new parent class.
Cleaning the classes directory worked for me.
Nearly a year later I'm sorry to say that I never solved this, and for various reasons moved on to another stack altogether: Tomcat, Wicket and Wicket-CDI, all of which have worked great for me.