Looks like the persistence.xml was read (server.log contains "Read persistence.xml for maj2e-lafr-dev"), however, jboss.jdbc-driver.ifxjdbc_all_jar seems to have a problem (look for keyword "missing" in server.log). Which version of JDBC jboss.jdbc-driver.ifxjdbc_all_jar implement? Read this link about using JDBC version 4 drivers (includes tips for using older drivers also) on JBoss AS 7.

Its probably a good time for you to enable TRACE logging for org.jboss.jpa + org.jboss.as.jpa, which will give more information about what is occuring (see the troubleshooting section in above doc link). That will give a better idea of what is going wrong during the search for the persistence unit. Post the server.log with the TRACE logging output.

By default, classes in one ejb-module do not have access to classes (and other resources) in other ejb-modules in the same EAR (see §EE.8.3.2 of the JEE6 spec). Historically, earlier versions of JBoss have not enforced this.

You can resolve this problem by adding manifest classpath entries to your ejb-jar files, or defining deployment domains using a jboss-classloading.xml file.

"By default this is set to false, which allows the sub-deployments to see classes belonging to other sub-deployments within the .ear.

If the ear-subdeployments-isolated is set to false, then the classes in web.war can access classes belonging to ejb1.jar and ejb2.jar. Similarly, classes from ejb1.jar can access classes from ejb2.jar (and vice-versa)."

My war-files are web-services calling only session beans and not other webservices.

I had some classloading issues right at the beginning, because I had simple java modules in EAR root and listed in application.xml.

I moved those simple jar files to EAR/lib and CNFE went away.

I also found a hint to move the ejb-entity.jar to the lib directory. But this also did not solve the unsuccesful deployment.

See the attached server.log file with TRACE enabled for the packages requested.

Everything seems to be fine, the deployment unit is found, but all of a sudden the deployment is aborted.

at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor$1.handle(ModuleJndiBindingProcessor.java:169)

at org.jboss.as.ee.component.ClassDescriptionTraversal.run(ClassDescriptionTraversal.java:54)

at

I don't have the code in front of me right now, so can't say for sure. But do you have any <resource-ref> or @Resource entries in your application which might be using foo#bar kind of syntax? Or maybe even ejb-ref or ejb-local-ref or @EJB with such syntax?

The mappedName attribute of the @Resource annotation is explicitly non-portable.

A product specific name that this resource should be mapped to.

Whenever you use a JNDI ENC name, you must map that value somewhere to the real resource. On JBoss this is typically done in the jboss.xml (renamed to jboss-ejb3.xml in AS7.x) file, which must be in the META-INF directory of the associated ejb-jar file.

That said, I can't really say if it has anything to do with:

"Can't find a deployment unit named null in subdeployment "ejb-session-common.jar" of deployment "maj2e-lafr-dev.ear"

but I expect that it can cause the failure of that particular subdeployment and you will have to deal with it at some point.