Passing remote interface

Hi,
Is it allowed to pass the reference to the remote interface of a bean from client c1 to client c2?
Is client c2 able to access the bean, even if client c1 and client c2 are running on different machines?
Regards,
Ueli

In continuation to my earlier message, I
In the other bean, I have the following method -
public void passCountObject(EJBObject eO) {
try {
((CountObject)eO).toTest();
} catch (RemoteException e2) {
e2.printStackTrace();
}I am getting an error
java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: com.ibm.ejs.container.BeanNotReentrantException: TX_IN_METHOD
Where am I going wrong?
Thanks in advance.
Regards,
Ashish A.

Similar Messages

  • Obtain remote interface using PortableRemoteObject

    Hello,
    I have sample code from "Applying Enterprinse JavaBeans" book.
    Plan plan = (Plan)PortableRemoteObject.narrow(
    it.next(), Plan.class);
    ... plan.getPlanInfo() ...
    here:
    Plan is a remote interface of the entity bean (e.g.. MyPlanBean).
    getPlanInfo() is one of the business methods in Plan.
    In this case, the remote interface is obtained by using PortableRemoteObject.narrow(...). could anyone explane the creation using the concept of life cycle of an entity bean instance? That means if any ejbCreate() methods or any callback methods are involved in the creation or not?
    Thanks.

    I am not sure if you are doing the right thing.
    The home interface represents the life-cycle methods of the component (create, destroy, find) while the remote interface represents the business method of the bean.
    Clients use the bean's home interface to obtain references to the bean's remote interface. Following is the life-cycle of
    entity bean creation:
    1. Client invokes create() on home object
    2. Home object allocates a bean from the free pool
    3. Home object passes on the create args to the ejbCreate(..)
    in the bean
    4. the bean inserts a row into the database table
    5. the bean returns the primary key of the row to the home object
    6. The container creates an EJB object for the bean and populates
    it with the primary key
    7. The home object calls the ejbPostCreate() on the bean
    8. The home object returns the remote reference to the EJB
    object back to the client
    9. Client now makes business calls to the bean instance.
    No bean instance is associated with the EJB object
    10. EJB object communicates to the container that a bean
    instance is needed
    11. The container allocates a bean instance from the pool
    and associates it with the EJB object (ejbActivate() is called)
    12. home object invokes the ejbLoad method on the bean to
    tell it to load itself(BMP) or to tell it that it has just been
    loaded (CMP)
    13. the bean uses the primary key stored in the EJB object to load the approp row's data from the database
    14. EJB object dispatches the client's business method call to the
    bean
    Hope this helps.
    Regards,
    Sun-DTS

  • Get a remote interface from a local instance

    hi,
    I want to construct a bean locally on a server and then I want to pass the remote interface for that constructed bean back to a client. Is this possible?
    Thanks

    Yes. Take a look at SessionContext class. You can't construct a bean yourself, as its life is managed by container.
         * Obtain an object that can be used to invoke the current bean through
         * the given business interface.
         * @param businessInterface One of the local business interfaces
         *        or remote business interfaces for this session bean.
         * @return The business object corresponding to the given business
         *         interface.
         * @exception IllegalStateException Thrown if this method is invoked
         *         with an invalid business interface for the current bean.
        <T> T getBusinessObject(Class<T> businessInterface) throws IllegalStateException;

  • Session Bean - Why the Remote Interface?

    Hi,
    I have a stateless session bean that takes a serializable object
    as a parameter and passes it to an entity bean to persist. My question
    is: why should I put the method (addxxx) in the remote interface of my
    session bean? Why can't I just put it in the home interface so that I
    don't have to instantiate the EJB object first, then call the method?
    Any pros/cons? Thanks.
    -Linus

    You could use the Home.create() method. Generally, the home interface is
    used to manage the lifecycle of a EJB. Theoretically, you are right in your
    thinking because a stateless session bean does not preserve any state and is
    alive for the duration of a method call.
    "Linus" <[email protected]> wrote in message
    news:[email protected]..
    Hi,
    I have a stateless session bean that takes a serializable object
    as a parameter and passes it to an entity bean to persist. My question
    is: why should I put the method (addxxx) in the remote interface of my
    session bean? Why can't I just put it in the home interface so that I
    don't have to instantiate the EJB object first, then call the method?
    Any pros/cons? Thanks.
    -Linus

  • How to specify a base class for Remote Interface in Workshop 9.2? -- URGENT

    Hi,
    I am trying to create a UUP EJB in WebLogic 9.2 workshop. I am using @FileGeneration to create my home & remote interfaces. And the generated remote interface is extending javax.ejb.EJBObject;I want my remote interface to extend com.bea.p13n.property.EntityPropertyManager which in turn implements javax.ejb.EJBObject. Can someone tell how i can do it in Workshop?.
    I came across Predefined Variable: remote.baseClass and as per docume
    ntation..."If specified, the value of this variable will be used as the base class for all generated remote classes. Where i should specify it?. @FileGeneration does nt have any option for it. Any help is grtly appreciated.
    Following are my code snippets:
    IMPL Class
    @FileGeneration(remoteClass = Constants.Bool.TRUE,remoteHome = Constants.Bool.TRUE, localClass = Constants.Bool.FALSE, localHome = Constants.Bool.FALSE,remoteClassName = "MyEntityPropertyManager",remoteHomeName = "MyEntityPropertyManagerHome")
    public class MyEntityPropertyManagerImpl extends GenericSessionBean implements
              SessionBean {
    //code
    }

    This question was posted to both the bea.workshop.developer.general and weblogic.developer.interest.workshop (I had replied to the later on 10/19); after seeing an identical question today on this list want to include a reference to that reply here:
    http://forums.bea.com/bea/message.jspa?messageID=600044925&tstart=0
    -Rob

  • EJB3 - More than one remote interface for Session Bean?

    Hi,
    Is it possible in EJB3 to have more than one remote interface for a SessionBean?
    I have seen it posetd on here that it is possible but never been able to find any other information.
    Using JBoss as my App Server, I have deployed an App, where a SessionBean is defined as implementing 2 interfaces, both of which are annotated using @remote.
    However when I examine the JBoss JMX Console, Global JNDI Namespace only one remote interface is listed, and indeed it is the first one defined in the SessionBean.
    Considering I use a String similar to (MyApp/MyBean/remote) to do the JNDI lookup, this would indicate that it is not possible to have more than one remote interface.
    1. Is this a JBoss specific limitation?
    2. Is there another way of performing the JNDI lookup?
    Thanks,
    Alan.

    Hi,
    Thanks for prompt response! I tried the suggestion in my application, and the output from JBoss JMX Console was
    +- XXXBean (class: org.jnp.interfaces.NamingContext)
      |   |   +- remote (proxy: $Proxy291 implements No ClassLoaders found for: xxx.xxx.xxx.xxx.xxx.Remote1 (no security manager: RMI class loader disabled))Again only displaying the remote interface that is first in the @remote ({ Remote1.class , Remote2.class}) list. This would lead me to believe that JBoss does not support this.
    Can anyone confirm this?
    Alan.

  • Super interfaces on EJB 3.0 Remote interface in OC4J 10.1.3

    We are implementing (on OC4J 10.1.3) an EJB 3.0 Stateless Session Bean with 2 business interfaces (remote and local) both of which extend an inteface we have defined in our system.
    When we look up the local interface we see our interface in the bean.
    When we look up the remote interface we do not see our interface in the bean.
    Any ideas?
    Thanks,
    Ed Dirago
    Computer Sciences Corp.
    FAA TFMS System

    The EJB 3.0 Remote Business references are not directly stored in CosNaming. EJB 3.0 Remote references do not have the cross-vendor interoperability requirements that the EJB 2.x Remote view had.
    You can still access Remote EJB references from a different JVM as long as the client has access to SJSAS naming provider. Please see our EJB FAQ for more details :
    https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html

  • SJSAS 9.1 does not expose EJB 3.0 remote Interface via JNDI

    I have successfully deployed a simple Stateful EJB 3.0 bean (CartBean, like the one in the Java EE 5 tutorial remote interface Cart) on SJSAS 9.1, located on machine host1.
    After I deployed the CartBean, I browsed the SJSAS and noticed the existence of the following JNDI entries:
    ejb/Cart
    ejb/Cart__3_x_Internal_RemoteBusinessHome__
    ejb/Cart#main.Cart
    ejb/mgmt
    ejb/myOtherEJB_2_x_bean ( +myOtherEJB_2_x_bean+ is a different 2.x bean that I have deployed as well)So, I am trying to access the remote interface of the CartBean from a remote machine, host2. The client application is a Java-standalone client.
    I am using the Interoperable Naming Service syntax: corbaname:iiop:host1:3700#<JNDI name>
    The problem is that the remote interface of the bean does NOT seem to be available via JNDI. I get the javax.naming.NameNotFoundException when I try to do a lookup like:
    corbaname:iiop:host1:3700#ejb/Cart
    On the other hand, the following lookups succeed:
    corbaname:iiop:host1:3700#ejb/mgmt
    corbaname:iiop:host1:3700#myOtherEJB_2_x_bean
    and also the following succeeds:
    corbaname:iiop:host1:3700#ejb/Cart__3_x_Internal_RemoteBusinessHome__So it seems like the Remote interface is not available via JNDI, rather only some internal SJSAS implementation (the object returned from the ejb/Cart__3_x_Internal_RemoteBusinessHome__ lookup is of type: com.sun.corba.se.impl.corba.CORBAObjectImpl
    Why is this happening? I know there used to be a bug in Glassfish, but I thought it had been fixed since 2006.
    Many thanks in advance, any help would be greatly appreciated.

    The EJB 3.0 Remote Business references are not directly stored in CosNaming. EJB 3.0 Remote references do not have the cross-vendor interoperability requirements that the EJB 2.x Remote view had.
    You can still access Remote EJB references from a different JVM as long as the client has access to SJSAS naming provider. Please see our EJB FAQ for more details :
    https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html

  • Multiple inheritance in remote interfaces for EJB 3.0 session beans on Webl

    Hi All,
    We started migration from EJB 2.1(WLS 8.1) to EJB 3.0(WLS 10.3.2) and identified few serious problems. One of them is related with multiple business interfaces inheritance. I wrote simple example that presents point of the problem.
    we have session bean AImpl:
    +@Stateless(name="A")+
    +@Remote({A.class})+
    +@TransactionAttribute(TransactionAttributeType.REQUIRED)+
    +public class AImpl implements A {+
    +@Override+
    +public void writeA() {+
    System.out.println("A");
    +}+
    +@Override+
    +public void writeB() {+
    System.out.println("B");
    +}+
    +@Override+
    +public void writeC() {+
    System.out.println("C");
    +}+
    +}+
    with remote interface A:
    +@Remote+
    +@JNDIName(A.JNDI_NAME)+
    +public interface A extends B, C {+
    public static String JNDI_NAME = "A_JNDI_NAME";
    void writeA();
    +}+
    As you can see A extends B, and C. Definition of both interfaces is very simple:
    +public interface B {+
    void writeB();
    +}+
    +public interface C {+
    void writeC();
    +}+
    Everything looks nice until we want to invoke some method on AImpl bean. For above implementation code:
    A a = ctx.lookup(A. JNDI_NAME);
    a.writeA();
    a.writeB();
    a.writeC();
    writes down ”A \n B” and throws exception:
    caused by: java.lang.NoSuchMethodException: pl.gov.arimr.zszik.bazowe.slowniki.ejb.A_vt0zts_AImpl_1032_WLStub.*writeC()*
    at java.lang.Class.getMethod(Class.java:1605)
    at weblogic.ejb.container.internal.RemoteBusinessIntfProxy.getTargetMethod(RemoteBusinessIntfProxy.java:165)
    at weblogic.ejb.container.internal.RemoteBusinessIntfProxy.invoke(RemoteBusinessIntfProxy.java:57)
    so.. in stub generated by WLS there is no method from interface C ! What more interesting after small change in interface A rely on change in interface implementation order from B, C to C, B (+public interface A extends C, B {+) server writes down only A and I have stack like below:
    Caused by: java.lang.NoSuchMethodException: pl.gov.arimr.zszik.bazowe.slowniki.ejb.A_vt0zts_AImpl_1032_WLStub.*writeB()*
    at java.lang.Class.getMethod(Class.java:1605)
    at weblogic.ejb.container.internal.RemoteBusinessIntfProxy.getTargetMethod(RemoteBusinessIntfProxy.java:165)
    at weblogic.ejb.container.internal.RemoteBusinessIntfProxy.invoke(RemoteBusinessIntfProxy.java:57)
    After this experience I came up with suspicion that Weblogic 10.3 does not support inheritance from multiple interfaces in one “generation”. Instead of that it takes only the first interface from the list.
    Does anybody have some experience with such a situation? maybe someone have an idea how to work around this problem?

    This is Not Supported in WebLogic that the Remote Interface extends other Interfaces. Because Annotation Processor just looks up inside the implemented interface methods. The actual interface which is Implemented by the Bean Class. So the Methods declared inside the Interface B and Interface C will be ignored and will not be available as part of the generated Stubs. Thats why u are getting NoSuchMethodError.
    You can even contact Oracle Support on this...there are 3-4 Cases on it. And the Solution is Work As Designed.
    Workaround is : edit your interface A as following
    Declare all the Business Methods only in the Remote Interface and not inside it's Super Interfaces.
    Example:
    @Stateless(name="A")
    @Remote({A.class})
    @TransactionAttribute(TransactionAttributeType.REQUIRED)
    public class AImpl implements A {
    @Override
    public void writeA() {
    System.out.println("A");
    @Override
    public void writeB() {
    System.out.println("B");
    @Override
    public void writeC() {
    System.out.println("C");
    @Remote
    @JNDIName(A.JNDI_NAME)
    public interface A extends B, C {
    public static String JNDI_NAME = "A_JNDI_NAME";
    void writeA();
    void writeB();
    void writeC();
    Thanks
    Jay SenSharma
    http://jaysensharma.wordpress.com (WebLogic Wonders Are Here)

  • A problem while getting a EJB remote interface from SJSAS 9.0

    I hava deployed a session bean in SJSAS 9.0
    I wrote some codes to get the remote interface as follow:
    Context ctx = null;
    Hashtable env = new Hashtable();
    env.put ("java.naming.factory.initial","com.sun.jndi.cosnaming.CNCtxFactory");
    env.put("java.naming.provider.url","iiop://127.0.0.1:3700");
    try {
    ctx = new InitialContext(env);
    } catch (NamingException ex) {
    ex.printStackTrace();
    try {
    Object cs =ctx.lookup(ejb.MySessionBean);
    } catch (NamingException ex) {
    ex.printStackTrace();
    A exception occured during the lookup operation.
    javax.naming.NameNotFoundException [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]
    at com.sun.jndi.cosnaming.ExceptionMapper.mapException(ExceptionMapper.java:44)
    at com.sun.jndi.cosnaming.CNCtx.callResolve(CNCtx.java:453)
    at com.sun.jndi.cosnaming.CNCtx.lookup(CNCtx.java:492)
    at com.sun.jndi.cosnaming.CNCtx.lookup(CNCtx.java:470)
    at javax.naming.InitialContext.lookup(InitialContext.java:351)
    at demo.Main.run(Main.java:46)
    at demo.Main.main(Main.java:62)
    Caused by: org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0
    at org.omg.CosNaming.NamingContextPackage.NotFoundHelper.read(NotFoundHelper.java:72)
    at org.omg.CosNaming._NamingContextExtStub.resolve(_NamingContextExtStub.java:406)
    at com.sun.jndi.cosnaming.CNCtx.callResolve(CNCtx.java:440)
    ... 5 more
    Anyone can solve this problem for me???
    Thanks a lot

    We don't recommend explicitly instantiating the CosNaming provider within a stand-alone java client when accessing beans within the Java EE SDK. We have a simpler approach that involves just instantiating the no-arg InitialContext. Details are in our EJB FAQ :
    https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html
    --ken                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

  • Enhancement request: Remote interface java file generation

    Problem:
    In release 9.0.3, If you want to write a method that is suppossed to be exposed in the remote interface, you have to first right click on the ejb-jar.xml's appropriate EJB name node and then add the method, specify the argument types (say about 25 in number in a small width textbox), return type, etc and check the check box 'Expose in remote interface'. Then only remote interface's java source gets updated and only after doing all this can you actually sit down to write the business logic in that method. If you first code the method and then try to add the same, it gives an error saying "duplicate method exists"
    Suggestion:
    The similiar feature in release 9.0.2 was much better and flexible as it allowed the generation of remote interface source after coding the actual method in the EJB source. You can first write the method and then expose it in the interface by just choosing it from a method browser and opting for exposing it in the remote interface. You donot have to write the name and number of arguments like we have to currently do in the 9.0.3 release.
    (1) Actually, all public methods in the EJB source should by default be exposed in the remote interface because EJB are supposed to be used by other EJBs and JSPs only and all methods that are public but not exposed in the remote interface should actually be private or protected.
    (2) Leave it up to the developer to edit the remote interface
    (3) When the EJB source file is changed (public methods changed) compiled the remote interface should also be updated automatically. Why? already you have provision to change the remote interface source, so just dump all the public methods in the remote interface source when the EJB source is compiled.
    (4) Ditto for EJB Homes
    (5) Actually whenever the developer changes and compiles the EJB source, the remote and home source should automatically be updated AND COMPILED. (Refer: Pramati Studio 3.0 SP3 :- URL: www.pramati.com )
    I was very happy with the earlier option. If anybody other then the JDeveloper Team finds this interesting, please respond. A suite like developer should be more User-friendly.
    And yes expect more like this from me in the future

    Hi Raghu,
    Thanks for the quick response. This flexiblity in Remote interface generation and choice of methods in it at any given point in the development cycle is very much desired feature.
    The other thing I would like to suggest is you look at another enhancement request in my name regarding batch updates of the "web.xml" file. You will find the thread updated today i.e. on 15th September with a reply
    I will shortly post one more for lack of modularity in EJB components descriptors.
    My Company Four Soft Pvt. Ltd. (www.four-soft.com) is Oracle's development partner and we use and support Oracle products. They are good but naturally we would like them to be better and more User-friendly.
    Thanks once again.
    Amit

  • Remote interface distribution

    Hi,
    I am just learning to use RMI, have a typical setup, Server and Client and everything works fine, BUT.......
    I have compiled my remote classes, ie RmtServer, RmtServerImpl, then run the rmiregistry
    and then started the service, so far so good.
    I then compile etc the Client class and run
    My question is this, I am currently working from the same directory for all classes, I would like to truly
    distribute the client and server. Do I need to put a copy of the RmtServer interface on the client?
    Currently in my client I have the line:
    RmtServer server = (RmtServer)Naming.lookup("rmi://" + serverHost + "/ProjectServer");
    I have been reading about dynamic class loading but I am slightly confused!!!
    It says that the stubs created by running "rmic" on the server classes can be loaded dynamically, thats great, but the stubs created and the RmtServer interface are not the same thing. If I have to have a "local" copy of every interface I want to use then it seems a bit limited.
    My impression was that I could specify a location for a class repositry on a remote machine and then
    instantiate classes from the server on the local machine! So then I would only need to have one interface on the client to enable me to connect to the server for the first time!!!
    Im really confused as people can probably tell. Any help would be really appreciated

    The purpose of dynamic loading is really so that you don't have to distribute the stub, or the implementation classes of any interfaces.
    You can certainly load the remote interface dynamically from the codebase in the client, e.g. with URLClassLoader, but you will also have to have already loaded all the classes that use the remote interface the same way, rather than via the system class loader. Otherwise they won't load (NoClassDefFoundError). You can download the entire client actually, and this is not a bad way to go: see the the RMI 1.1 Specification, 'Bootstrapping the client', for details (if you can find it: try http://java.sun.com/products/archive/jdk/1.1/index.html), and the RMI-USERS archives of about five-six years ago for discussions (see http://archives.java.sun.com/archives/rmi-users.html). The description of this was removed from the 1.2 specification for some reason, and I did encounter problems migrating a 1.1 bootstrap client to 1.2, so beware.

  • Location of stubs, skeletons, remote interface ,client and server files

    I have a question to the subject mentioned above :
    In a training example for RMI I red the following :
    .... stubs, remote interface and client files into
    client location
    ... skeletons, remote interfaces, server files and stubs
    into server location ....
    I understand that with the exception that the stubs must also be located at server side. My understanding is
    that it is enough if those reside only at client side. Is that
    right or wrong ?
    Thanks for your comment.
    Regards,
    Oskar

    The stubs must be available (in the classpath) on the server side. This is because when a remote server object is exported, the RMI runtime creates an instance of the stub (instead of the server) and sends it whenever a reference to the server is encountered. In order to create (and then serialize) the stub, its class file must be available on the server.

  • Local Interfaces in WebLogic 7.0 Not Faster Than Remote Interfaces?

    I was curious how much faster calling business methods in
    a stateless session EJB in WebLogic 7.0 would be through
    a local interface than calling the same business methods
    through a remote interface. I timed both ways of calling
    the same methods and much to my surprise the times were
    nearly identical. I double-checked that in one case I really
    used the local interface (using ejb-local-ref, local-jndi-name,
    local interfaces in source code). Does anybody (perhaps from
    BEA) have an explanation for this? By the way, I ran the
    same experiment with other J2EE application servers such
    as IBM's WebSphere 5 (Beta) and there was a tremendous
    performance difference between local and remote interface
    usage.
    Thanks,
    Reinhard

    "Reinhard Klemm" <[email protected]> wrote in message
    news:[email protected]...
    I appreciate your response and, at the same time, I am somewhat
    surprised about it. Here are the reasons for my surprise:
    1. Your response indicates that WebLogic uses RMI for
    EJB local method calls, i.e., even if the client is on the same VM.
    I would have assumed that WebLogic would bypass RMI in such
    a situation.That is not what I said. Local interfaces wont use rmi.
    But remote interfaces do better if the call is from the same VM. This is
    weblogic rmi optimization. Please see Rob's posting also.
    2. Other J2EE application servers fare a lot better. In one
    experiment, I timed WebLogic against WebSphere 5.0 Technology
    for Developers (i.e., WebSphere 5.0 Beta, which is expressly
    NOT for performance testing) and against the Sun Reference
    Implementation. Here are the numbers for calling business
    methods in a stateless session EJB through its local interface:
    WebLogic: 5.15 ms on the average
    WebSphere: 0.41 ms on the average
    Sun Reference Implementation: 0.11 ms on the average
    This indicates to me that both WebSphere and the Sun Reference
    Implementation are better optimized than WebLogic by excluding
    RMI when making local EJB calls.
    Reinhard
    "Maruthi Nuthikattu" <[email protected]> wrote in message
    news:<[email protected]>...
    Can you post some numbers so that we can visualize the difference.
    Please add the numbers with other J2EE appserver also.
    Otherwise top of my head, the reason is:
    Weblogic rmi is well optimized for the calls with in the same JVM andsame
    J2EE application.
    This could be the reason you are not seeing much difference.
    ..maruthi
    "Reinhard Klemm" <[email protected]> wrote in message
    news:[email protected]...
    I was curious how much faster calling business methods in
    a stateless session EJB in WebLogic 7.0 would be through
    a local interface than calling the same business methods
    through a remote interface. I timed both ways of calling
    the same methods and much to my surprise the times were
    nearly identical. I double-checked that in one case I really
    used the local interface (using ejb-local-ref, local-jndi-name,
    local interfaces in source code). Does anybody (perhaps from
    BEA) have an explanation for this? By the way, I ran the
    same experiment with other J2EE application servers such
    as IBM's WebSphere 5 (Beta) and there was a tremendous
    performance difference between local and remote interface
    usage.
    Thanks,
    Reinhard

  • Remote Interface problem using Sun ONE App & web server

    HI,
    1) I am using an S'less SB. I have local & remote interfaces. I am using the sun one appserver7 & the sun ones's htttp server. By default it doesnt pick up the remote interfaces is it ? How do i make my remote interfaces work ? what are the changes required in config/xml ?
    2) However i changed my client code (i.e my action class which is called by the struts action servlet ) to access the localhome rather than the remote home, but then i get java.lang.classcastexception.
    pls help !
    sanjay

    Hi parsuram,
    Thanks for the tip. After looking at the sample source code, I did finally figure out the solution - so I'll post it in case anyone else happens to be working with websphere studio has the same issue deploying on sun one.
    To access local interface ejb, you must have the following
    1. ejb-local-ref tag in the ejb-jar.xml like so underneath the <session> or <entity> tag of the bean which you plan to access the local ejb with.
    <ejb-local-ref>
    <ejb-ref-name>TestL</ejb-ref-name>
    <ejb-ref-type>Session</ejb-ref-type>
    <local-home>memory.simple.TestLLocalHome</local-home>
    <local>memory.tool.simple.TestLLocal</local>
    <ejb-link>TestL</ejb-link>
    </ejb-local-ref>
    2. similar ejb-ref tag in sun-ejb-jar.xml
    <ejb-ref>
    <ejb-ref-name>TestL</ejb-ref-name>
    <jndi-name>localejbs/module_memory.betaEJB/TestL68640023372300293</jndi-name>
    </ejb-ref>
    note: sun generates the <jndi-name> and overwrites whatever you put in that tag no matter what you put in there.
    3. here is the code to access
    Context initial = new InitialContext();
    TestLLocalHome tlHome=(TestLLocalHome) Initial.lookup
    ("TestL");
    //the string must match <ejb-ref-name> underneath <ejb-local-ref>
    4. note that the jndi name for the local interface bean becomes irrelevant. only the <ejb-ref-name> in the ejb-jar and sun-ejb-jar matter. furthermore, both <ejb-ref-name> must be the same or you won't be able to deploy.
    5. This is completely my fault for not checking the "proper" way to access local interfaces. in websphere, they let you get away without the ejb-ref tags and just use the string "local:/TestL"!
    -matt

Maybe you are looking for