Question

I’m using glassfish 3.1 and JEE6 with EJB3.1. I’m simply trying to inject one Stateless LocalBean with the no-interface view into another EJB so that I can access one of its methods. But I immediately get a deployment error on the injection site.

If I inject its interface @EJB Interface interface;

Cannot resolve reference Local ejb-ref name=com.sallie.logic.RSSbean/tclient,Local 3.x interface =com.eb
.thriftEJBinterfaces.thriftEJBinterf*ace,ejb-link=null,lookup=,mappedName=,jndi-name=,r*efType=Session

If I inject it through no-interface view as in @EJB myBean bean;

• javax.naming.NamingException: Lookup failed for ‘java:comp/env/com
• javax.naming.NamingException: Exception resolving Ejb for ‘Remote ejb-ref
• javax.naming.NameNotFoundException: c
• javax.naming.NamingException: Lookup failed for ‘java:comp/env/c

No matter how I do the injection it doesn’t work. I have other EJBs doing the exact same thing in this project that work fine. My database access object uses injection and it’s still running. For some reason this EJB will not inject.

Edit: class declaration with annotation: (basically this class creates a socket connection to an external server not on my web app but that is available at that address using a IDL called thrift. This was tested and works on it’s on as a java SE program (NOTE:THE SERVER LOG ERRORS DO NOT INDICATE THAT THIS IS A PROBLEM. THE LOG FILES THROW REFERENCE AND NAMING EXCEPTIONS AS IF THEY CANNOT FIND THE EJB).

package com.eb.thrift;

import com.eb.thrift.sendEventMessage2;
import com.eb.thriftEJBinterfaces.thriftEJBinterface;

import org.apache.thrift.TException;
import org.apache.thrift.protocol.TBinaryProtocol;
import org.apache.thrift.transport.TSocket;
import org.apache.thrift.transport.TTransportException;

import javax.annotation.ManagedBean;
import javax.ejb.Remote;
import javax.ejb.Local;
import javax.ejb.LocalBean;
import javax.ejb.Singleton;
import javax.ejb.Stateless;

@Stateless
@LocalBean
public class ThriftClient{

    public ThriftClient() { }

    public String sendToServer(String say) {
        System.out.println("Entering ThriftClient's main method starting server connection...");

        String msg = null;
        //**Make Socket**
        TSocket socket = new TSocket("982.222.33.44", 30888);

        //**Make Buffer**
        //TSocket bufferedSocket = (socket); skipping this step because the jvm already handles
        //the buffering on this end. 

        //**put in protocol**
        TBinaryProtocol protocol = new TBinaryProtocol(socket);
        //**create client to use protocol encoder**
        sendEventMessage2.Client client = new sendEventMessage2.Client(protocol);
        //**connect**
        try {
            socket.open();
        } catch (TTransportException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
        try {
            client.ping();
        } catch (TException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }

        try {
            msg = client.sayMsg(say);
            return msg;
        } catch (TException e) {
            msg = "response from server failed";
            e.printStackTrace();
        }
        socket.close();
        return msg;
    }
}

I’ve tried this with and without the interface because I’m using 3.1 I can use no-interface view and it didn’t solve the problem.

I’m wondering if I could use some annotation parameters to explicitly set the mapping and name so that the reference can be found better.

Answer 1

I think you’ve proved that, despite what the logs say, the Thrift code is the problem. If you remove it, injection works; if you leave it in, injection fails. That points very strongly at the Thrift code.

I suspect that this is a classloading problem. The app server can’t find the Thrift libraries, or finds the wrong version, and as a result, the class doesn’t load, or can’t be instantiated. That failure means the EJB can’t be instantiated, which means the lookup fails.

You would expect the underlying exception causing the failure to be logged, but this might be a bug or oversight in the app server. That kind of thing does happen depressingly often.

I’d try writing a really simple test version of the EJB that does:

try {
    System.err.println(Class.forName("org.apache.thrift.transport.TSocket"));
}
catch (Exception e) {
    System.err.println(e);
}

And see what you get when the method is invoked.