EJB3 lookup

Hi,
We are working with JDeveloper Studio 10.1.3.1.0, and we are using EJB3 session beans. We can access our session beans using annotations, and this works fine, but we have a situation in wich we need access to a generic EJB (local interface), so we want to use the old lookup. But it doesn’t work, we get a javax.naming.NameNotFoundException, maybe we are using the wrong name?
This is an example of the EJB we are using:
@Stateless(name="MyProcessEJB")
public class MyProcessEJBBean implements MyProcessEJB {
And this is the code we are using to access the EJB, from another EJB:
Context context = new InitialContext();
Object process = context.lookup(name); // name is "MyProcessEJB"
Thanks in advance

Hi,
You could do one of the following:
1. Provide an orion-ejb-jar.xml in the META-INF directory (the same dir where ejb-jar.xml resides):
orion-ejb-jar.xml:
<?xml version = '1.0' encoding = 'windows-1251'?>
<orion-ejb-jar xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema/orion-ejb-jar-10_0.xsd" schema-major-version="10" schema-minor-version="0">
    <enterprise-beans>
        <session-deployment name="MyProcessEJB" local-location="SomeLookupName"/>
    </enterprise-beans>
    <assembly-descriptor>
    </assembly-descriptor>
</orion-ejb-jar>Then you can look it up via:
MyProcessEJBLocal bean = (MyProcessEJBLocal)ctx.lookup("SomeLookupName");
2. If you are accessing the EJB from a web module, you can define the following in web.xml:
<ejb-local-ref>
    <ejb-ref-name>SomeLookupName</ejb-ref-name>
    <ejb-ref-type>Session</ejb-ref-type>
    <local>some.package.path.MyProcessEJBLocal</local>
    <ejb-link>MyProcessEJB</ejb-link>
</ejb-local-ref>And then you can look it up by the name you specified in the &lt;ejb-ref-name> tag. In my example, it is: "SomeLookupName".

Similar Messages

  • Exception in ejb3

    Hi friends,
    I wrote one client programe in servlet for ejb3 lookup as follows
    Context ctxt = new InitialContext();
    LoginRemote remote = (LoginRemote)ctxt.lookup("LoginBean/remote");
    If i run this from main() it is working , but if i am calling this code from servlet application it is throwing the following exception
    java.lang.ClassCastException: $proxy85
    Please give me your suggestions on this.
    regards,
    shafi

    Hi friend,
    I deployed ejb as separate jar with name petstoreejb.ejb3 and web application as petstore.war . Is it is necessary to create ear file of these two, give me your suggestions.
    regards,
    shafi

  • Weak and concurrent hash map for caching

