JNDI Lookup in loca JVM

I am using the following properties to get an InitialContext to lookup an EJB:
INITIAL_CONTEXT_FACTORY: com.sun.jndi.cosnaming.CNCtxFactory
PROVIDER_URL: iiop://localhost:3700
The EJBs are hosted on Sun AS8.1. If I use these properties from an external client, Tomcat webapp, then everything works fine. However, if I deploy the webapp as part of the ear along with the ejbs and try to access the webapp on the Sun Server then I get the following error when trying to get the InitialContext.
If I don't include the two properties when getting the InitialContext then everything works fine on the Sun AS server as well.
Does anyone have any idea why the first configiraton would fail??
Thanks,
Pete Giesin
[#|2005-12-05T11:08:03.000-0500|SEVERE|sun-appserver-pe8.1_02|javax.enterprise.resource.corba._DEFAULT_.rpc.transport|_ThreadID=14;|"IOP00410216: (COMM_FAILURE) Unable to create IIOP listener on the specified host/port: all interfaces/3700"
org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 216 completed: No
     at com.sun.corba.ee.impl.logging.ORBUtilSystemException.createListenerFailed(ORBUtilSystemException.java:2661)
     at com.sun.corba.ee.impl.logging.ORBUtilSystemException.createListenerFailed(ORBUtilSystemException.java:2681)
     at com.sun.corba.ee.impl.transport.SocketOrChannelAcceptorImpl.initialize(SocketOrChannelAcceptorImpl.java:167)
     at com.sun.corba.ee.impl.transport.CorbaTransportManagerImpl.getAcceptors(CorbaTransportManagerImpl.java:207)
     at com.sun.corba.ee.impl.transport.CorbaTransportManagerImpl.addToIORTemplate(CorbaTransportManagerImpl.java:224)
     at com.sun.corba.ee.spi.oa.ObjectAdapterBase.initializeTemplate(ObjectAdapterBase.java:104)
     at com.sun.corba.ee.impl.oa.toa.TOAImpl.<init>(TOAImpl.java:78)
     at com.sun.corba.ee.impl.oa.toa.TOAFactory.getTOA(TOAFactory.java:65)
     at com.sun.corba.ee.impl.orb.ORBImpl.connect(ORBImpl.java:1536)
     at com.sun.corba.ee.spi.presentation.rmi.StubAdapter.connect(StubAdapter.java:164)
     at com.sun.corba.ee.impl.orbutil.ORBUtility.connectAndGetIOR(ORBUtility.java:825)
     at com.sun.corba.ee.impl.orb.ORBImpl.getFVDCodeBaseIOR(ORBImpl.java:901)
     at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.addServiceContexts(CorbaClientRequestDispatcherImpl.java:737)
     at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:227)
     at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:127)
     at com.sun.corba.ee.impl.resolver.BootstrapResolverImpl.invoke(BootstrapResolverImpl.java:77)
     at com.sun.corba.ee.impl.resolver.BootstrapResolverImpl.resolve(BootstrapResolverImpl.java:110)
     at com.sun.corba.ee.impl.resolver.CompositeResolverImpl.resolve(CompositeResolverImpl.java:22)
     at com.sun.corba.ee.impl.resolver.CompositeResolverImpl.resolve(CompositeResolverImpl.java:22)
     at com.sun.corba.ee.impl.resolver.CompositeResolverImpl.resolve(CompositeResolverImpl.java:22)
     at com.sun.corba.ee.impl.orb.ORBImpl.resolve_initial_references(ORBImpl.java:1221)
     at com.sun.jndi.cosnaming.CNCtx.setOrbAndRootContext(CNCtx.java:340)
     at com.sun.jndi.cosnaming.CNCtx.initUsingIiopUrl(CNCtx.java:289)
     at com.sun.jndi.cosnaming.CNCtx.initUsingUrl(CNCtx.java:245)
     at com.sun.jndi.cosnaming.CNCtx.initOrbAndRootContext(CNCtx.java:209)
     at com.sun.jndi.cosnaming.CNCtx.<init>(CNCtx.java:69)
     at com.sun.jndi.cosnaming.CNCtxFactory.getInitialContext(CNCtxFactory.java:32)
     at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
     at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247)
     at javax.naming.InitialContext.init(InitialContext.java:223)
     at javax.naming.InitialContext.<init>(InitialContext.java:197)
     at dstb.servicelocator.InitialContextCreator.getInitialContext(InitialContextCreator.java:77)
     at dstb.servicelocator.ExaminedServiceLocator.getRemoteEJBHome(ExaminedServiceLocator.java:213)
     at dstb.servicelocator.ExaminedServiceLocator.getRemoteEJB(ExaminedServiceLocator.java:114)
     at dstb.common.EJBShare.getEJB(EJBShare.java:675)
     at dstb.servletapi.stbprovision.StbStatusSelectorObj.getStatus(StbStatusSelectorObj.java:35)
     at cvnet.servlet.Home_cab.doGet(Home_cab.java:63)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:747)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
     at sun.reflect.GeneratedMethodAccessor64.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:585)
     at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
     at java.security.AccessController.doPrivileged(Native Method)
     at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
     at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
     at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
     at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
     at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
     at java.security.AccessController.doPrivileged(Native Method)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:263)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
     at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:225)
     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:173)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:132)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
     at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:933)
     at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:185)
     at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:653)
     at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:534)
     at com.sun.enterprise.web.connector.grizzly.ProcessorTask.doTask(ProcessorTask.java:403)
     at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:55)
