aspose file tools*
The moose likes Glassfish and the fly likes Remote EJB lookup without including Remote interface to client's classpath Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » Glassfish
Bookmark "Remote EJB lookup without including Remote interface to client Watch "Remote EJB lookup without including Remote interface to client New topic
Author

Remote EJB lookup without including Remote interface to client's classpath

Justas Gud
Greenhorn

Joined: Jan 10, 2014
Posts: 2
So, yeah, I'm trying to do a remote EJB lookup without including Remote interface to client's classpath.

In fact it's not really a remote EJB at the moment, but it might some day become remote in a sense of where it's executed, so it's remote for me now.

Whats there?

An interface:


An EJB bean:





ISomePlugin is deployed to a simple jar, lets call it PluginsFramework.jar

SomePlugin.ear
--> SomePlugin_ejb.jar (ejb jar)
--> PluginsFramework.jar

And then I lookup SomePluginEJB like that:


Client is deployed in EAR like that:
PluginClient.ear
--> PluginsFramework.jar
--> Client_ejb.jar (ejb jar)

When I try to lookup a Local interface, I get this:

When I try to lookup a Local interface, I get this:


Class and package names are ommitted for obvious reasons

What I think is that EJB lookup method in Client unnecessarily tries to cast the EJB to its remote interface before actually returning any object.
Is it supposed to to so? I don't need remote interface, I only need the basic interface ISomePlugin.

This exact method worked in Weblogic Server, but we're moving to Glassfish and found this issue
K. Tsang
Bartender

Joined: Sep 13, 2007
Posts: 2531
    
    8

The lookup coding looks ok to me. Yet the @Local and @Remote annotations should be in the interface level not the class level.







Also the @Stateless mappedName value should be the same as that context lookup

For the mapped naming you should able to check them out in the JNDI settings in Glassfish if I recall correctly.


K. Tsang JavaRanch SCJP5 SCJD/OCM-JD OCPJP7 OCPWCD5 OCPBCD5
Justas Gud
Greenhorn

Joined: Jan 10, 2014
Posts: 2
Thanks for your reply!
You're right, I had @Remote and @Local annotations in respective interfaces, right where you are saying they should be. Putting them into class was an experiment

The problem is not that lookup cannot find JNDI name - it finds it.
Problem is that ctx.lookup tries to cast found object to a remote interface (SomePluginEJB in my example) and does not find it
I deliberately chose NOT to include it in client EAR because the whole architecture is meant to support multiple plugins (EJBs deployed in EARs) using only metadata (lists of global JNDI names) and common interface ISomePlugin.
K. Tsang
Bartender

Joined: Sep 13, 2007
Posts: 2531
    
    8

Since you say the lookup is successful only casting the problem, try changing the ctx from InitialContext (the class) to Context (the interface).

Also I believe I read local interface may not be accessible by java clients from here
 
 
subject: Remote EJB lookup without including Remote interface to client's classpath