Websphere 6.1: periodic "EntityManagerFactory incompatible"

[benmoore]

Periodically, I get the following exception:

WARN  [org.jboss.seam.Component] Exception calling component @Destroy method: authenticator
java.lang.ClassCastException: org.jboss.seam.persistence.EntityManagerFactory incompatible with javax.persistence.EntityManagerFactory
     at org.jboss.seam.persistence.ManagedPersistenceContext.getEntityManagerFactoryFromJndiOrValueBinding(ManagedPersistenceContext.java:236)
     at org.jboss.seam.persistence.ManagedPersistenceContext.initEntityManager(ManagedPersistenceContext.java:79)
     at org.jboss.seam.persistence.ManagedPersistenceContext.getEntityManager(ManagedPersistenceContext.java:108)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     ...
     at com.foo.expressionbuilder.service.Authenticator_$$_javassist_3.destroy(Authenticator_$$_javassist_3.java)

My authenticator is amazingly simple. It is not an EJB but a POJO. It currently doesn't use entityManager but will in the future:

@Name("authenticator")
public class Authenticator implements Serializable {

  @In
  private EntityManager entityManager;

  @Logger
  private Log log;

  public boolean authenticate() {
    String username = Identity.instance().getUsername();
    String password = Identity.instance().getPassword();
    log.debug("Authenticating user  " + username);
    return true;
  }

  @Destroy
  public void destroy() {}
}

I'm using Hibernate as the persistence provider: persistence.xml (sorry for linking elsewhere, but I wasn't able to get the wiki to accept it)

This issue and this (linked from the JIRA bug) seem similar, but are definitely different.

Anyone know what's going on?

thank you in advance, ben

[benmoore]

p.s. after I get this error, I have to restart Websphere. Otherwise, no logins succeed (they always result in the above exception).

[jbalunas.jbalunas.jboss.org]

From what I remember of looking at this it was primarily an issue on windows machines.  Are you using windows? 

Also someone mentioned in the forum that:

You can avoid the class cast exception just by removing the persistence-api.jar from the ear/war.

Perhaps check that.  We do know that websphere can have problems injecting EJB 3 objects (EJB, EJBContext, some persistence stuff) into non EJBs. 

You could also debug in the code and see what the objects really are?  In other words is it a classloader issue, or is the class really not incompatible?

-Jay

[benmoore]

Hi Jay,

From what I remember of looking at this it was primarily an issue on windows machines. Are you using windows?

I've tried on both platforms. On unix, the exception occurs immediately (as soon as the first non-EJB uses the EntityManager injected reference). On Windows, the exception is periodic.

Also someone mentioned in the forum that:

    You can avoid the class cast exception just by removing the persistence-api.jar from the ear/war.

Yeah, I saw that before I posted here. I don't have persistence-api.jar anywhere

You could also debug in the code and see what the objects really are? In other words is it a classloader issue, or is the class really not incompatible?

Just did that. The problem is definitely on line 236 of org.jboss.seam.persistence.ManagedPersistenceContext (this is Seam 2.0.1):

   public EntityManagerFactory getEntityManagerFactoryFromJndiOrValueBinding()
   {
      EntityManagerFactory result = null;
      //first try to find it via the value binding
      if (entityManagerFactory!=null)
      {
         result = entityManagerFactory.getValue();
      }
      ...
      return result;
   }

entityManagerFactory.getValue() is returning an instance of org.jboss.seam.persistence.EntityManagerFactory but result is of type javax.persistence.EntityManagerFactory.

[benmoore]

Jay, can you just check that this is correct?

<persistence:managed-persistence-context name="entityManager"
  auto-create="true"
  entity-manager-factory="#{myEMFactory}"/>

<persistence:entity-manager-factory name="myEMFactory" persistence-unit-name="myDB"/>                                     

<persistence-unit name="myDB">
 ...
</<persistence-unit>

[jbalunas.jbalunas.jboss.org]

Hi Ben,

This does look correct based on the JPA example.