Caused by: java.lang.Error: Untranslated exception
     at sun.nio.ch.Net.translateToSocketException(Net.java:63)
     at sun.nio.ch.Net.translateException(Net.java:79)
     at sun.nio.ch.Net.translateException(Net.java:85)
     at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:61)
     at com.sun.enterprise.server.ss.ASServerSocket.bind(ASServerSocket.java:258)
     at com.sun.enterprise.server.ss.ASServerSocket.bind(ASServerSocket.java:231)
     at com.sun.enterprise.iiop.IIOPSSLSocketFactory.createServerSocket(IIOPSSLSocketFactory.java:289)
     at com.sun.corba.ee.impl.transport.SocketOrChannelAcceptorImpl.initialize(SocketOrChannelAcceptorImpl.java:160)
     ... 64 more
Caused by: java.net.SocketException: Already bound
     at sun.nio.ch.Net.translateToSocketException(Net.java:49)
     ... 71 more
Caused by: sun.nio.ch.AlreadyBoundException
     at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:114)
     at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
     ... 68 more
|#]

To answer my own question, a fairly straight-forward way of achieving this is to use two configurations for the application module: one for testing locally (the supplied configuration), and another one for deployment that is a copy of the first except for the JNDI name. I can switch between the configurations via the Databindings depending on whether I want to test locally or deploy to Tomcat.
This is certainly a useable solution, but I'm bothered by the fact that I need to reference the JNDI name in two different ways. Shouldn't this be container-independent?
-Matt

