5

I'm creating a JSF+JPA project for and GlassFish 4. A couple of times I get an exception at the at this point:

List<User> users = connection.getUserList();

for (User u : users) { //exception

...

    public List<User> getUserList() {

    EntityManager em = Persistence.createEntityManagerFactory("project").createEntityManager();
    List<User> users = em.createQuery("SELECT c FROM User c", User.class).getResultList();
    em.close();
    return users;
}

stacktrace:

javax.faces.el.EvaluationException: java.lang.ClassCastException: de.sep.ateam.sap.norris.model.User cannot be cast to de.sep.ateam.sap.norris.model.User
    at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:101)
    at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102)
    at javax.faces.component.UICommand.broadcast(UICommand.java:315)
    at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790)
    at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282)
    at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
    at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
    at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646)
    at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
    at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
    at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
    at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
    at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
    at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
    at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
    at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
    at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
    at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
    at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
    at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
    at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.ClassCastException: de.sep.ateam.sap.norris.model.User cannot be cast to de.sep.ateam.sap.norris.model.User
    at de.sep.ateam.sap.norris.controller.beans.LoginBean.doLogin(LoginBean.java:50)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at javax.el.ELUtil.invokeMethod(ELUtil.java:326)
    at javax.el.BeanELResolver.invoke(BeanELResolver.java:536)
    at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256)
    at com.sun.el.parser.AstValue.invoke(AstValue.java:269)
    at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304)
    at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40)
    at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50)
    at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105)
    at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87)
    ... 35 more
Improve this question
7
  • 2
    Please, show your Exceptions stack trace. Commented Nov 25, 2013 at 17:06
  • @Rakesh: library/framework/product names like "JSF" and "GlassFish" are not code. Please stop formatting them as code in suggested edits. Commented Nov 25, 2013 at 17:09
  • Try for(Object u: users) { User user = (User) u; ..... Commented Nov 25, 2013 at 17:15
  • 2
    Your entity classes are deployed twice. Check you .jar files! Commented Nov 25, 2013 at 17:18
  • 1
    I've faced this problem before, it happens because of some left overs from the old EntityManagerFactory, somehow its classloaders survived after redeployment, what you need to do is to close the factory just before you redeploy your app, you can use ServletContextListeners for that, it allows you to do exactly what you need, here is a tutorial on how to implement it: 4dev.tech/2015/08/… Commented Aug 18, 2015 at 0:29

4 Answers 4

Reset to default
3

If you are sure that you don`t have multiple versions of the same class loaded in the application server, you might try to reset the server cache.

Follow this steps:

  1. Undeploy the application;
  2. Stop the application server;
  3. Delete the osgi cache folder of your application server. I.e. if you are using glassfish, it is the folder: E:\glassfish-3.1.2.2\glassfish\domains\domain1\osgi-cache
  4. Restart the server;
  5. Deploy the application.
Improve this answer
1

I had the same issue, and I finally found a workaround on java.net :

Copy all org.eclipse.persistence jar files from glassfish4/glassfish/modules to WEB-INF/lib. Then go in your glassfish-web.xml, and set class-delegate to false.

Worked for me !

Improve this answer
1
  • In my case it was sufficient to only add org.eclipse.persistence.core.jar and org.eclipse.persistence.jpa.jar to WEB-INF/lib Commented Jun 30, 2016 at 13:30
0

I had a similar problem because I was serializing classes and the serialized versions couldn't be deserialized after the classes updated and the app was restarted without restarting the container.

Improve this answer
2
  • how did you fix it? i'm serializing the classes too Commented Nov 25, 2013 at 17:40
  • We used things like private static final long serialVersionUID = 1L; and updated the uid when we knew it would break deserialization and also sometimes just destroyed the cache on purpose. Also, we have multiple caching strategies, but one of them was being run by the container (Tomcat) which we turned off on dev instances (where we update the apps without restarting the container) and have a container restart policy on deploy for production. Oh, also sometimes the container when its rebooting an app has a hard to replacing classes because it can't unload some class on redeploy. Commented Nov 30, 2013 at 22:50
0

Typically this happens when there is more than one instance of the same jar in a different class loader. Most app servers have a global class loader and a web-app specific class loader (some also have others like contrib, etc.). If the class loader that is higher up in the food chain has that class defined already and it gets redefined by a lower level class loader this sort of situation can occur (the same class in a different class loader is considered different even though its definition is the same). The order of how/when jars get loaded is not guaranteed which could explain why you sometimes see the error and sometimes don't. Long story short, make sure you haven't already deployed the jar that contains this class somewhere else in the server that is visible to your web app.

Improve this answer
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.