testejb.ear needs to provide a copy of all of the home and businessinterface classes that it references from testfileejb.ear.
Typically, these classes would be made available in testfileejb-api.jar in the lib directory of testejb.ear.
JBossAS7.x/WildFly has (mostly) spec compliant class loading by default, meaning classes in one ear are not normally visible to classes in another ear. Earlier versions of JBossAS had to be configured to use spec compliant class loading.
There are other ways of accomplishing the same thing, but that would require you to read and understand most of Chapter EE.8 "Application Assembly and Deployment" of the "Java™ Platform, Enterprise Edition (Java EE) Specification, v6", and/or https://docs.jboss.org/author/display/AS72/Class+Loading+in+AS7.
Thanks for you quick response. I have already added the testfileejb-api.jar in the lib directory of testejb.ear but still facing the issue.
In testfileejb.ear, I am using java:global/FileService as a jndi name. Also I am using the same to reference it from testejb.ear, but it seems server is searching for "java:comp/env/FileService".
Please attach the complete server.log.
I suspect that there is no actual object at java:global/FileService.
Sorry, I've just noticed that you're using jboss.xml. This has now been replaced by jboss-ejb3.xml which you must use now.
From what I can see from your log, your ejb-ref will then look something like:
<ejb-ref> <ejb-ref-name>FileService</ejb-ref-name> <lookup-name>java:jboss/exported/filemanager-as-ear-22.214.171.124/filemanager-as-ejb-126.96.36.199/FilemanagerService!com.myapp.infra.filemanager.appservice.ejb.FilemanagerServiceHome</lookup-name> </ejb-ref>
You code does indeed lookup java:comp/env/FileService. The ejb-ref decouples your java code from the real JNDI name of the EJB, which gets linked for you via the jboss-ejb3.xml file. You will see this pattern replicated for all the different *-ref-name elements. There is always an implicit java:comp/env prefix, unless a fully qualified name is provided, such as java:app/FileService (an ejb-ref-name, not a lookup-name). This last bit is new in JavaEE 6.
Thanks for your response. We use xdoclet ejb2.1 spec which generates jboss.xml. But since it is now ignored by Jboss as 7 do I need to migrate first from ejb2.1 to ejb 3 ?
Strictly speaking it is not necessary to migrate to EJB3. However, you will likely find life much easier in the future if you bite the bullet and do it now. You will probably find it consists mainly of removing stuff (such as home interfaces). This assumes that you do not have any CMP entity beans.
If you need to defer this then I suggest building your jboss-ejb3.xml file using the generated jboss.xml as a basis. Most of it will be the same.
1 of 1 people found this helpful
Remove the fourth line containing:
You could change it to:
but it may be easier to use the container generated defaults for the time being.