Similar Messages

  • Objects returned via JNDI Lookup

    All,
    I have had this nagging question in my head about JNDI lookups for some time
    now, but haven't had the time to do the proper research. The question is
    simple.
    The setup is simple as well. Suppose that we have a typical WLS setup, with
    WLS running in a JVM on a server host somewhere, with objects bound to its
    JNDI tree (we'll leave clustering out of the picture for simplicity's sake),
    and we also have a WLS client Java application. The client connects to WLS
    and performs various JNDI lookups on the server. Some of these objects
    implement java.io.Serializable, some do not.
    The question is, if the client uses JNDI to lookup an object that exsts in a
    separate JVM, and that object does not implement Serializable, how does this
    object come to be instantiated on the client?
    This leads to a second question: What exactly is getting returned from a
    JNDI lookup? A reference to an object or a copy of it? I can see that
    lookups within a single JVM would return a reference, but the cross-JVM
    lookup is less clear to me.
    Any and all help appreciated,
    -jc

    This leads to a second question: What exactly is getting returned from a
    JNDI lookup?From how I understand it, only Serializable objects are returned such as RMI
    stubs, which serve as proxies to EJB or other RMI servers registered in JNDI.
    - Thomas
    (ex-BONY too)
    Jonathan Castellani wrote:
    All,
    I have had this nagging question in my head about JNDI lookups for some time
    now, but haven't had the time to do the proper research. The question is
    simple.
    The setup is simple as well. Suppose that we have a typical WLS setup, with
    WLS running in a JVM on a server host somewhere, with objects bound to its
    JNDI tree (we'll leave clustering out of the picture for simplicity's sake),
    and we also have a WLS client Java application. The client connects to WLS
    and performs various JNDI lookups on the server. Some of these objects
    implement java.io.Serializable, some do not.
    The question is, if the client uses JNDI to lookup an object that exsts in a
    separate JVM, and that object does not implement Serializable, how does this
    object come to be instantiated on the client?
    This leads to a second question: What exactly is getting returned from a
    JNDI lookup? A reference to an object or a copy of it? I can see that
    lookups within a single JVM would return a reference, but the cross-JVM
    lookup is less clear to me.
    Any and all help appreciated,
    -jc

  • Websphere: Exception JNDI lookup

    Hi All,
    I am stuck up with JNDI lookup in WebSphere 6 from standalone non J2EE application client JVM.
    Client JVM has thrown the following exception while lookup:
    Feb 23, 2005 11:30:47 AM com.ibm.ws.naming.util.Helpers
    WARNING: jndiGetObjInstNoop
    Exception in thread "P=586654:O=0:CT" java.lang.ClassCastException: javax.naming.Reference
    javax.naming.NameNotFoundException: Context: Cell/nodes/Node01/servers/server1, name: Node01Cell/nodes/Nod
    e01/servers/server1: First component in name Cell/nodes/Node01/servers/server1 not found. Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0
    at org.omg.CosNaming.NamingContextPackage.NotFoundHelper.read(NotFoundHe
    lper.java:85)
    Both the WebSphere container and standalone client uses IBM JDK 1.4.2 and I have placed all necessary JAR files in the client's CLASSPATH, but still the ClassCastException resulted.
    Below is the sample code of the application client:
    Properties props = new Properties();
    props.put(Context.INITIAL_CONTEXT_FACTORY, "com.ibm.websphere.naming.WsnInitialContextFactory");
    props.put(Context.PROVIDER_URL, "iiop://localhost:2809");
    Context ctx = new InitialContext(props);
    Object obj =  ctx.lookup("System\config");Need help. Could someone please tell me what I am doing wrong?
    Regards,
    Srinivas

    I'm having the same problem:
    Jun 6, 2006 8:16:36 PM com.ibm.ws.naming.util.Helpers
    WARNING: jndiGetObjInstNoop
    java.lang.ClassCastException: javax.naming.Reference
         at com.test.jms.Sender.main(Sender.java:33)
    Adding <WAS_HOME>/lib/dynacache.jar into the classpath solved the problem.
    My environment is: WAS 6.0.0.1, WebSphere MQ 6.0, JMS Client Java Application running in RAD 6.0

  • OC4J, JNDI lookup and UserManager

    Hi
    Recently we decided to upgrade our Oracle9iAS to 9.0.3 from 9.0.2 and its JVM to 1.4.2_02 from 1.3.1.
    We have 2 customs implementations of UserManager that worked in the earlier version and, after the upgrade, it became unstable. Each UserManager uses a connection to a database provided by a DataSource, which is retrieved by a JNDI lookup. This lookup throws a NameNotFoundException after some time of execution. A container restart solves the problem, but it appears again later.
    What´s happening?
    Jose Antonio.

    Hi
    Recently we decided to upgrade our Oracle9iAS to 9.0.3 from 9.0.2 and its JVM to 1.4.2_02 from 1.3.1.
    We have 2 customs implementations of UserManager that worked in the earlier version and, after the upgrade, it became unstable. Each UserManager uses a connection to a database provided by a DataSource, which is retrieved by a JNDI lookup. This lookup throws a NameNotFoundException after some time of execution. A container restart solves the problem, but it appears again later.
    What´s happening?
    Jose Antonio.

  • Cost of a local JNDI lookup

    5.1sp8
    I always thought that cost of a local JNDI lookup is pretty
    small, but just found that it is not:
    application JSP's extend common superclass which does(did!) JNDI
    lookup based on the URI and sets a threadlocal variable before
    invoking jspservice() method.
    During performance testing replacing JNDI with a static hashtable
    improved thoughput by ~25-30% (pages themselves are very fast -
    mostly jsp cache tags hits).
    Weird.
    Dimitri

    First of all I am not caching the Initial Context. I am caching the results
    of the initial context lookup into a hashmap (I have changed this from
    hashtable, which I proposed originally in my posting - see my latest post).
    Second, if you have client running in seperate JVM, can not lookup the
    hashmap created by the server.
    Third, on the server side, you cannot get a reference of a startup class.
    The server simply instantiates the class and invoke startup() method (from
    T3StartupDef interface) and it does not keep reference after startup()
    method returns. But you could use another class that you want to get an
    instance of by creating it within the startup class and provide a static
    method to create/return that instance. I guess the proper way of saying it
    would be create the hashmap as a class variable in a singleton class
    (hopefully you get the idea)...
    .raja
    -----Original Message-----
    From: Mittal, Raj [mailto:[email protected]]
    Sent: Wednesday, June 20, 2001 1:16 PM
    To: '[email protected]'
    Subject: Re: cost of a local JNDI lookup
    Raja,
    We are also wrapping all the JNDI requirements in a startup class and WL
    loads it automatically. Now my problem is how to access the InitalContext
    (initialized by startup class) by a client and also on the server side. If
    you have any code that explains that, please pass it along.
    Thanks
    Raj Mittal
    Front Office Group
    NEUBERGER BERMAN
    *(646) 497-4224
    "Raja Mukherjee" <[email protected]> wrote in message
    news:[email protected]...
    Mike,
    Thanks for the reply to the previous message. For the particularbenchmark,
    I knew all the JNDI lookup requirements at the design time (I think that
    would be the case in most applications), so I wrapped them into a startup
    class.
    .raja
    "mike " <[email protected]> wrote in message
    news:[email protected]...
    In the code where you need the context ...
    static Hashtable h=new Hashtable();
    ctx=h.get(ctx_name);
    if(ctx == null){
    ctx=new InitialContext(... args ...);
    h.put(ctx_name, ctx);
    mike
    Kirk Everett <[email protected]> wrote:
    Can you explan what you mean by "use a static hash table"? We did some
    load
    testing on 6.0 SP 1 and saw that
    creating an local initial context is fairly costly and I would like to
    understand your solution. Thanks.
    Kirk
    Raja Mukherjee wrote:
    Dimitri,
    I was surprised to see that in WLS 5.1. I have seen this on 6.0 and
    understood that JNDI lookups need to be sereilized because of the newclass
    loader. In the recent benchmark, for 6.0 we found that the about
    15-20%
    of
    the (client's) application CPU time was spent on JNDI lookup
    (serealization). We changed it to a static hash table.
    Unfortunately, I am only seeing marginal gain in 5.1sp8.
    For all 6.0 applications we are going to use static hashtable. Mightas well
    do it now for 5.1 so that your migration to 6.0 will be easier :).
    .raja
    "Daniel Hoppe" <[email protected]> wrote in message
    news:[email protected]...
    This is irritating. If I remember correctly, until now the official
    statement was that it's not even worth caching an InitialContext ifit's
    a local one. Guess I'll have to review my application for this as
    well.
    >>>>
    Daniel
    -----Ursprüngliche Nachricht-----
    Von: Dimitri Rakitine [mailto:[email protected]]
    Bereitgestellt: Freitag, 15. Juni 2001 05:17
    Bereitgestellt in: performance
    Unterhaltung: cost of a local JNDI lookup
    Betreff: cost of a local JNDI lookup
    5.1sp8
    I always thought that cost of a local JNDI lookup is pretty
    small, but just found that it is not:
    application JSP's extend common superclass which does(did!) JNDI
    lookup based on the URI and sets a threadlocal variable before
    invoking jspservice() method.
    During performance testing replacing JNDI with a static hashtable
    improved thoughput by ~25-30% (pages themselves are very fast -
    mostly jsp cache tags hits).
    Weird.
    Dimitri

  • JNDI lookup from Portal Application Module

    Dear Experts,
    I have a problem with looking up a Deployable Web Service Proxy from within a Portal Application Module.
    I use NWDI and created both the Deployable WS Proxy DC and the Portal App DC.
    I added the generated Proxy to the Proxy DC's public part and added it as used DC to the Portal Module DC.
    When I perform the JNDI lookup, no exception is thrown but the Code is not executed any further...
    Here is the source:
    Category.APPLICATIONS.infoT( loc, "lookup JNDI...", new Object[] { this });
    Object o = ctx.lookup(JNDI_NAME);
    Category.APPLICATIONS.infoT( loc, o.getClass().getName(), new Object[] { this });
    service = (OrchestrationService)o;
    Category.APPLICATIONS.infoT(loc, "success!", new Object[] { this });
    The log shows the name of the class (OrchestrationServiceImpl) but not the success! part.
    As I said: No exceptions are thrown...
    Any help is appreciated!
    Matthias

    Solved the problem!
    It's allways the same:
    As soon as you ask the question the answer comes to you by itself...
    I needed to add a reference to the using DC. I already did that before but not correctly:
    If you want to add a reference to a j2ee application you need to read this document:
    [Calling J2EE Applications from Portal Applications|http://help.sap.com/erp2005_ehp_03/helpdata/EN/42/9ddf20bb211d72e10000000a1553f6/frameset.htm]
    It says the reference has to look like this:
    <property name="SharingReference" value="SAPJ2EE::sap.com/Hello"/>
    I hope it helps someone.

  • JNDI lookup Issue

    All,
    I have this question in my head about JNDI lookups, but haven't received proper
    information when i do research. The question is simple.
    The setup is simple as well. Suppose that we have a typical WLS cluster setup,
    with
    WLS running in a JVM on a server host somewhere, with objects bound to its
    JNDI tree, and we also have a WLS client Java application. The client connects
    to WLS
    and performs JNDI lookups on the server.
    The question is, if the client uses JNDI to lookup an object that exists in a
    separate JVM, it does load balancing and failover properly. Alternatively, if
    client uses same JVM to lookup an object in failover case, we are encountering
    application specific error. I just need to know what makes difference when you
    lookup an object(RMI) from same JVM and separate JVM.
    Any and all help appreciated,
    -Senthil

    No one?

  • EJB 3.0 and jndi lookup (simple question)

    hi all,
    i am newbie on Weblogic Application Server and i have some issues,
    i have weblogic application server 10.0, also i have oracle timesten in-memory database, i have configured datasource and deploy my ejb 3.0 application, but i could not done jndi lookup?
    here is my example:
    1. one stateless session bean :
    import javax.ejb.Remote;
    @Remote
    public interface InsertSubscriber {
         public void insertSubscriber(SubscriberT subscriberT);
    } 2. here is it's implementation :
    @Remote(InsertSubscriber.class)
    @Stateless
    public class InsertSubscriberBean implements InsertSubscriber {
         @PersistenceContext(unitName = "TimesTenDS")
         private EntityManager oracleManager;
         public void insertSubscriber(SubscriberT subscriber)
              try {
                   System.out.println("started");
                   oracleManager.persist(subscriber);
                   System.out.println("end");
              } catch (Exception e) {
                   e.printStackTrace();
    }3 and my test client :
    public class Client {
         public static void main(String[] args) {
              Context ctx = null;
              Hashtable ht = new Hashtable();
              ht.put(Context.INITIAL_CONTEXT_FACTORY,
                        "weblogic.jndi.WLInitialContextFactory");
              ht.put(Context.PROVIDER_URL, "t3://192.9.200.222:7001");
              try {
                   ctx = new InitialContext(ht);
                   InsertSubscriber usagefasade = (InsertSubscriber) ctx
                             .lookup("ejb.InsertSubscriberBean");               
              } catch (NamingException e) {
                   e.printStackTrace();
              } finally {
                   try {
                        ctx.close();
                   } catch (Exception e) {
                        e.printStackTrace();
    }what i did incorrect ???
    i got error like this : Name not fount exception
    when i tried to view jndi tree on weblogic server application console i found this :
         Binding Name:     
    TimestenExampleTimestenExample_jarInsertSubscriberBean_InsertSubscriber     
         Class:     
    test.InsertSubscriberBean_o7jk9u_InsertSubscriberImpl_1000_WLStub     
         Hash Code:     
    286     
         toString Results:     
    weblogic.rmi.internal.CollocatedRemoteRef - hostID: '2929168367193491522S::billing_domain:AdminServer', oid: '286', channel: 'null'what does it mean how i can done lookup to jndi ?
    Regards,
    Paata Lominadze,
    Magticom LTD.
    Georgia.

    Hi All,
    I am using the weblogic cluster with session replication and EJB 2.0 with Local entity beans.
    for fail-over session should be replicated to another server so we can achive the same session if 1st server fails.
    Suppose i m using two managed server(server1,server2) in the cluster.I am storing the object of class ABC into session and object contains the instance of Local-EntityBean home but i put that as a transient.I have also override the readObject and write object method.
    when write object is called on 1st server,readObject method should be called on second server so we will be sure that session is replicating properly.
    pleaase find the code below : -
    public IssuerPageBean() {
    initEJB();
    private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException {
    stream.defaultReadObject();
    initEJB();
    initializeCommonObject();
    private void writeObject(java.io.ObjectOutputStream stream) throws IOException {
    stream.defaultWriteObject();
    private void initEJB() {
    try {
    ic = new InitialContext();
    issuerHome = (LocalIssuerHome) ic.lookup("java:comp/env/Issuer");
    } catch (NamingException e) {
    e.printStackTrace();
    in my case if i am calling the constructor IssuerPageBean(),it calls the initEJB() method and lookeup the entity local home properly but when readObject method is called on another server only initEJB() method is called directly and getting the exception below :
    WARNING: Error during create -
    javax.naming.NameNotFoundException: remaining name: env/ejb/Client
    at weblogic.j2eeclient.SimpleContext.resolve(Ljavax/naming/Name;Z)Ljavax/naming/Context;(SimpleContext.java:35)
    at weblogic.j2eeclient.SimpleContext.resolve(Ljavax/naming/Name;)Ljavax/naming/Context;(SimpleContext.java:39)
    at weblogic.j2eeclient.SimpleContext.lookup(Ljavax/naming/Name;)Ljava/lang/Object;(SimpleContext.java:57)
    at weblogic.j2eeclient.SimpleContext.lookup(Ljavax/naming/Name;)Ljava/lang/Object;(SimpleContext.java:57)
    at weblogic.j2eeclient.SimpleContext.lookup(Ljava/lang/String;)Ljava/lang/Object;(SimpleContext.java:62)
    at weblogic.jndi.factories.java.ReadOnlyContextWrapper.lookup(Ljava/lang/String;)Ljava/lang/Object;(ReadOnlyCont
    extWrapper.java:45)
    at weblogic.jndi.internal.AbstractURLContext.lookup(Ljava/lang/String;)Ljava/lang/Object;(AbstractURLContext.jav
    a:130)
    at javax.naming.InitialContext.lookup(Ljava/lang/String;)Ljava/lang/Object;(InitialContext.java:347)
    at com.lb.equities.veda.tools.salesvault.jsp.ClientPageBean.initEJB()V(ClientPageBean.java:218)
    at com.lb.equities.veda.tools.salesvault.jsp.ClientPageBean.readObject(Ljava/io/ObjectInputStream;)V(ClientPageB
    ean.java:191)
    at java.lang.LangAccessImpl.readObject(Ljava/lang/Class;Ljava/lang/Object;Ljava/io/ObjectInputStream;)V(Unknown
    Source)
    at java.io.ObjectStreamClass.invokeReadObject(Ljava/lang/Object;Ljava/io/ObjectInputStream;)V(Unknown Source)
    at java.io.ObjectInputStream.readSerialData(Ljava/lang/Object;Ljava/io/ObjectStreamClass;)V(Unknown Source)
    at java.io.ObjectInputStream.readOrdinaryObject(Z)Ljava/lang/Object;(Unknown Source)
    at java.io.ObjectInputStream.readObject0(Z)Ljava/lang/Object;(Unknown Source)
    at java.io.ObjectInputStream.readObject()Ljava/lang/Object;(Unknown Source)
    at java.util.HashMap.readObject(Ljava/io/ObjectInputStream;)V(Unknown Source)
    at java.lang.LangAccessImpl.readObject(Ljava/lang/Class;Ljava/lang/Object;Ljava/io/ObjectInputStream;)V(Unknown
    Source)
    at java.io.ObjectStreamClass.invokeReadObject(Ljava/lang/Object;Ljava/io/ObjectInputStream;)V(Unknown Source)
    at java.io.ObjectInputStream.readSerialData(Ljava/lang/Object;Ljava/io/ObjectStreamClass;)V(Unknown Source)
    at java.io.ObjectInputStream.readOrdinaryObject(Z)Ljava/lang/Object;(Unknown Source)
    at java.io.ObjectInputStream.readObject0(Z)Ljava/lang/Object;(Unknown Source)
    at java.io.ObjectInputStream.defaultReadFields(Ljava/lang/Object;Ljava/io/ObjectStreamClass;)V(Unknown Source)
    at java.io.ObjectInputStream.readSerialData(Ljava/lang/Object;Ljava/io/ObjectStreamClass;)V(Unknown Source)
    at java.io.ObjectInputStream.readOrdinaryObject(Z)Ljava/lang/Object;(Unknown Source)
    at java.io.ObjectInputStream.readObject0(Z)Ljava/lang/Object;(Unknown Source)
    at java.io.ObjectInputStream.readObject()Ljava/lang/Object;(Unknown Source)
    at weblogic.common.internal.ChunkedObjectInputStream.readObject()Ljava/lang/Object;(ChunkedObjectInputStream.jav
    a:120)
    at weblogic.rjvm.MsgAbbrevInputStream.readObject(Ljava/lang/Class;)Ljava/lang/Object;(MsgAbbrevInputStream.java:
    121)
    at weblogic.cluster.replication.ReplicationManager_WLSkel.invoke(ILweblogic/rmi/spi/InboundRequest;Lweblogic/rmi
    /spi/OutboundResponse;Ljava/lang/Object;)Lweblogic/rmi/spi/OutboundResponse;(Unknown Source)
    at weblogic.rmi.internal.BasicServerRef.invoke(Lweblogic/rmi/extensions/server/RuntimeMethodDescriptor;Lweblogic
    /rmi/spi/InboundRequest;Lweblogic/rmi/spi/OutboundResponse;)V(BasicServerRef.java:492)
    Please help .
    Thanks in Advance.
    Edited by hforever at 03/04/2008 7:28 AM

  • EJB 3.0 JNDI lookup gives ClassCastException

    The object returned by the JNDI lookup of a EJB 3.0 Statefull Session Bean is not of the expected type, but rather of an obviously generated Proxy type (ejb_DistributionProcessor_LocalProxy_4h350 instead of expected DistributionProcessor). Does anybody have any idea about what this could be?
    Details:
    We are using annotations @Statefull and @Local and are deploying on a standalone OC4J 10.1.3.1. The beans are presumably loaded correctly since they get listed in Enterprise Managers list of beans for the application. There is also obviously an object at the desired JNDI location, presumably some kind of proxy. Unfortunately the proxy cannot be cast to the original type making the retrieved object useless.
    I can supply more details if necessary, but really don't know what more is relevant.

    Well, I figured it out, it seems I had the classes in both the EJB and the WEB deployment, so when casting it tried to cast X from EJB to X from WEB application and since they reside in different locations they weren't the same file and therefore not castable.

  • JNDI Lookup in JSP fails for EJB 3.0

    I am new to Java technology. I read the EJB FAQ, NetBeans docs and may forum discussions and I am still confused with the error I am having.
    Background:
    I have developed a persistance bean and related sessions beans (similar to the customer-cmp-ear application in the Java App Server samples). Now I am trying to access this bean using a JSP. After deploying the war file in the App Server and try to access the page, I get the following error.
    javax.naming.NameNotFoundException: No object bound to name java:comp/env/ConsumerSessionLocal
    After reading many articles, I understood that I dont have to prepare any descriptors, or JAR files for EJB 3.0.
    Environment Details:
    Java App Server Ver 9.0
    NetBeans 5.5
    I normally build the war files using NetBeans.
    I use App Server Admin console to deploy the web applications using the above war file.
    EJB details:
    Persistance EJB : person.java
    Session Objects
    Consumer.java (this implements ConsumerSessionLocal, ConsumerSessionRemote). This Stateless bean accesses the methods in person.java.
    ConsumerSessionLocal.java - local interface
    ConsumerSessionRemote.java - remote interface
    SearchConsumer.jsp
    This JSP page is calling the ConsumerSessionLocal using the JNDI lookup through InitialContext.
    Here is the Code snippet:
    try {
    InitialContext ic = new InitialContext();
    Object o = ic.lookup("java:comp/env/ConsumerSessionLocal");
    ConsumerSessionLocal consSession = (ConsumerSessionLocal) o;
    I am able to see the jsp page in the browser, however, after a submit action, I get the Java Naming Exception error.
    javax.naming.NameNotFoundException: No object bound for java:comp/env/ConsumerSessionLocal
    I would appreciate your help/any of your thoughts.
    Thanks in advance.
    -Ram

    I did not really solve it. Instead I used some of the tutorials that used JNDI lookup and modified those as my way forward. I did not really find out exactly what I was doing wrong.
    /Anders

  • JNDI lookup issue in weblogic 10 server

    Hi all,
    I have a serious problem in getting the datasource lookup. My application uses EJB3 and JPA and it is deployed in weblogic10. I configured datasource in the domain (ex:mydomain) using weblogic 10 admin console. Now when i try to call from a client program, it is giving me javax.naming.NameNotFoundException. I use eclipse IDE to deploy the application. From the IDE, i can start the oracle 10.3 server and it automatically deploys the application into the server in mydomain. The admin console shows that the application deployed fine. And i can see the webcontent WAR file and EJB jar deployed. Coming back to the issue.... I verified user_projects\domains\mydomain\config\jdbc\datasource-jdbc.xml and user_projects\domains\mydomain\config\config.xml file enteries. My entries are present in those files.
    When i start the server i am getting below error...
    << Stacktrace >>
    javax.naming.NameNotFoundException: While trying to look up jdbc in /app.; remaining name 'jdbc'
         at weblogic.jndi.internal.BasicNamingNode.newNameNotFoundException(BasicNamingNode.java:1139)
         at weblogic.jndi.internal.ApplicationNamingNode.lookup(ApplicationNamingNode.java:144)
         at weblogic.jndi.internal.WLEventContextImpl.lookup(WLEventContextImpl.java:254)
         at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:380)
         at weblogic.deployment.PersistenceUnitInfoImpl.lookUpAppScopedDataSource(PersistenceUnitInfoImpl.java:529)
         at weblogic.deployment.PersistenceUnitInfoImpl.reconfig(PersistenceUnitInfoImpl.java:549)
         at weblogic.ejb.container.deployer.EJBModule.reconfigPersistenceUnits(EJBModule.java:529)
         at weblogic.ejb.container.deployer.EJBModule.activate(EJBModule.java:515)
         at weblogic.application.internal.flow.ModuleListenerInvoker.activate(ModuleListenerInvoker.java:107)
         at weblogic.application.internal.flow.DeploymentCallbackFlow$2.next(DeploymentCallbackFlow.java:411)
         at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37)
         at weblogic.application.internal.flow.DeploymentCallbackFlow.activate(DeploymentCallbackFlow.java:74)
         at weblogic.application.internal.flow.DeploymentCallbackFlow.activate(DeploymentCallbackFlow.java:66)
         at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:635)
         at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37)
         at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:212)
         at weblogic.application.internal.EarDeployment.activate(EarDeployment.java:16)
         at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:162)
         at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:79)
         at weblogic.deploy.internal.targetserver.operations.AbstractOperation.activate(AbstractOperation.java:569)
         at weblogic.deploy.internal.targetserver.operations.ActivateOperation.activateDeployment(ActivateOperation.java:140)
         at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doCommit(ActivateOperation.java:106)
         at weblogic.deploy.internal.targetserver.operations.AbstractOperation.commit(AbstractOperation.java:323)
         at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentCommit(DeploymentManager.java:820)
         at weblogic.deploy.internal.targetserver.DeploymentManager.activateDeploymentList(DeploymentManager.java:1227)
         at weblogic.deploy.internal.targetserver.DeploymentManager.handleCommit(DeploymentManager.java:436)
         at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.commit(DeploymentServiceDispatcher.java:163)
         at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doCommitCallback(DeploymentReceiverCallbackDeliverer.java:181)
         at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$100(DeploymentReceiverCallbackDeliverer.java:12)
         at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$2.run(DeploymentReceiverCallbackDeliverer.java:67)
         at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516)
         at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
         at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
    << Client program snippet >>
    Hashtable ht = new Hashtable();
                   ht.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.WLInitialContextFactory");
                   ht.put(Context.PROVIDER_URL, "t3://10.237.76.132:7001");
                   InitialContext ctx = null;
                   ctx = new InitialContext(ht);
                   Object obj = (Object)ctx.lookup(EmployeeBean.RemoteJNDIName);
                   EmployeeRemote empRemote = (EmployeeRemote)PortableRemoteObject.narrow(obj,com.acs.test.emp.EmployeeRemote.class);
                   List empList = empRemote.getEmployeeDetails(1);
                   System.out.println("SUCCESS"+empList.size());
    << Persistence.xml >>
    <?xml version="1.0" encoding="UTF-8"?>
    <!-- Persistence deployment descriptor for dev profile -->
    <persistence 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"
    version="1.0">
    <persistence-unit name="cmsepool">
    <jta-data-source>java:/mydatasource</jta-data-source>
              <class>com.acs.test.emp.EmployeeVO</class>
              <properties>
    <property name="hibernate.dialect" value="org.hibernate.dialect.HSQLDialect"/>
              <property name="hibernate.transaction.manager_lookup_class" value="org.hibernate.transaction.WeblogicTransactionManagerLookup"/>
    </properties>
    </persistence-unit>
    </persistence>

    Make sure that this Datasource you created is Targetted to Admin Server and full Cluster (incase of cluster domain). From Admin Console, select your datasource and check for the Targets tab. Since its JNDI lookup error, most probably it may not be deployed properly.
    HTH
    Ravi Jegga

  • Is it possible to test XI Adapter on PCK by JNDI lookup?

    Hi, friends
    I can't test the XI Adapter by using the communication channels and sender/receiver agreements on a standalone PCK (without XI server to be connected). Is it possible to test XI Adapter on PCK by JNDI lookup?
    I can locate the XI Adapter by JNDI lookup (JNDI name is configured on SampleRA.xml):
    ConnectionFactory cxf = (ConnectionFactory)initctx.lookup("deployedAdapters/sample_ra/shareable/sample_ra");
    But later it failed to get the ConnectionSpec and create the Connection. Could anyone give me a sample code for testing XI Adapter by JNDI lookup?
    Thanks in advance.
    Best Regards,
    Jason
    Message was edited by: Jason Wang

    Hi,
    I'm not sure if this is what you are looking for but
    check the link "Using Resource Adapter to Obtain Connection" on this site:
    http://help.sap.com/saphelp_nw04/helpdata/de/89/b262427a65423f87706a0e3faea00d/frameset.htm
    Hope it helps,
    Christian

  • JNDI Lookup in OC4J *AND* Tomcat 5 (not either/or)

    I've been struggling to get a web application to deploy and run correctly on Tomcat 5.x. I couldn't ADF to look up the Datasource I'd set up in the Tomcat configs. After reading this forum post:
    Problem deploying BC4J Toy Store app on Tomcat 4
    I was able to run my test app successfully on Tomcat by prepending 'java:comp/env/' to the JNDI name of my Datasource in bc4j.xcfg. Unfortunately, specifying the JNDI name in this way breaks the JNDI lookup in the embedded OC4J container. The impression I got from the above forum post was that OC4J should be able to look up the data source when the name is specified as either jndi/myDataSource or java:comp/env/jndi/myDataSource. I can only get it to work with the former.
    Is there a way to specify the JNDI name of a datasource in bc4j.xcfg such that both Tomcat AND the embedded OC4J container within JDeveloper will be able to look it up?
    Thanks,
    -Matt

    To answer my own question, a fairly straight-forward way of achieving this is to use two configurations for the application module: one for testing locally (the supplied configuration), and another one for deployment that is a copy of the first except for the JNDI name. I can switch between the configurations via the Databindings depending on whether I want to test locally or deploy to Tomcat.
    This is certainly a useable solution, but I'm bothered by the fact that I need to reference the JNDI name in two different ways. Shouldn't this be container-independent?
    -Matt

  • Best practice for jndi lookup

    I am in the process of cleaning up a rather large codebase and am looking for the best way (or good methodologies I can choose from) for specifying the jndi lookup name. Our current code base has the following methods for specifying the lookup name:
    1) hard-coded strings
    2) constant defined in the file making lookup
    3) constant defined in external interface
    4) constant defined in EJB Home interface
    My initial thought was to create a single interface and put all the constants within it and have any class that wants to perform a lookup implement that interface. But before I went and did that I wanted to see if there were any other methods out there.
    I searched the forums (EJB/JNDI) but could not find anything that specified any method that was preferred.
    TIA

    I am in the process of cleaning up a rather large
    codebase and am looking for the best way (or good
    methodologies I can choose from) for specifying the
    jndi lookup name. Our current code base has the
    following methods for specifying the lookup name:
    1) hard-coded strings
    2) constant defined in the file making lookup
    3) constant defined in external interface
    4) constant defined in EJB Home interface
    constant defined in external interface
    My initial thought was to create a single interface
    and put all the constants within it and have any
    class that wants to perform a lookup implement that
    interface.
    sounds great !

  • JNDI lookup from a Java stored proc?

    Anybody know if a JNDI lookup, or accessing an EJB from a Java stored procedure is possible? I looked through all the docs and it says it is possible but doesn't specify how. In the java class thats resolved through the stored proc, how are the server generated classes and interfaces made available? Normally setting the classpath for the client app that does the lookup accomplishes this, but what if its called through the stored proc?

    check the rdbms platform's "javavm" folder for a "readme.txt" file ...
    In section 3.16.9, it discusses how to do this ...

Maybe you are looking for

  • Redeeming tones after installing 8.1.2

    The update told me I would be able to redeem my tones that were lost after my update. How may I go about doing that?

  • Using SUM BY to limit result of 3 union queries (11g)

    Hey guys, First time posting here (btw, I've tried changing my handle name via edit profile here to no success! Ugh!). I need to modify a report that's built off of 3 union queries.  Here's a simplified table version of the union result: Label Year C

  • How to UnZip Binary Distribution?

    I have downloaded the Binary distribution, but I can't figure out how to unzip it. My OS is windows XP. Thank you.

  • Error while accessing Oracle Virtual Directory 11g client view.

    Hi everyone, I'm a beginner in Oracle IDAM suite 11g. I'm facing an issue while configuring LDAP adapter in Oracle Virtual Directory. LDAP adapter is configured for ODSEE instances. Currently I've configured two instances. For these adapters, the ent

  • OER message on ASR 1000 RP2

    Hello! I have an issue regarding to an ASR 1006 RP2 (Cisco IOS XE Software, Version 03.10.01.S) I was removing a prefix, to stop announcing to an ISP: no ip prefix-list announced_prefixes seq 10 permit X.X.X.X/Y router bgp XXXX address-family ipv4 no