• Is this the same application that you discussed in a different post - with a mixture of EJB and POJO components?

• Are you still using the setting from the persistence.xml?

<jta-data-source>jdbc/mydb</jta-data-source>

• If you switch to a non-jta-data-source what does that change?  Also specify the details of the persistence unit:

persistence-unit name="myDB" transaction-type="RESOURCE_LOCAL">

• You linked to your persistence.xml file above - could you provide your complete components.xml?

Thanks,
Jay

[ericjung2]

Jay,

I'm no longer posting under my alias :)
For what it's worth, a restart of the entire app server (not the server instance) seemed to make the problem disappear on unix... at least for now. I cannot replicate it anymore.

Is this the same application that you discussed in a different
post - with a mixture of EJB and POJO components?

Yes.

Are you still using a jta-data-source?

Yes.

If you switch to a non-jta-data-source what does that change?  Also specify the details of the persistence unit:

I haven't tried that because I absolutely must have transaction support. I'd try it for you anyway, but now that I'm no longer able to reproduce this problem it seems moot. Do you want me to try anyway? Here is my full persistence.xml:

   <persistence-unit name="myDB">
      <provider>org.hibernate.ejb.HibernatePersistence</provider>
      <jta-data-source>jdbc/HIDDEN</jta-data-source>
      <properties>
         <property name="hibernate.show_sql" value="true"/>
         
        <!--  http://blog.hibernate.org/Bloggers/WebSphereRunningSeamsJEE5BookingExample -->
     <property name="hibernate.transaction.flush_before_completion" value="false"/>
         
        <property name="hibernate.cache.provider_class"
               value="org.hibernate.cache.HashtableCacheProvider"/>
        <property name="hibernate.dialect" value="org.hibernate.dialect.DB2Dialect"/>
        <property name="hibernate.transaction.manager_lookup_class"
               value="org.hibernate.transaction.WebSphereExtendedJTATransactionLookup"/>
      </properties>
         
   </persistence-unit>
</persistence>

I'm not specifying RESOURCELOCAL. Can you please explain what RESOURCELOCAL does? This is mentioned in the seam manual but not explained (maybe I should be looking at the JPA and/or hibernate documentation?)

You linked to your persistence.xml file above - could you provide your complete components.xml?

Here it is:

<components>
    <core:init jndi-pattern="@jndiPattern@" debug="@debug@"/>

    <core:manager conversation-timeout="120000"
                  concurrent-request-timeout="500"
                  conversation-id-parameter="cid"/>

    <persistence:managed-persistence-context name="entityManager"
             auto-create="true"
             entity-manager-factory="#{ebdManagerFactory}"/>

     <persistence:entity-manager-factory name="ebdManagerFactory" persistence-unit-name="myDB"/>                   
                 
     <transaction:ejb-transaction/>               

     <security:identity authenticate-method="#{authenticator.authenticate}"/>     

     <event type="org.jboss.seam.security.notLoggedIn">
         <action execute="#{redirect.captureCurrentView}"/>
     </event>
         
     <event type="org.jboss.seam.security.postAuthenticate">
         <action execute="#{redirect.returnToCapturedView}"/>
     </event>          
</components>

And the problematic class is here (I just spent 20 minutes trying to get that code to parse by the wiki, couldn't do it, so it's externally pasted... sorry).

[jguglielmin]

Has anyone been able to get this working on a Windows machine.  I am getting the same ClassCastException for EntityManagerFactory.  I have not included persistence-api.jar in any of my applications that I have been attempting to run on WAS6.1 (with feature pack for ejb3,JPA)

[ericjung2]

Answering my own question about the transaction-type attribute of RESOURCE_LOCAL, this is from the EJB 3.0 Persistence Specification PDF

