7
votes

I have an existing project that I am in need of configuring different. This needs to happen without major code changes. I am actually hoping I could somehow do this only with configuration. I have spent the past 2 to 3 days reading everything I can find on this issue. I understand the glassfish classloaders, and what is available to me.

I have a current sample project that has an EJB which defines a @Local interface. The ejb is deployed inside an ejb-module as an ejb-module into the glassfish domain. Now I am trying to find a way for another application which was deployed as an ear into the same domain, to be able to access that EJB via it's local interface.

I have read documentation that says this is not possible. Then I have seen posts on here at StackOverflow, and other's on the web saying it is possible. But, I cannot find the actual solution.

With investigation, I have realised that the @Local EJB does not register itself onto jndi (atleast according to the logs), if I use the glassfish JNDI browser, I also do not see it visible. So it makes sense to me, that either it's not possible, or the deployment of the EJB project is at fault, and somehow I need to expose it.

@Remote is a possibility, if it can be by reference, and no performance overhead. But the preferred method allowing @Local EJB access is really the ultimate need.

Does anyone know what I would need to do to expose the @Local EJB to another application? Or is this plainly not possible?

I am using Glassfish 2.1 With EJB 3.0

If Glassfish 2.1 can handle EJB 3.1 I would be willing to move to it if it provided this capability, but I doubt it's that easy.

Please assist. Thank you.

I am adding a bounty. To complete the bounty, it would be required to run 2 ear applications in the same domain, where A.ear contains an @Local EJB that is used as well by the application in a B.ear.

1
Additional info: docs.oracle.com/cd/E18930_01/html/821-2418/beadh.html#beadl . This is for Glassfish 3.1 but the documentation states the same thing in 2.1. I cannot get this to work.guyumu
maybe you should explain your motivation for doing this, but as you already mentioned, there are other threads here dealing with the same problem, I'd just agree with jtahlborn answer: stackoverflow.com/questions/5681197/… (and would not try to do that)Peter Butkovic

1 Answers

5
votes

The link @Peter gave you almost solves your problem. (link)

One trick which needs to be done to solve @Xavier's problem is to provide common.jar to both ears in the same version (loaded by the same class loader). If you do it, the class cast exception will not be thrown and you will be able to use the ejb with local interface.

To do it you need to put common.jar into glassfish/domains/domain1/lib folder (substitute domain1 with you domain name). This way this jar will be loaded by a Glassfish's shared class loader.

I made a quick test with Eclipse and Glassfish 3 with following structure:

package com.example;

JarShared
 - @Local class Server

EarServer
 - EjbServer
    - @Stateless class ServerBean implements Server

EarClient
 - EjbClient
    - @Stateless @LocalBean class ClientBean

Lookup from ClientBean:

InitialContext ic = new InitialContext();
Server server = (Server) ic.
    lookup("java:global/EarServer/EjbServer/ServerBean!com.example.Server");

I did not get ClassCastException and I could call sample method from ServerBean.

Important notes:

  • both EarServer and EarClient should not contain JarShared in lib folder, they should reuse the one which is in domains lib folder
  • remember to restart Glassfish after adding JarShared to it.
  • to make both ejb projects compile you must add JarShared to their build paths, but nothing more

If you have questions, post a comment.