EJB3 Local and Remote interfaces

up vote9down votefavorite 3

I understood that Local interface is designed for clients in the same container's JVM instance and remote interface is designed for clients residing outside the EJB container's JVM. How about the web application client which is not reside (or packaged) in the same .ear but reside on the same Java EE server? java jvm ejb-3.0 share|improve this question edited Dec 15 '11 at 22:37 Arjan Tijms 19.3k53472 asked Dec 15 '11 at 20:31 Thurein 8081817

2   Why wouldn't you put the webapp in the same EAR? The point of an EAR is precisely to contain both the web and EJB parts of an application. –  JB Nizet Dec 15 '11 at 20:34 What do you mean by the same J2EE server? Is it deployed on the same instance, in the same domain?–  jFrenetic Dec 15 '11 at 20:35 EAR is maintained and deployed separately and other WAR wants to use some business methods from the ejb reside in the EAR. J2EE server means they will be deployed on the same instance. –  Thurein Dec 15 '11 at 21:00  In my case, on Glassfish 3.1, deploying web and ejb module separately, on their own (no ear involved), on the same instance and using @EJB annotation to inject ejbs into JSF managed-beans works. – Bhesh Gurung Dec 15 '11 at 22:15  add comment

4 Answers

activeoldestvotes

up vote11down voteaccepted

Officially @Local annotated beans can only be accessed if they're in the same application. A .war deployed separately from an .ear (or other .war or other .jar EJB) is a different application, even when deployed to the same application server instance. There's thus no guarantee that the code in your .war can call @Local EJB beans that are defined in the .ear. However, in practice in nearly all application servers this just works. There's a request for the EJB 3.2 spec to officially support local cross-application calls:http://java.net/jira/browse/EJB_SPEC-22 share|improve this answer edited Dec 15 '11 at 23:12 Bhesh Gurung 19.6k72564 answered Dec 15 '11 at 22:47 Arjan Tijms 19.3k53472

4   I feel somewhat sad to be the only one who voted on this feature... Everyone - feel free to join and just click 'vote' on this JIRA request ;-) –  Piotr Nowicki Dec 15 '11 at 23:15 It might be quite hard to have 100% working cross-application (cross ClassLoader!) calls. Let ClassLoader 1 has class A and ClassLoader 2 has class A (another copy). Passing object A via local interface will cause ClassCastException because there are two copies of the same class. An EAR has its own sometimes isolated ClassLoader. –  Piotr Gwiazda Sep 4 '12 at 20:39 Yes, the class loading isolation might be the problem here. It would still work for classes from the JDK and possibly for (interface) classes from the AS (depending on how the AS does modularization of those). Many users will probably not understand this limitation and it might become one of the new puzzlers in Java EE. – Arjan Tijms Sep 4 '12 at 21:37  add comment

up vote2down vote

Local interfaces are to be used in communication within the same application. It doesn't necessarily mean JVM. The point is: even within the same JVM instance, on the same server, two different applications cannotcommunicate using local interfaces (which means local and no-interface views). If you have a web component (WAR) as well as a business component (EJB-JAR) which is in the same application, the most intuitive and straightforward solution is to package them in one EAR or in one WAR (since Java EE 6). share|improve this answer edited Aug 6 at 12:17 David Victor 519417 answered Dec 15 '11 at 22:40 Piotr Nowicki 6,29831238

1   Yes but this is all just theory. In practice you have a big application with multiple WARs (i.e. partner, customer and administration portal application), calling the same EJBs. For deployment/less downtime reasons you would want to package these WARs separately, as many people do. –  bozo May 7 '12 at 9:41 Agreed - I also don't like this idea and the cumbersome EAR approach as well, but it's the officially suggested solution. –  Piotr Nowicki May 7 '12 at 10:21 1   Don't get me started on JEE people. The whole thing is a job security project. We've been using it in complex projects for years, and I must say that we were 10 times more productive in PHP. But nowadays the PHP is "uncool" with various certifications people, and you have to have a certificate to sell toilet paper today, so we all have to suffer bloated bullsh*t that doesn't do anything properly. It reminds me of F-35. ;) –  bozo May 9 '12 at 13:45 add comment