6.2.1.2 transaction-type
The transaction-type attribute is used to specify whether the entity managers provided by the
entity manager factory for the persistence unit must be JTA entity managers or resource-local entity
managers. The value of this element is JTA or RESOURCE_LOCAL. A transaction-type of JTA
assumes that a JTA data source will be provided—either as specified by the jta-data-source element
or provided by the container. In general, in Java EE environments, a transaction-type of
RESOURCE_LOCAL assumes that a non-JTA datasource will be provided. In a Java EE environment, if
this element is not specified, the default is JTA. In a Java SE environment, if this element is not specified,
a default of RESOURCE_LOCAL may be assumed.

[jbalunas.jbalunas.jboss.org]

Ok - lets see....

Here are some ideas until I can get my websphere env back up to verify on windows.  I did not see this issue on Linux and think that it is similar to you not being able to reproduce it on Unix (after a restart). 

The examples I used (as you mention) did not mix EJB and non EJB components that use the persistence API.  I think that part of the problem is that two things are managing your entity manager and transactions.  You are in a JEE5 env, and using managed-persistence-context - this might conflict (they both may be managing Entity-Managers).  I will need to look further.

Here are some things to try:

• Try changing the managed-persistence-context name="entityManager" to a different name and use that different name in you non-ejb components.

• Try (as a temp test) setting transaction-type="RESOURCE_LOCAL" in the persistence.xml.  This is described in the chapter 8.2.2 (linked below).

• Along with the RESOURCE_LOCAL set the data source to non-jta... temporarily.

Chapter 8.2.2

[ericjung2]

I did not see this issue on Linux and think that it is similar to you not being able to reproduce it on Unix (after a restart).

The problem exists on both Windows and Unix. The restart fixes the problem on both platforms.

I think I've nailed down exactly how to reproduce this ... consistently. It appears that accessing the application from a browser with an expired session (forcing the Authenticator class, with its @In EntityManager, to be called again) consistently causes it.

I'm double- and triple-checking this on both OSs. Will report back shortly.

[ericjung2]

Here is the solution to get rid of java.lang.ClassCastException: org.jboss.seam.persistence.EntityManagerFactory incompatible with javax.persistence.EntityManagerFactory

1. Ensure <ear-project>/META-INF/ibmconfig/cells/defaultCell/applications/defaultApp/deployments/defaultApp/deployment.xml has *three* modules entries (your war, your jar with ejbs, and jboss-seam.jar). By default, you'll only have two. The file should look like this, with the filenames for the jar and ear appropriate for your project.


<?xml version="1.0" encoding="UTF-8"?>
<appdeployment:Deployment xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:appdeployment="http://www.ibm.com/websphere/appserver/schemas/5.0/appdeployment.xmi" xmi:id="Deployment_1219936444526">
  <deployedObject xmi:type="appdeployment:ApplicationDeployment" xmi:id="ApplicationDeployment_1219936444526" startingWeight="10" warClassLoaderPolicy="SINGLE">
    <modules xmi:type="appdeployment:WebModuleDeployment" xmi:id="WebModuleDeployment_1219936444526" startingWeight="10000" uri="my-war.war"/>
    <modules xmi:type="appdeployment:EJBModuleDeployment" xmi:id="EJBModuleDeployment_1219936444526" startingWeight="5000" uri="jboss-seam.jar"/>
    <modules xmi:type="appdeployment:EJBModuleDeployment" xmi:id="EJBModuleDeployment_1219937434401" startingWeight="5000" uri="my-jar.jar" />    
    <classloader xmi:id="Classloader_1219936444526" mode="PARENT_FIRST"/>
  </deployedObject>
</appdeployment:Deployment>


A few things to note about this file:

a. warClassLoaderPolicy="SINGLE" - I am not sure this is necessary

b. The numbers after WebModuleDeployment_, EJBModuleDeployment_, and Classloader_ come from the complete deployment.xml file. That file can be found at <WAS-install-dir>\sdp70\runtimes\base_v61\profiles\<app-server>\config\cells\cell-name\applications\<ear-name.ear>\deployments\<ear-project-name>\deployment.xml. This is the same file where you can ensure PARENT_LAST is set both of the WAR and the EAR since the admin console doesn't always work when setting these.