    Hello,
    I have written a very simple cache class with both weakness and concurrency benefits. This class is intended to be used as a weak cache in "hot redeploy" capable servers (JBoss or any other).
    My implementation uses the (problematic) "double-check" pattern with a reentrant lock and encapsulates a WeakHashMap with WeakReference values (to avoid circular key/value references). Here is the code:
    public interface ValueCreator<V> {
         public V create();
    public class WeakCache<K, V> {
         private final Lock lock = new ReentrantLock();
         private final Map<K, WeakReference<V>> weakMap;
         public WeakCache() {
              this(16);
         public WeakCache(int initialCapacity) {
              this(initialCapacity, 0.75F);
         public WeakCache(int initialCapacity, float loadFactor) {
              weakMap = new WeakHashMap<K, WeakReference<V>>(initialCapacity, loadFactor);
         public V get(K key, ValueCreator<V> creator) {
              WeakReference<V> ref = weakMap.get(key);
              if (ref == null) {
                   lock.lock();
                   try {
                        ref = weakMap.get(key);
                        if (ref == null) {
                             ref = new WeakReference<V>(creator.create());
                             weakMap.put(key, ref);
                   } finally {
                        lock.unlock();
              return ref.get();
         }One usage of this cache is for session ejb3 lookup:
    private static final WeakCache<Class, Object> LOOKUP_CACHE = new WeakCache<Class, Object>();
    public static <T> T lookup(final Class<T> serviceClass) {
         T service = (T)LOOKUP_CACHE.get(serviceClass,
              new ValueCreator<Object>() {
                   public T create() {
                        String lookup = "myapp/" + serviceClass.getSimpleName() + "/local";
                        try {
                             return (T)(new InitialContext()).lookup(lookup);
                        } catch (NamingException e) {
                             throw new RuntimeException("Could not lookup EJB " + serviceClass + ": " + lookup, e);
         return service;
    ...2 questions:
    1. Is there any issue with concurrent access to this cache ?
    2. What happens exactly when the garbage collector wants to free memory with a map with both weak keys and values ?
    Some limited tests show that the behavior of this cache fits my needs: the lookup cache is cleared on redeploy and it keeps its key/values pairs otherwise.
    Thanks for any comments.
    Message was edited by:
    fwolff999

    I know that DCL is broken under certain circumstances (but I have read it may work with modern JVM and the use of volatile variables for example).
    So: is it broken with this specific implementation and if so, what should be done to make it work ?
    The getter method is potentially setting a value (like in ConcurrentHashMap.putIfAbsent) and it uses a ValueCreator in order to actually create the value only if it is not already present in the map.

  • EJB3.0 App deployed with warning:Object not found in lookup of JPA_DEFAULT

    Hi All ,
               I am working on NWCE7.1. I am deploying Enterprise Application DC wich is having
    1 . 3 EJB3.0 session DCs
    2.  1 JPA DC
    I am getting following warning in deployment. I have checked persistence.xml for jta-data-source , it is added. Still not working. I am getting this error after importing configuration(Track) for these DCs in my NWDS. Earlier build n deployment was working in other NWDS on other PC.
    --- Deploying file(s):
         D:\NWDS7.1\workspace.jdi\4\DCs\asianpaints.com\erecapp\_comp\gen\default\deploy\asianpaints.com~erecapp.ear
    --- Status:
         Deploy finished with warnings.
    --- Description:
                S U M M A R Y
    ~~~~~~~~~~~~~~~~~~~
    Successfully deployed:           0
    Deployed with warnings:           1
    Failed deployments:                0
    ~~~~~~~~~~~~~~~~~~~
    1. File:D:\NWDS7.1\workspace.jdi\4\DCs\asianpaints.com\erecapp\_comp\gen\default\deploy\asianpaints.com~erecapp.ear
         Name:erecapp
         Vendor:asianpaints.com
         Location:J2N_ERECTT_D
         Version:20090217100038
         Deploy status:Warning
         Version:HIGHER
         Description:
              1. Exception has been returned while the 'asianpaints.com/erecapp' was starting. Warning/Exception :
    [ERROR CODE DPL.DS.6193] Error while ; nested exception is:
         com.sap.engine.services.deploy.exceptions.ServerDeploymentException: [ERROR CODE DPL.DS.5030] Clusterwide exception: server ID 6358450:com.sap.engine.services.orpersistence.container.deploy.ActionException: [ERROR CODE DPL.DS.5030] Clusterwide exception: com.sap.engine.services.jndi.persistent.exceptions.NameNotFoundException: Object not found in lookup of JPA_DEFAULT.
         at com.sap.engine.services.jndi.implserver.ServerContextImpl.lookup(ServerContextImpl.java:584)
         at com.sap.engine.services.jndi.implclient.ClientContext.lookup(ClientContext.java:343)
         at com.sap.engine.services.jndi.implclient.ClientContext.lookup(ClientContext.java:637)
         at javax.naming.InitialContext.lookup(InitialContext.java:351)
         at javax.naming.InitialContext.lookup(InitialContext.java:351)
         at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexModuleCreator.initDataSources(ComplexModuleCreator.java:344)
         at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexModuleCreator.initRuntimeModels(ComplexModuleCreator.java:230)
         at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexModuleCreator.createModule(ComplexModuleCreator.java:154)
         at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexModuleCreator.execute(ComplexModuleCreator.java:84)
         at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexActionAdapter.execute(ComplexActionAdapter.java:34)
         at com.sap.engine.services.orpersistence.container.deploy.impl.ApplicationCreator.execute(ApplicationCreator.java:74)
         at com.sap.engine.services.orpersistence.container.deploy.impl.PersistenceContainer.prepareStart(PersistenceContainer.java:187)
         at com.sap.engine.services.deploy.server.application.StartTransaction.prepareCommon(StartTransaction.java:219)
         at com.sap.engine.services.deploy.server.application.StartTransaction.prepare(StartTransaction.java:179)
         at com.sap.engine.services.deploy.server.application.ApplicationTransaction.makeAllPhasesOnOneServer(ApplicationTransaction.java:420)
         at com.sap.engine.services.deploy.server.application.ApplicationTransaction.makeAllPhases(ApplicationTransaction.java:445)
         at com.sap.engine.services.deploy.server.application.ParallelAdapter.super_MakeAllPhases(ParallelAdapter.java:337)
         at com.sap.engine.services.deploy.server.application.StartTransaction.makeAllPhasesImpl(StartTransaction.java:550)
         at com.sap.engine.services.deploy.server.application.ParallelAdapter.runInTheSameThread(ParallelAdapter.java:251)
         at com.sap.engine.services.deploy.server.application.ParallelAdapter.makeAllPhasesAndWait(ParallelAdapter.java:392)
         at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3389)
         at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3375)
         at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3278)
         at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3251)
         at com.sap.engine.services.dc.lcm.impl.J2EELCMProcessor.doStart(J2EELCMProcessor.java:99)
         at com.sap.engine.services.dc.lcm.impl.LifeCycleManagerImpl.start(LifeCycleManagerImpl.java:62)
         at com.sap.engine.services.dc.cm.deploy.impl.LifeCycleManagerStartVisitor.visit(LifeCycleManagerStartVisitor.java:34)
         at com.sap.engine.services.dc.cm.deploy.impl.DeploymentItemImpl.accept(DeploymentItemImpl.java:83)
         at com.sap.engine.services.dc.cm.deploy.impl.DefaultDeployPostProcessor.postProcessLCMDeplItem(DefaultDeployPostProcessor.java:80)
         at com.sap.engine.services.dc.cm.deploy.impl.DefaultDeployPostProcessor.postProcess(DefaultDeployPostProcessor.java:56)
         at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.doPostProcessing(DeployerImpl.java:741)
         at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.performDeploy(DeployerImpl.java:732)
         at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.doDeploy(DeployerImpl.java:576)
         at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.deploy(DeployerImpl.java:270)
         at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.deploy(DeployerImpl.java:192)
         at com.sap.engine.services.dc.cm.deploy.impl.DeployerImplp4_Skel.dispatch(DeployerImplp4_Skel.java:875)
         at com.sap.engine.services.rmi_p4.DispatchImpl._runInternal(DispatchImpl.java:351)
         at com.sap.engine.services.rmi_p4.server.ServerDispatchImpl.run(ServerDispatchImpl.java:70)
         at com.sap.engine.services.rmi_p4.P4Message.process(P4Message.java:62)
         at com.sap.engine.services.rmi_p4.P4Message.execute(P4Message.java:37)
         at com.sap.engine.services.cross.fca.FCAConnectorImpl.executeRequest(FCAConnectorImpl.java:877)
         at com.sap.engine.services.rmi_p4.P4Message.process(P4Message.java:53)
         at com.sap.engine.services.cross.fca.MessageReader.run(MessageReader.java:58)
         at com.sap.engine.core.thread.execution.Executable.run(Executable.java:108)
         at com.sap.engine.core.thread.execution.CentralExecutor$SingleThread.run(CentralExecutor.java:304)
         at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexModuleCreator.initDataSources(ComplexModuleCreator.java:360)
         at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexModuleCreator.initRuntimeModels(ComplexModuleCreator.java:230)
         at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexModuleCreator.createModule(ComplexModuleCreator.java:154)
         at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexModuleCreator.execute(ComplexModuleCreator.java:84)
         at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexActionAdapter.execute(ComplexActionAdapter.java:34)
         at com.sap.engine.services.orpersistence.container.deploy.impl.ApplicationCreator.execute(ApplicationCreator.java:74)
         at com.sap.engine.services.orpersistence.container.deploy.impl.PersistenceContainer.prepareStart(PersistenceContainer.java:187)
         at com.sap.engine.services.deploy.server.application.StartTransaction.prepareCommon(StartTransaction.java:219)
         at com.sap.engine.services.deploy.server.application.StartTransaction.prepare(StartTransaction.java:179)
         at com.sap.engine.services.deploy.server.application.ApplicationTransaction.makeAllPhasesOnOneServer(ApplicationTransaction.java:420)
         at com.sap.engine.services.deploy.server.application.ApplicationTransaction.makeAllPhases(ApplicationTransaction.java:445)
         at com.sap.engine.services.deploy.server.application.ParallelAdapter.super_MakeAllPhases(ParallelAdapter.java:337)
         at com.sap.engine.services.deploy.server.application.StartTransaction.makeAllPhasesImpl(StartTransaction.java:550)
         at com.sap.engine.services.deploy.server.application.ParallelAdapter.runInTheSameThread(ParallelAdapter.java:251)
         at com.sap.engine.services.deploy.server.application.ParallelAdapter.makeAllPhasesAndWait(ParallelAdapter.java:392)
         at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3389)
         at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3375)
         at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3278)
         at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3251)
         at com.sap.engine.services.dc.lcm.impl.J2EELCMProcessor.doStart(J2EELCMProcessor.java:99)
         at com.sap.engine.services.dc.lcm.impl.LifeCycleManagerImpl.start(LifeCycleManagerImpl.java:62)
         at com.sap.engine.services.dc.cm.deploy.impl.LifeCycleManagerStartVisitor.visit(LifeCycleManagerStartVisitor.java:34)
         at com.sap.engine.services.dc.cm.deploy.impl.DeploymentItemImpl.accept(DeploymentItemImpl.java:83)
         at com.sap.engine.services.dc.cm.deploy.impl.DefaultDeployPostProcessor.postProcessLCMDeplItem(DefaultDeployPostProcessor.java:80)
         at com.sap.engine.services.dc.cm.deploy.impl.DefaultDeployPostProcessor.postProcess(DefaultDeployPostProcessor.java:56)
         at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.doPostProcessing(DeployerImpl.java:741)
         at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.performDeploy(DeployerImpl.java:732)
         at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.doDeploy(DeployerImpl.java:576)
         at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.deploy(DeployerImpl.java:270)
         at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.deploy(DeployerImpl.java:192)
         at com.sap.engine.services.dc.cm.deploy.impl.DeployerImplp4_Skel.dispatch(DeployerImplp4_Skel.java:875)
         at com.sap.engine.services.rmi_p4.DispatchImpl._runInternal(DispatchImpl.java:351)
         at com.sap.engine.services.rmi_p4.server.ServerDispatchImpl.run(ServerDispatchImpl.java:70)
         at com.sap.engine.services.rmi_p4.P4Message.process(P4Message.java:62)
         at com.sap.engine.services.rmi_p4.P4Message.execute(P4Message.java:37)
         at com.sap.engine.services.cross.fca.FCAConnectorImpl.executeRequest(FCAConnectorImpl.java:877)
         at com.sap.engine.services.rmi_p4.P4Message.process(P4Message.java:53)
         at com.sap.engine.services.cross.fca.MessageReader.run(MessageReader.java:58)
         at com.sap.engine.core.thread.execution.Executable.run(Executable.java:108)
         at com.sap.engine.core.thread.execution.CentralExecutor$SingleThread.run(CentralExecutor.java:304)
    Result
    Status:Warning

    You have to give an explicit data source in your persistence.xml to solve this error normaly.
    <persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
         <persistence-unit name="YOUR_UNIT">
        <jta-data-source>DSNAME</jta-data-source>
    Frank

  • Howto: portable bind, lookup remote + local beans (EJB3) to JNDI with WL 10

    I struggle writing portable ejb3 applications with weblogic.
    I have a JEE5 (EJB3) application using the standard and it works fine on JBoss and WebSphere.
    Porting it to Weblogic (10.0) there are quite a lot of problems, mainly
    in the area of JNDI lookups of EJBs.
    So the issue is how to configure the JNDI-Names of local and remote beans (EJB3!)
    in a portable way with Weblogic without making the application unportable.
    The biggest problem is caused by the fact, that WL 10 does not bind the EJBs
    to the JNDI-tree by default. The bound name would not really be important (JBoss and WebSphere
    come up with a value that can easily be used for a generic lookup). Just any binding
    would be fine.
    So there has to be some extra step in order to get WL 10 binding a remote or local
    bean into the JNDI tree. Unfortunately none of them works/is acceptable in an portable JEE app.
    Idea1: Using the "mappedName" attribute (of @Stateless, @Stateful)
    Well, this one is not portable as the documentation states:
    [http://edocs.bea.com/wls/docs100/ejb30/annotations.html#wp1417411|http://edocs.bea.com/wls/docs100/ejb30/annotations.html#wp1417411]
    Idea2: Using @weblogic.ejbgen.JndiName
    Using weblogic's annotation JndiName also doesn't bind the bean to the given names:
    @Stateless
    @weblogic.ejbgen.JndiName(local="myapp/XBean/local",remote="myapp/XBean/remote")
    public class XBean implements XLocal {
    Besides this, that code would not be portable (as nobody wants an weblogic.jar within another application server).
    Idea3: Using weblogic-ejb-jar.xml
    Mapping a bean using the weblogic-ejb-jar.xml below, also doesn't work.
    The bean is not bound to the given name "myapp/XBean/remote":
    Exception in thread "main" javax.naming.NameNotFoundException:
    Unable to resolve 'myapp.XBean.remote'. Resolved 'myapp.XBean' [Root exception is javax.naming.NameNotFoundException: Unable to resolve 'myapp.XBean.remote'. Resolved 'myapp.XBean']; remaining name 'remote'
    Looking at the JNDI tree, there is "something" bound to "myapp.XBean", but it is not the bean.
    Doing a lookup with this name ("myapp/XBean" or "myapp.XBean"), gives this:
    Exception in thread "main" java.lang.ClassCastException: weblogic.jndi.internal.WLContextImpl cannot be cast to test.server.XRemote
         at test.client.Client.main(Client.java:14)
    Question 1) What is the preferred way to bind and lookup a remote bean in Weblogic 10?
    Again: the goal is to use pure EJB3.
    Question 2) What is the preferred way to bind and lookup a local bean in WL 10?
    This lookup has to be done on the server in some "unmanaged" classes
    where injection doesn't work.
    If there is an unportable way to bind a local bean to jndi, it might do for the time.
    The important thing would be, that there is no weblogic specific code within the application.
    So, solving it using weblogic-xml files would be best.
    This declaration
    <local-jndi-name>myapp/XBean/local</local-jndi-name>
    will come up with the same problems, I guess.
    Here's the code. We want the local interface extending the remote interface,
    so that the local beans can do all what the remote beans can do too.
    XRemote.java
    package test.server;
    import javax.ejb.Remote;
    @Remote
    public interface XRemote {
    String JNDI_NAME = "myapp/XBean/remote";
    void doXRemote();
    XLocal.java
    package test.server;
    import javax.ejb.Local;
    @Local
    public interface XLocal extends XRemote {
    String JNDI_NAME = "myapp/XBean/local";
    void doXLocal();
    XBean.java
    package test.server;
    import javax.ejb.Stateless;
    @Stateless
    public class XBean implements XLocal {
    @Override
    public void doXLocal() {
    System.out.println("doXLocal() called");
    @Override
    public void doXRemote() {
    System.out.println("doXRemote() called");
    weblogic-ejb-jar.xml
    <weblogic-ejb-jar
    xmlns="http://www.bea.com/ns/weblogic/10.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.bea.com/ns/weblogic/10.0 http://www.bea.com/ns/weblogic/10.0/weblogic-ejb-jar.xsd">
    <weblogic-enterprise-bean>
    <ejb-name>XBean</ejb-name>
    <jndi-name>myapp/XBean/remote</jndi-name>
    </weblogic-enterprise-bean>
    </weblogic-ejb-jar>
    Client.java
    package test.client;
    import java.util.Properties;
    import javax.naming.Context;
    import javax.naming.InitialContext;
    import javax.naming.NamingException;
    import test.server.XRemote;
    public class Client {
    public static void main(String[] args) throws NamingException {
    InitialContext context = getInitialContext();
    XRemote xRemote = (XRemote) context.lookup(XRemote.JNDI_NAME);
    xRemote.doXRemote();
    private static InitialContext getInitialContext() throws NamingException {
    Properties properties = new Properties();
    properties.put(Context.PROVIDER_URL, "t3://localhost:7001");
    properties.put(Context.INITIAL_CONTEXT_FACTORY,
    "weblogic.jndi.WLInitialContextFactory");
    properties.put(Context.SECURITY_PRINCIPAL, "weblogic");
    properties.put(Context.SECURITY_CREDENTIALS, "weblogic");
    return new InitialContext(properties);
    }

    Hi,
    about how to specify jndi name of remote ejb, please refer to this link: http://forums.oracle.com/forums/thread.jspa?threadID=800314&tstart=1
    please note @JNDIName isn't an EJBGen annotation. its package name is weblogic.javaee.
    So far, based on the EJB spec, local ejb will not be bound to global JNDI. EJB3.1 specification is trying to specify the portable JNDI names including local EJBs, but it isn't published yet.
    local EJB is used within one application and ejb reference is used to lookup the local EJB. please refer to EJB specification about how to declare an EJB local reference. once it is declared, it can be looked up from the java:comp\env JNDI namespace.
    But, if the local client of the EJB isn't a JavaEE component, there won't be any declaration of ejb-local-ref. You may want to try remote access to the EJB from the non-JavaEE client.

  • EJB3 Stateful:ClassCastException when casting the object returned in lookup

    Hi,
    I'm developing a web application that make use of EJB3 stateless and stateful beans. The application server is the Websphere Application Server 6.1.0.15 with the EJB3 Feature Pack installed and the web server is the IBM HTTP Server running in another machine.
    The problem I'm facing is that for every stateful bean after the lookup, it throws a ClassCastExcption when casting the object returned. See part of the log below.
    [7/13/08 3:15:48:869 CDT] 0000001c SystemErr R java.lang.ClassCastException: cannot cast class com.spcs.dsa.ejb.authenticationmanager._AuthenticationManager_Stub to class com.spcs.dsa.ejb.authenticationmanager._AuthenticationManager_Stub
    at com.ibm.rmi.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:396)
    at com.spcs.dsa.ejb.client.DsaEjbClient.getAuthenticationRemote(DsaEjbClient.java:37)
    at com.spcs.dsa.action.NewCardAction.execute(NewCardAction.java:85)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:585)
    Please notice in the log above that the cast was done for the correct class.
    Here is the java code:
    AuthenticationManager auth =
    (AuthenticationManager) javax.rmi.PortableRemoteObject.narrow(
    context.lookup("com.spcs.dsa.ejb.authenticationmanager.AuthenticationManager"),
    AuthenticationManagerStub.class);
    This problem doesn't happen for statless beans. If you simply change the class to be stateless, this problem stop to happen.
    If you run this code in a stand alone program, this problem doesn't happen. It only happen when running in the web server.
    Does anybody know what should be done to solve this problem ??
    Thanks,
    Marcos.

    I'm not familiar with any specifics of IBM's implementation but from an EJB 3 spec perspective there is no need to use PortableRemoteObject.narrow() if you're retrieving an EJB 3.0 Remote Business interface, regardless of the component type( stateful vs. stateless). In addition, the "_Stub" class should never have to be part of your client programming model. That should be hidden within the vendor's implementation, if present at all.
    If AuthenticationManager is the Remote 3.0 Business Interface
    @Remote
    public interface AuthenticationManager {
    your client lookup should be :
    AuthenticationManager am = (AuthenticationManager) context.lookup("...");

  • JNDI Lookup for EJB3 (Bean to Bean)

    Hi Forum,
    i've search the whole internet and two books but I could not find an answer that pleased me.
    I want to get a reference to an EJB3 by JNDI Lookup. With container managed dependency injection everything works fine but I have to do a little more generic way, thats why I want to work with JNDI Lookup.
    I have the following situation:
    At first I have a stateless bean
    @Local
    public interface Job {
         * run the job
         * @return true if the job executed without errors
        public boolean run(SchedulerConfig schedulerConfig ,JobContext context);
    @Local
    public interface AConcreteJobLocal extends Job {   
    //no more declarations
    @Stateless
    @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
    public class AConcreteJobBean implements AConcreteJobLocal {
    //implemented methods goes here | removed for better overview in the post
    } This is a typical declaration for a bunch of jobs I have. Every concrete job has it's own bean if it necessary in some way for you to know.
    So now I wanted to write a bean which returns me an bean instance via a JNDI lookup
    @Stateless
    public class JobJNDILookupBean implements JobJNDILookupLocal {
        Logger logger = Logger.getLogger(JobJNDILookupBean.class.getName());
        public Job getJobBeanFromJNDIName(String jndiName) {
            Job job = null;
            try {
                Context c = new InitialContext();
                job = (Job) c.lookup("jndiName");
            } catch (NamingException ex) {
                Logger.getLogger(JobJNDILookupBean.class.getName()).log(Level.SEVERE, null, ex);
            } catch (IllegalArgumentException ex) {
                logger.log(Level.SEVERE, "Bean not found", ex);
            return job;
    }When I call this method I always get a NameNotFoundException
    javax.naming.NameNotFoundException: JNDI_NAME_GOES_HERE not found
            at com.sun.enterprise.naming.TransientContext.doLookup(TransientContext.java:216)
            at com.sun.enterprise.naming.TransientContext.lookup(TransientContext.java:188)
            at com.sun.enterprise.naming.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:74)
            at com.sun.enterprise.naming.LocalSerialContextProviderImpl.lookup(LocalSerialContextProviderImpl.java:111)
            at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:398)
            at javax.naming.InitialContext.lookup(InitialContext.java:351)
            at com.vw.ais.dcl.timer.engine.JobJNDILookup.getJobBeanFromJNDIName(JobJNDILookup.java:46)
            at com.vw.ais.dcl.timer.engine.EngineBean.init(EngineBean.java:221)
            at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
            at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
            at java.lang.reflect.Method.invoke(Method.java:585)
            at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
            at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
            at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
            at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3986)
            at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:197)
            at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:83)
            at $Proxy713.init(Unknown Source)
            at com.vw.ais.dcl.timer.SchedulerBean.runEngine(SchedulerBean.java:192)
            at com.vw.ais.dcl.timer.SchedulerBean.handleIncomingByTimer(SchedulerBean.java:171)
            at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
            at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
            at java.lang.reflect.Method.invoke(Method.java:585)
            at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
            at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
            at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
            at com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:2824)
            at com.sun.ejb.containers.EJBTimerService.deliverTimeout(EJBTimerService.java:1401)
            at com.sun.ejb.containers.EJBTimerService.access$100(EJBTimerService.java:99)
            at com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.run(EJBTimerService.java:1952)
            at com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.service(EJBTimerService.java:1948)
            at com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75)
            at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555)I've tried I guess all combinations for the JNDI_NAME
    java:/comp/env/ejb/AConcreteJob
    java:/comp/env/ejb/AConcreteJobLocal
    java:/comp/env/ejb/AConcreteJobBean
    java:/comp/env/AConcreteJob
    java:/comp/env/full.package.and.Class.name
    this all without java:/comp/env
    etc.
    The only way it worked was when I added a annotation to the JobJNDILookupBean in this way
    @Stateless
    *@EJB(name="ejb/AConcreteJob",beanInterface=A.Interface.location)*
    public class JobJNDILookupBean implements JobJNDILookupLocal {
    }But this is not what I want to do. Thats why my question. How can I lookup a bean without annotate it in the bean which want to look it up???
    In other words whats wrong here
    @Stateless
    public class JobJNDILookupBean implements JobJNDILookupLocal {
        Logger logger = Logger.getLogger(JobJNDILookupBean.class.getName());
        public Job getJobBeanFromJNDIName(String someJndiName) {
            Job job = null;
            try {
                Context c = new InitialContext();
                job = (Job) c.lookup("someJndiName");
            } catch (NamingException ex) {
                Logger.getLogger(JobJNDILookupBean.class.getName()).log(Level.SEVERE, null, ex);
            } catch (IllegalArgumentException ex) {
                logger.log(Level.SEVERE, "Bean not found", ex);
            return job;
    }I hope you understand my question and more than this I hope some has the answer.

    Hi Zsom,
    Zsom wrote:
    One thing you need to keep in mind is that beans aren't instantiated every time you make a call to your EJB. You're right! But because the fact the beans are all stateless it doesn't matter. I don't want to get a new EJB at a lookup. If I get a reference to a bean which was used a million times before it is absolutely ok
    Zsom wrote:
    You might be gaining some time because the container can create new beans more quickly, but you are also looking up the beans before each call, which in the long run will be even more expensive.Mhm, I don't know if I understand you. Maybe I explain my process a little bit. I have a lot of different jobs in my application (JobDoThis, JobDoThat, JobFoo, JobBar). Every job has a own bean which keeps the business logic. Furthermore I have an job engine which is able to execute jobs which are configured to run and this engine can solve some dependencies (If JobFoo fails don't execute JobBar , and so on). When I build my engine I want to get a reference to a jobBean by jndi lookup which keeps the business logic and then call some method on it. This means that the lookup will only be called when I build a new engine. And because this doesn't happen so often performance is not so important. Furthermore if all jobs all configured to run the application needs sometimes more than 12 hours (depended from the amount of data) for one run (Start to End -> the application has a little script character), that's why performance as I said already is not so important.
    Zsom wrote:
    But it would be worth making some test, because to me it seems a bit like bad design.Yes it could be, but this was my first thought to instantiate a bean (or get a reference to an existing one) dynamically. I don't like this hard coded dependency injection. I mean it's great If you know at compiletime which beans you need. But because we don't know which beans we need it's a big overhead to inject them all by container and then use only 40 percent of the injected bean because for example only 40 of 100 jobs shall run.
    If there is another approach to get a reference dynamically which is better than this then I will try, no problem, but unfortunally I don't see another.

  • Ejb3 session bean lookup

    Hello, I have following problem with the ejb3 and session bean lookup:
    For example, I have a session bean with some dummy method, i.e. getInfo() :
    @Stateless
    public class MySessionBean implements MySessionLocal {
    public String getInfo() {return "Hello from Session bean";}
    When I lookup and use this bean in servlet in the following way, everything is OK:
    public class MyServlet extends HttpServlet {
    @EJB() MySessionLocal mySession;
    protected void doPost(HttpServletRequest request, HttpServletResponse response) {
    out.println(mySession.getInfo());
    On the other side, when I create some java bean object as a facade, import and use it in servlet , it doesn't work:
    public class Facade {
    @EJB() MySessionLocal mySession;
    public String getInfo() { return mySession.getInfo();}
    public class MyServlet extends HttpServlet {
    protected void doPost(HttpServletRequest request, HttpServletResponse response) {
    Facade myFacade = new Facade();
    out.println(myFacade.getInfo());
    When servlet runs and gets to the command myFacade.getInfo(), NullPointerException is thrown, because mySession object in myFacade is null (ejb lookup method probably fails to perform...)
    I'm trying to use Facade to be able to use my Session Bean in JSP pages, i.e. to do something like <jsp:useBean id="myFacade" class="Facade" ...>
    Could someone clarify why lookup doesn't work in javabean object, despite the fact that it works in servlets?
    P.S. I'm running the latest promoted build (b31) of GlassFish (maybe this is the cause) and NetBeans IDE...

    Hi,
    Please try this ... http://weblogic-wonders.com/weblogic/2009/08/16/weblogic-10-3-ejb3-local-lookup-sample/ (Lookup from JSP)
    and
    http://weblogic-wonders.com/weblogic/2009/08/15/hello-world-2/  (Lookup/Injection from Servlet)
    Thanks
    Jay SenSharma

  • EJB3 - where to perform JMS JNDI lookups?

    Hi, I was reading about how the WebLogic jms wrappers work at:
    http://download.oracle.com/docs/cd/E12840_01/wls/docs103/jms/j2ee.html
    and noticed this section:
    "The JNDI lookups of the Connection Factory and Destination objects can be expensive in terms of performance. This is particularly true if the Destination object points to a Foreign JMS Destination MBean, and therefore, is a lookup on a non-local JNDI provider.". I am using Sonic MQ as my foreign JMS Provider hence this is of particular interest to me.
    The document recommends caching these lookups in the ejbCreate() method of an EJB. I'm new to EJB3 but notice there is no concept of an ejbCreate() method there so where should I cache the lookups and how do I ensure they get re-looked up in the case of a connection failure?
    Many thanks
    Mandy

    Thanks very much Tom, this helps a lot. I think my confusion lay in the fact that this document talks about caching the JNDI lookups in the ejbCreate and gives the example PoolTestBean.java which uses EJB2 style code. I've made your recommended changes to my code, would you mind just casting your eye over to see if looks ok? I have chosen to cache on create of the bean rather than on first invocation as I want clients to fail on startup rather than during their processing.
    Sorry about code layout, not sure how to use HTML in posts to make it verbatim..
    @Stateless
    @TransactionAttribute(NEVER)
    //@ExcludeDefaultInterceptors
    public class ServiceWrapperBean implements ServiceWrapper {
         // injected resources
         @Resource
         private SessionContext sctx; // inject the bean context
         @Resource(name = "sonicConnectionFactory", mappedName = "sonic.connFactory", shareable = true)
         private ConnectionFactory connectionFactory;
         @Resource(name = "LegacyAccessIn", mappedName = "queue/LegacyIn", shareable = true)
         private Destination sendQueue;
         public void sendMessage(String msg) {
              if (connectionFactory == null)
                   connectionFactory = (javax.jms.ConnectionFactory) sctx
                             .lookup("sonicConnectionFactory");
              if (sendQueue == null)
                   sendQueue = (javax.jms.Destination) sctx.lookup("LegacyAccessIn");
              if (msg == null)
                   throw new IllegalArgumentException("object cannot be null!");
              Connection con = null;
              Session session = null;
              MessageProducer sender = null;
              try {
                   con = connectionFactory.createConnection();
                   session = con.createSession(true, Session.AUTO_ACKNOWLEDGE);
                   sender = session.createProducer(null);
                   Message message = session.createTextMessage("do stuff");
                   sender.send(sendQueue, message);
              } catch (JMSException e) {
                   // Invalidate the JNDI objects if there is a failure
                   // this is necessary because the destination object
                   // may become invalid if the destination server has
                   // been shut down
                   connectionFactory = null;
                   sendQueue = null;
                   throw new RuntimeException(e);
              } finally {
                   if (con != null) {
                        try {
                             // Return JMS resources to the resource reference pool for later re-use.
                             // Closing a connection automatically also closes its sessions, etc.
                             con.close(); // also closes other objects
                        } catch (JMSException je) {
                             // ignore
         }

  • EJBContext.lookup() vs InitialContext.lookup() @ EJB3.0

    current design of my application uses a helper class for retrieving the system resources. according the new ejb3.0 specs i can't use dependency injection in helper classes. so, if we wanna stay with the current design, we should continue with the 2.1 style initialcontext.lookup.
    my question is if brand new EJBContext.lookup()is just a wrapper that hides direct jndi usage, or there is any deep reason not to use InitialContext.lookup() anymore even if this means that the whole design should be rebuilt from scratch?
    thanks folks!

    Good question :-) EJBContext.lookup() is just a convenience method to make the lookup a bit easier to understand.
    -- It removes the JNDI API from the developer's view.
    -- It removes the notion of "java:comp/env" from the developer's view.
    -- It removes the need to catch a checked exception during the lookup.
    However, the object returned from EJBContext.lookup("abc") is exactly the same as the equivalent new InitialContext().lookup("java:comp/env/abc"). So, you can feel free to use the older more explicit JNDI component environment lookup wherever you'd like, but for code located directly within the bean class, it's easiest to use injection or EJBContext.lookup.
    --ken                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

  • Manual JNDI lookup for EJB3 between different Application Server Instances

    Hi all,
    i have spent quite some time looking into this problem and searching the net but i just can't figure out for the life of me what i am doing wrong so i hope someone here can give me a clue or a good resource where i can look it up myself.
    I am currently doing some interoperability tests concerning EJB calls between Glassfish and Weblogic 10. In my test setup i have an EJB deployed in a jar file on one server and a servlet in a war file deployed on the other. The objective is to try to look up and call the EJB from the servlet. As there seem to be some issues with injection in Weblogic 10 i set that one aside for now (i have opened a case at BEA support for this) but i would like to do a plain old JNDI lookup to obtain the EJB.
    The online tutorials and FAQs i have read so far all state that this can be done the same way as it works for EJB2.x, at least if i understood them correctly. The interessting thing is, when i deploy an EJB2.x bean i can look it up without problems, but when i try to do the same with the EJB3 bean the name cannot be found. On the other hand when listing all contents of the JNDI tree in Glassfish from a stand alone application i can see entries for both EJBs of the type java.naming.Reference (in Weblogic i can also see entries for both, but the ones for EJB3 are of some weird internal weblogic types, which i put down as a weblogic problem for now).
    The lookup code for the servlet running in weblogic looks like this:
    Properties env = new Properties();
    env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
    env.put(Context.PROVIDER_URL, "corbaname:iiop:1.2@localhost:3700");
    Object myEjb = new InitialContext(env).lookup("JNDINameDisplayedByContextListing");
    I know that the preferred way would be to have the corbaname put into weblogic.xml/sun-web.xml and just use an InitialContext without an environment to perform the lookup but i wanted to get rid of any additional indirections to pinpoint the source my problem and it should work this way, too. As i said, it works when i target an EJB2.x bean but not with the EJB3 one, so i guess i am doing something wrong there. The jar file contains the interface of the bean annotated with @Remote and the implementation of the interface annotated with @Stateless, i also tried setting the mappedName attribute for the bean and use that name as JNDI name, but that also fails. In addition i added an ejb-jar.xml to the jars META-INF containing the following:
    <?xml version="1.0" encoding="UTF-8"?>
    <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
    http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
         version="3.0">
         <enterprise-beans>
              <session>
                   <ejb-name>SecurityTest3EJB</ejb-name>
                   <ejb-class>
                        testcase.ejb.SecurityTestBean
                   </ejb-class>
                   <session-type>Stateless</session-type>
                   <transaction-type>Container</transaction-type>
    </session>
    </enterprise-beans>
    But the ejb-name specified there does not show up in a context listing, so i would guess that means the file is ignored or only accessible from within the same application server (note, there is no indication of any problems in the Glassfish log when deploying the jar file).
    This might be just a stupid mistake by me, but i just can't figure it out at the moment, so any advice will be greatly appriciated.
    Thanks, Chris

    I think i stumbled across something now. From some posts it seems to me that the EJB3 spec does not require EJBs to be accessible from a remote location, since this can be achieved by using the @RemoteHome annotation and performing a EJB2.x compliant look up. Is that correct?

  • EJB3.0 App Deplyed wid warnings : Object not found in lookup of JPA-DEFAULT

    Hello Friends
    I am getting this warning while deploying this EJB 3.0 Application
    here I have
    1) 4 DCs with session beans
    2) One Entity DC
    I have checked my jta-data-source its added properly
    here is the deployment stack trace
         Description:
              1. Exception has been returned while the 'asianpaints.com/hssp_app_new' was starting. Warning/Exception :
    [ERROR CODE DPL.DS.6193] Error while ; nested exception is:
         com.sap.engine.services.deploy.exceptions.ServerDeploymentException: [ERROR CODE DPL.DS.5030] Clusterwide exception: server ID 6358450:com.sap.engine.services.orpersistence.container.deploy.ActionException: [ERROR CODE DPL.DS.5030] Clusterwide exception: com.sap.engine.services.jndi.persistent.exceptions.NameNotFoundException: Object not found in lookup of JPA_DEFAULT.
         at com.sap.engine.services.jndi.implserver.ServerContextImpl.lookup(ServerContextImpl.java:584)
         at com.sap.engine.services.jndi.implclient.ClientContext.lookup(ClientContext.java:343)
         at com.sap.engine.services.jndi.implclient.ClientContext.lookup(ClientContext.java:637)
         at javax.naming.InitialContext.lookup(InitialContext.java:351)
         at javax.naming.InitialContext.lookup(InitialContext.java:351)
         at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexModuleCreator.initDataSources(ComplexModuleCreator.java:344)
         at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexModuleCreator.initRuntimeModels(ComplexModuleCreator.java:230)
         at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexModuleCreator.createModule(ComplexModuleCreator.java:154)
         at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexModuleCreator.execute(ComplexModuleCreator.java:84)
         at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexActionAdapter.execute(ComplexActionAdapter.java:34)
         at com.sap.engine.services.orpersistence.container.deploy.impl.ApplicationCreator.execute(ApplicationCreator.java:74)
         at com.sap.engine.services.orpersistence.container.deploy.impl.PersistenceContainer.prepareStart(PersistenceContainer.java:187)
         at com.sap.engine.services.deploy.server.application.StartTransaction.prepareCommon(StartTransaction.java:219)
         at com.sap.engine.services.deploy.server.application.StartTransaction.prepare(StartTransaction.java:179)
         at com.sap.engine.services.deploy.server.application.ApplicationTransaction.makeAllPhasesOnOneServer(ApplicationTransaction.java:420)
         at com.sap.engine.services.deploy.server.application.ApplicationTransaction.makeAllPhases(ApplicationTransaction.java:445)
         at com.sap.engine.services.deploy.server.application.ParallelAdapter.super_MakeAllPhases(ParallelAdapter.java:337)
         at com.sap.engine.services.deploy.server.application.StartTransaction.makeAllPhasesImpl(StartTransaction.java:550)
         at com.sap.engine.services.deploy.server.application.ParallelAdapter.runInTheSameThread(ParallelAdapter.java:251)
         at com.sap.engine.services.deploy.server.application.ParallelAdapter.makeAllPhasesAndWait(ParallelAdapter.java:392)
         at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3389)
         at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3375)
         at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3278)
         at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3251)
         at com.sap.engine.services.dc.lcm.impl.J2EELCMProcessor.doStart(J2EELCMProcessor.java:99)
         at com.sap.engine.services.dc.lcm.impl.LifeCycleManagerImpl.start(LifeCycleManagerImpl.java:62)
         at com.sap.engine.services.dc.cm.deploy.impl.LifeCycleManagerStartVisitor.visit(LifeCycleManagerStartVisitor.java:34)
         at com.sap.engine.services.dc.cm.deploy.impl.DeploymentItemImpl.accept(DeploymentItemImpl.java:83)
         at com.sap.engine.services.dc.cm.deploy.impl.DefaultDeployPostProcessor.postProcessLCMDeplItem(DefaultDeployPostProcessor.java:80)
         at com.sap.engine.services.dc.cm.deploy.impl.DefaultDeployPostProcessor.postProcess(DefaultDeployPostProcessor.java:56)
         at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.doPostProcessing(DeployerImpl.java:741)
         at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.performDeploy(DeployerImpl.java:732)
         at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.doDeploy(DeployerImpl.java:576)
         at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.deploy(DeployerImpl.java:270)
         at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.deploy(DeployerImpl.java:192)
         at com.sap.engine.services.dc.cm.deploy.impl.DeployerImplp4_Skel.dispatch(DeployerImplp4_Skel.java:875)
         at com.sap.engine.services.rmi_p4.DispatchImpl._runInternal(DispatchImpl.java:351)
         at com.sap.engine.services.rmi_p4.server.ServerDispatchImpl.run(ServerDispatchImpl.java:70)
         at com.sap.engine.services.rmi_p4.P4Message.process(P4Message.java:62)
         at com.sap.engine.services.rmi_p4.P4Message.execute(P4Message.java:37)
         at com.sap.engine.services.cross.fca.FCAConnectorImpl.executeRequest(FCAConnectorImpl.java:877)
         at com.sap.engine.services.rmi_p4.P4Message.process(P4Message.java:53)
         at com.sap.engine.services.cross.fca.MessageReader.run(MessageReader.java:58)
         at com.sap.engine.core.thread.execution.Executable.run(Executable.java:108)
         at com.sap.engine.core.thread.execution.CentralExecutor$SingleThread.run(CentralExecutor.java:304)
         at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexModuleCreator.initDataSources(ComplexModuleCreator.java:360)
         at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexModuleCreator.initRuntimeModels(ComplexModuleCreator.java:230)
         at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexModuleCreator.createModule(ComplexModuleCreator.java:154)
         at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexModuleCreator.execute(ComplexModuleCreator.java:84)
         at com.sap.engine.services.orpersistence.container.deploy.impl.ComplexActionAdapter.execute(ComplexActionAdapter.java:34)
         at com.sap.engine.services.orpersistence.container.deploy.impl.ApplicationCreator.execute(ApplicationCreator.java:74)
         at com.sap.engine.services.orpersistence.container.deploy.impl.PersistenceContainer.prepareStart(PersistenceContainer.java:187)
         at com.sap.engine.services.deploy.server.application.StartTransaction.prepareCommon(StartTransaction.java:219)
         at com.sap.engine.services.deploy.server.application.StartTransaction.prepare(StartTransaction.java:179)
         at com.sap.engine.services.deploy.server.application.ApplicationTransaction.makeAllPhasesOnOneServer(ApplicationTransaction.java:420)
         at com.sap.engine.services.deploy.server.application.ApplicationTransaction.makeAllPhases(ApplicationTransaction.java:445)
         at com.sap.engine.services.deploy.server.application.ParallelAdapter.super_MakeAllPhases(ParallelAdapter.java:337)
         at com.sap.engine.services.deploy.server.application.StartTransaction.makeAllPhasesImpl(StartTransaction.java:550)
         at com.sap.engine.services.deploy.server.application.ParallelAdapter.runInTheSameThread(ParallelAdapter.java:251)
         at com.sap.engine.services.deploy.server.application.ParallelAdapter.makeAllPhasesAndWait(ParallelAdapter.java:392)
         at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3389)
         at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3375)
         at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3278)
         at com.sap.engine.services.deploy.server.DeployServiceImpl.startApplicationAndWait(DeployServiceImpl.java:3251)
         at com.sap.engine.services.dc.lcm.impl.J2EELCMProcessor.doStart(J2EELCMProcessor.java:99)
         at com.sap.engine.services.dc.lcm.impl.LifeCycleManagerImpl.start(LifeCycleManagerImpl.java:62)
         at com.sap.engine.services.dc.cm.deploy.impl.LifeCycleManagerStartVisitor.visit(LifeCycleManagerStartVisitor.java:34)
         at com.sap.engine.services.dc.cm.deploy.impl.DeploymentItemImpl.accept(DeploymentItemImpl.java:83)
         at com.sap.engine.services.dc.cm.deploy.impl.DefaultDeployPostProcessor.postProcessLCMDeplItem(DefaultDeployPostProcessor.java:80)
         at com.sap.engine.services.dc.cm.deploy.impl.DefaultDeployPostProcessor.postProcess(DefaultDeployPostProcessor.java:56)
         at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.doPostProcessing(DeployerImpl.java:741)
         at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.performDeploy(DeployerImpl.java:732)
         at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.doDeploy(DeployerImpl.java:576)
         at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.deploy(DeployerImpl.java:270)
         at com.sap.engine.services.dc.cm.deploy.impl.DeployerImpl.deploy(DeployerImpl.java:192)
         at com.sap.engine.services.dc.cm.deploy.impl.DeployerImplp4_Skel.dispatch(DeployerImplp4_Skel.java:875)
         at com.sap.engine.services.rmi_p4.DispatchImpl._runInternal(DispatchImpl.java:351)
         at com.sap.engine.services.rmi_p4.server.ServerDispatchImpl.run(ServerDispatchImpl.java:70)
         at com.sap.engine.services.rmi_p4.P4Message.process(P4Message.java:62)
         at com.sap.engine.services.rmi_p4.P4Message.execute(P4Message.java:37)
         at com.sap.engine.services.cross.fca.FCAConnectorImpl.executeRequest(FCAConnectorImpl.java:877)
         at com.sap.engine.services.rmi_p4.P4Message.process(P4Message.java:53)
         at com.sap.engine.services.cross.fca.MessageReader.run(MessageReader.java:58)
         at com.sap.engine.core.thread.execution.Executable.run(Executable.java:108)
         at com.sap.engine.core.thread.execution.CentralExecutor$SingleThread.run(CentralExecutor.java:304)
    Result
    Status:Warning

    OK, you have properly declared the data source for your persistence unit in the persistence.xml. But you also have to maintain this data source (alias) on the server, i.e. it has to be created explicitly.
    Check this [document|http://help.sap.com/saphelp_nwce711/helpdata/en/46/96ec3c33621e5ce10000000a1553f6/frameset.htm].
    HTH!
    -- Vladimir
    PS: Please take your time to go through the [Rules of Engagement|https://wiki.sdn.sap.com/wiki/display/HOME/RulesofEngagement] and do not crosspost to multiple forums.

  • NameNotFoundException in JNDI lookup in for stand alone App client in EJB3

    I created an ejb module in netbeans 5.5 added a session facade (SavingsaccountFacade) and downloaded it to SunAppServer 9 (java EE 5). When I try and access the JNDI name in a stand alone java application client using the following code
    Context initial = new InitialContext();
    Object objref = initial.lookup("ejb/SavingsaccountFacade");
    I get the following errors:
    javax.naming.NameNotFoundException: SavingsaccountFacade not found
    at com.sun.enterprise.naming.TransientContext.doLookup(TransientContext.java:203)
    I have added j2ee.jar, appserv-rt.jar, and the dist/SavingsAccount.jar to the library. When I do a similar thing in J2EE1.4 it worked fine.
    Can somebody help please.
    Thanks

    Hi Dave,
    Here's our EJB FAQ entry that explains how EJB Global JNDI names are set in the
    Java EE 5 SDK and Glassfish. The most likely explanation is that the name used
    in the client does not match the one assigned to your EJB in sun-ejb-jar.xml.
    https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html#SessionBeanGlobalJNDINameAssignment
    --ken                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

  • How to lookup EJB3 beans using JNDI names without defining ejb-ref in DD?

    Hi Kenneth,
    I am just continuing the topic:
    How Lookup SLSB from other SLSB? <HELP>
    http://forum.java.sun.com/thread.jspa?threadID=5117484&tstart=0
    (my original forums account failed, so I am using new one)
    if I am not seeking portability I should be able to lookup a bean directly through JNDI without using the ejb-ref. (I just want to see how it can be done)
    http://forum.java.sun.com/thread.jspa?forumID=13&threadID=751907
    http://www.theserverside.com/discussions/thread.tss?thread_id=16402
    I am using SJSAS PE 9.0 I am failing to lookup my beans from other beans directly without ejb-ref.
    Is there some sample code to look at?
    Thanks!

    Global JNDI names are vendor-specific and not known until deployment time. That is one
    of the main reasons the Java EE component environment model defines a level of
    indirection for accessing component dependencies. It is best to use either an ejb-ref
    or @EJB annotation when accessing EJBs from a Java EE component.
    If you choose not to, you just have to make sure the global JNDI name you use matches
    the one assigned to the target EJB. We have a lot of information on how this works
    in our EJB FAQ.
    https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html
    If you're still encountering an error, please provide more specifics about your application,
    the code you're using for the lookup, and the error message you're receiving. Just
    saying "my looking fails" doesn't help us diagnose the problem :-)
    --ken                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

  • EJB3 JNDI Lookup

    Hi,
    I managed to install the new Web AS successfully and to connect to the JNDI Server.
    Now I want to lookup my Bean on the server. I tried all possibilities to lookup the remote interface.
    From the SAP Documentation it is written, that for non J2EE Applications the JNDI Lookuppath should be
    sap.com/EARName/BeanClassName
    Unfortunatly this does not work. I receive the following Error below.
    Anybody able to help me? What I can do is a lookup of
    sap.com/EARName
    There I can do a list() oder listBinding() Operation which lists me my Beans available. Any Ideas?
    Thanks in Advance Martin
    [code]com.sap.engine.services.jndi.persistent.exceptions.NameNotFoundException: Object not found in lookup of Test.
         at com.sap.engine.services.jndi.implserver.ServerContextImpl.lookup(ServerContextImpl.java:650)
         at com.sap.engine.services.jndi.implserver.ServerContextRedirectableImpl.lookup(ServerContextRedirectableImpl.java:80)
         at com.sap.engine.services.jndi.implserver.ServerContextRedirectableImplp4_Skel.dispatch(ServerContextRedirectableImplp4_Skel.java:872)
         at com.sap.engine.services.rmi_p4.P4Message.process(P4Message.java:253)
         at com.sap.engine.services.rmi_p4.P4Message.execute(P4Message.java:109)
         at com.sap.engine.services.cross.fca.FCAConnectorImpl.executeRequest(FCAConnectorImpl.java:841)
         at com.sap.engine.services.rmi_p4.P4Message.process(P4Message.java:125)
         at com.sap.engine.services.cross.fca.MessageReader.run(MessageReader.java:59)
         at com.sap.engine.core.thread.execution.Executable.run(Executable.java:108)
         at com.sap.engine.core.thread.execution.CentralExecutor$SingleThread.run(CentralExecutor.java:168)
    predecessor system -
    [/code]

    What has been said in this thread so far are all valid points. However, I'd like to shed some light on this question as it seems to be of interest to many people here and, in the same time, it's a bit confusing.
    - Technically it's possible to lookup EJB 3.0 business interfaces just like Martin mentioned above. This is, however, the scheme implemented only in this preview release, and it's currently under discussion how to be supported in the upcoming official releases of SAP NetWeaver. Just keep in mind that it may be possible to change. That's what I meant by saying <i>"The lookup from standalone clients will be available and accordingly documented in the next release of SAP NetWeaver Application Server"</i> in the above referenced thread.
    - EJB 2.x style Home interfaces for EJB 3.0 session beans can still be looked up in the way described in the attached document <a href="http://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/uuid/0736159e-0301-0010-9ea4-c63d83d0797b">"Accessing EJB Applications Using JNDI"</a>. Although being targetted at SAP NetWeaver 04, it's still applicable to this Java EE 5 edition. The steps to create a 2.x style Home interface have been described by Sidharth above.
    Finally, I'd like to mention that you can always use the LSN command from the NAMING group in the Telnet Console Administrator to check the JNDI tree of your server. Another option would be to use the JNDI browser in the SAP NetWeaver Administrator. For more information please refer to the <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/806e75a0-0e01-0010-2587-fc518de8ac1a">Administration Guide</a>.
    Best regards,
    Vladimir

Maybe you are looking for