2

I'm using EJB 3.1 and Wildfly 8.2.Final

Ear 1 :

jar-impl with Bean1 (where I execute the lookup of Interface2)

lib /
    jar with Interface2

Ear 2 :

jar-impl with Bean2

lib / 
    jar with Interface2 and META-INF/ejb-jar.xml

I would like to execute the lookup in the Bean1 of Interface2 annotated with @Local.

"Look up" code: 

Properties jndiProp = new Properties();
InitialContext ctx = new InitialContext(jndiProp);
Object bean = ctx.lookup(JNDI);
Interface2 interface = (Interface2) bean;

If I annotate Interface2 with @Remote, the wildfly at startup writes: 

    java:global/c4c.commons.backend/c4c.commons.backend-impl/Bean2!eu.dedalus.c4c.commons.service.Interface2
    java:app/c4c.commons.backend-impl/Bean2!eu.dedalus.c4c.commons.service.Interface2
    java:module/Bean2!eu.dedalus.c4c.commons.service.Interface2
    java:jboss/exported/c4c.commons.backend/c4c.commons.backend-impl/CMSRemoteServiceBean!eu.dedalus.c4c.commons.service.Interface2
    java:global/c4c.commons.backend/c4c.commons.backend-impl/Bean2
    java:app/c4c.commons.backend-impl/Bean2
    java:module/Bean2

Having

JNDI = "ejb:c4c.commons.backend/c4c.commons.backend-impl/Bean2!eu.dedalus.c4c.commons.service.Interface2"

Everything goes well.. but when I annotate Interface2 with @Local witch is the thing i want to do, the wildfly at startup writes: 

java:global/c4c.commons.backend/c4c.commons.backend-impl/Bean2!eu.dedalus.c4c.commons.service.Interface2
    java:app/c4c.commons.backend-impl/Bean2!eu.dedalus.c4c.commons.service.Interface2
    java:module/Bean2!eu.dedalus.c4c.commons.service.Interface2
    java:global/c4c.commons.backend/c4c.commons.backend-impl/Bean2
    java:app/c4c.commons.backend-impl/Bean2
    java:module/Bean2
  • If i execute the lookup with "ejb:" prefix goes well, but when i try to invoke any of the methods of the bean, it throws: “JBAS014151: Could not find view ”

  • If i execute the lookup with "java:global/" prefix goes well, but when i try to assing to the interface i get a java.lang.ClassCastException: HelloWorldRemote$$$view4 cannot be cast to HelloWorldRemote

    This may be because i have two interfaces "Interface2" in two different ears ? But why with the remote the error does not occur?

    It's useful to use the @Local invocation instead of the @Remote, for local invocation? I've read several things, the better one is this: https://coderanch.com/t/79249/application-servers/Local-EJB-calls-separate-ear

    But still i have confused ideas. Please in the answer provide documentation links to official docs.

Gaetano Piazzolla
  • 1,388
  • 1
  • 16
  • 31

1 Answers1

2

See EJB 3.x specification for clarification, e.g. EJB 3.2 spec section 3.2.2:

Access to an enterprise bean through the local client view is only required to be supported for local clients packaged within the same application as the enterprise bean that provides the local client view. Compliant implementations of this specification may optionally support access to the local client view of an enterprise bean from a local client packaged in a different application. The configuration requirements for inter-application access to the local client view are vendor-specific and are outside the scope of this specification. Applications relying on inter-application access to the local client view are non-portable.

Using the remote interface will usually need marshalling and unmarshalling of the method parameters and the returning object along with a clear classloader separation.

Use remote EJBs if you need access from another JVM (e.g. remote client) or another application scope within the same application server. Use local EJBs if you want to provide access to an EJB within your application scope, only.

Frito
  • 446
  • 2
  • 12
  • Any known containers that support local invocation between two different applications? – Bruno Medeiros Nov 05 '18 at 08:41
  • I don't know any and I can't see a valid reason why this is needed. You will end up with ClassCastExceptions due to different classloaders. Wildfly has a feature, the other way around: you can configure the EJB subsystem to use optimized in-vm remote calls ( see [in-vm-remote-interface-invocation-pass-by-value](https://wildscribe.github.io/WildFly/13.0/subsystem/ejb3/index.html#attr-in-vm-remote-interface-invocation-pass-by-value) ). But you will face the same problems: the client and the EJB need the same class definitions (classloader). It's better to rethink you EJB design. – Frito Nov 05 '18 at 14:41
  • Thanks for the reply, @frito, but if I'm not able to achieve such a simple in-VM integration somehow, I'm probably migrating to a different technology. The main advantage in see in using EJBs is to be able to put many EJBs and WARs in the same container and deploy them independently. Something like this would be enough: https://github.com/jboss-developer/jboss-eap-quickstarts/tree/539f63eeae4e61af5a6f4e3de373b219bce365f9/inter-app (Just replacing AppA by and EAR/EJB instead of a WAR). Why is this so "wrong"? – Bruno Medeiros Nov 05 '18 at 17:45
  • Regarding your provided link: "independently" using shared resources, which is not so independent at all. Shared resoruces are used to avoid the classloading problems mentioned above. You can do the same with EJB only, too. CDI is used here just to provide the "seamless" injection. If you want to design your application this way, you must be very familiar with CDI and EJB. A looser coupling can be achieved using remote EJBs (interfaces and DTOs in every EAR) or even REST between EAR applications without using shared resources. – Frito Nov 06 '18 at 08:03
  • Thanks again for the reply, that's basically what I'm trying to do, find a way to have CDI injecting remote views "seamlessly" (from a client's perspective, they should look like @Local views). About the link I provided, it is just an example for the technical challenge, I'll not have a circular dependency. My plan is to have a "core" EAR/EJBs and multiple WARs connecting to this "core" (not using RESTful, I want a binary protocol) and I want all the WARs to potentially be deployed separately. If you have any ideas to achieve such a design, I'd love to hear :) – Bruno Medeiros Nov 06 '18 at 08:35