2. Create default ibm-application-ext.xmi and ibm-application-ext-pme.xmi files in the <ear>/META-INF folder (siblings to application.xml). If you're using RAD, this can be done by:

a. Open application.xml in RAD so you get the wizard.

b. On the Overview tab of the wizard, check "Shared session context". Click the save button on the toolbar. You should now have a ibm-application-ext.xmi file. Uncheck "Shared session context" and click save again. You'll now have a default ibm-application-ext.xmi.

c. On the Extended Services tab, check "Last participant support". Click the save button on the toolbar. You should now have a ibm-application-ext-pme.xmi file. Uncheck "Last participant support" and click save again. You'll now have a default ibm-application-ext-pme.xmi.

Rebuild and and restart twice. No more java.lang.ClassCastException: org.jboss.seam.persistence.EntityManagerFactory incompatible with javax.persistence.EntityManagerFactory error.

Eric

[ericjung2]

Here is the solution to get rid of java.lang.ClassCastException: org.jboss.seam.persistence.EntityManagerFactory incompatible with javax.persistence.EntityManagerFactory

1. Ensure <ear-project>/META-INF/ibmconfig/cells/defaultCell/applications/defaultApp/deployments/defaultApp/deployment.xml has *three* modules entries (your war, your jar with ejbs, and jboss-seam.jar). By default, you'll only have two. The file should look like this, with the filenames for the jar and ear appropriate for your project.


<?xml version="1.0" encoding="UTF-8"?>
<appdeployment:Deployment xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:appdeployment="http://www.ibm.com/websphere/appserver/schemas/5.0/appdeployment.xmi" xmi:id="Deployment_1219936444526">
  <deployedObject xmi:type="appdeployment:ApplicationDeployment" xmi:id="ApplicationDeployment_1219936444526" startingWeight="10" warClassLoaderPolicy="SINGLE">
    <modules xmi:type="appdeployment:WebModuleDeployment" xmi:id="WebModuleDeployment_1219936444526" startingWeight="10000" uri="my-war.war"/>
    <modules xmi:type="appdeployment:EJBModuleDeployment" xmi:id="EJBModuleDeployment_1219936444526" startingWeight="5000" uri="jboss-seam.jar"/>
    <modules xmi:type="appdeployment:EJBModuleDeployment" xmi:id="EJBModuleDeployment_1219937434401" startingWeight="5000" uri="my-jar.jar" />    
    <classloader xmi:id="Classloader_1219936444526" mode="PARENT_FIRST"/>
  </deployedObject>
</appdeployment:Deployment>


A few things to note about this file:

a. warClassLoaderPolicy="SINGLE" - I am not sure this is necessary

b. The numbers after WebModuleDeployment_, EJBModuleDeployment_, and Classloader_ come from the complete deployment.xml file. That file can be found at <WAS-install-dir>\sdp70\runtimes\base_v61\profiles\<app-server>\config\cells\cell-name\applications\<ear-name.ear>\deployments\<ear-project-name>\deployment.xml. This is the same file where you can ensure PARENT_LAST is set both of the WAR and the EAR since the admin console doesn't always work when setting these.

2. Create default ibm-application-ext.xmi and ibm-application-ext-pme.xmi files in the <ear>/META-INF folder (siblings to application.xml). If you're using RAD, this can be done by:

a. Open application.xml in RAD so you get the wizard.

b. On the Overview tab of the wizard, check "Shared session context". Click the save button on the toolbar. You should now have a ibm-application-ext.xmi file. Uncheck "Shared session context" and click save again. You'll now have a default ibm-application-ext.xmi.

c. On the Extended Services tab, check "Last participant support". Click the save button on the toolbar. You should now have a ibm-application-ext-pme.xmi file. Uncheck "Last participant support" and click save again. You'll now have a default ibm-application-ext-pme.xmi.

Rebuild and and restart twice. No more java.lang.ClassCastException: org.jboss.seam.persistence.EntityManagerFactory incompatible with javax.persistence.EntityManagerFactory error.

Eric

[pmuir]

Please post this in JIRA :-)