WLS/OSB DB Adapter - JNDI lookup failed

Hello all.
I've got a DB adapter service set up in a clustered environment, and it all works (and I've built proxy services, transformations etc around it), but I've just noticed that the log shows a warning regarding the JNDI lookup of the ConnectionFactory, as below.
It's working, and the error is only a warning, but could this cause problems going forward, particularly with regards performance?
Given that the ConnectionFactory name is 'com.whatever.myServiceDB', and the Endpoint URI of the service is 'jca://com.whatever.myServiceDB', what could be wrong? Has anyone seen/fixed this before? It's almost like the managed servers don't know about the JNDI name...but the DbAdapter deployent has 'All servers in the cluster' selected in its 'Targets' tab, so I'm not sure.
Any pointers would be appreciated, I'm probably missing something obvious.
Cheers.
####<Apr 15, 2010 10:53:10 AM BST> <Warning> <JCA_FRAMEWORK_AND_ADAPTER> <servername> <managed3_domainname> <[ACTIVE] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1271325190453> <BEA-000000> <servicebus:/WSDL/MyProject/MyService [ MyService_ptt::merge(MessagesCollection) ] - JNDI lookup of 'com.whatever.myServiceDB' failed due to: String index out of range: -1>

Thanks again.
In case anyone runs into a similar problem and is wondering: a bit of mucking about reveals that the WLS ConnectionFactory config is fine with dots or slashes, and it seems to treat both the same when creating the JNDI tree.
However, the WSDL (that you probably created in JDeveloper) has to have slashes for doing its lookup. So, for example, always use slashes rather than dots when setting your DB Adapter JNDI name in JDeveloper. I guess this is a bit different from usual class/package naming standards, so may catch someone else out too.
Cheers.

Similar Messages

  • JNDI lookup fails in a thread created by J2EE application on WAS 8.0.0.4 running on Red Hat Enterprise Server 5.8(2.6.18-308.e15).

    I am using Jackrabbit Repository (jcr's implementation) as backend in my Web Appl.Whose data persists on Oracle Database. To make connection with Oracle database jackrabbit provide provision of JNDI Lookup to read the data source defined in WAS (using WAS 8.0.0.4 as App Server).
    I am able to perform JNDI Lookup everywhere in my application,But in a flow where i am creating a Thread using Java Concurrent Api and insidethread's call() method when I am trying for JNDI Look following exception occurs –
    [8/20/13 10:57:35:163 IST] 000000dd System Out     O ERROR 20-08 10:57:35,163 (DatabaseFileSystem.java:init:209)            failed to initialize file system
    javax.jcr.RepositoryException: JNDI name not found: java:comp/env/jdbc/ofsds
    at org.apache.jackrabbit.core.util.db.ConnectionFactory.getJndiDataSource(ConnectionFactory.java:295)
    at org.apache.jackrabbit.core.util.db.ConnectionFactory.createDataSource(ConnectionFactory.java:233)
    at org.apache.jackrabbit.core.util.db.ConnectionFactory.getDataSource(ConnectionFactory.java:166)
    at org.apache.jackrabbit.core.fs.db.DbFileSystem.getDataSource(DbFileSystem.java:226)
    at org.apache.jackrabbit.core.fs.db.DatabaseFileSystem.init(DatabaseFileSystem.java:190)
    at org.apache.jackrabbit.core.config.RepositoryConfigurationParser$6.getFileSystem(RepositoryConfigurationParser.java:1057)
    at org.apache.jackrabbit.core.config.RepositoryConfig.getFileSystem(RepositoryConfig.java:911)
    at org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:285)
    at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:605)
    at org.apache.jackrabbit.core.TransientRepository$2.getRepository(TransientRepository.java:232)
    at org.apache.jackrabbit.core.TransientRepository.startRepository(TransientRepository.java:280)
    at org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:376)
    at com.mmpnc.icm.server.repository.RepositoryStartupService.newSession(RepositoryStartupService.java:408)
    at com.mmpnc.icm.server.repository.RepositoryStartupService.newSession(RepositoryStartupService.java:355)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
    at java.lang.reflect.Method.invoke(Method.java:611)
    at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
    at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
    at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
    at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
    at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
    at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
    at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
    at com.mmpnc.icm.server.repository.RepositoryStartupService_$$_javassist_1.newSession(RepositoryStartupService_$$_javassist_1.java)
    at com.mmpnc.icm.server.repository.ICMHouseKeepingSessionManager.create(ICMHouseKeepingSessionManager.java:37)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
    at java.lang.reflect.Method.invoke(Method.java:611)
    at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
    at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
    at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
    at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77)
    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
    at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
    at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
    at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
    at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
    at com.mmpnc.icm.server.repository.ICMHouseKeepingSessionManager_$$_javassist_8.create(ICMHouseKeepingSessionManager_$$_javassist_8.java)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
    at java.lang.reflect.Method.invoke(Method.java:611)
    at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
    at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:138)
    at org.jboss.seam.Component.callComponentMethod(Component.java:2171)
    at org.jboss.seam.Component.callCreateMethod(Component.java:2094)
    at org.jboss.seam.Component.newInstance(Component.java:2054)
    at org.jboss.seam.Component.getInstance(Component.java:1948)
    at org.jboss.seam.Component.getInstance(Component.java:1910)
    at org.jboss.seam.Component.getInstance(Component.java:1904)
    at org.jboss.seam.Component.getInstanceInAllNamespaces(Component.java:2271)
    at org.jboss.seam.Component.getValueToInject(Component.java:2223)
    at org.jboss.seam.Component.injectAttributes(Component.java:1663)
    at org.jboss.seam.Component.inject(Component.java:1481)
    at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:61)
    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
    at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
    at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
    at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
    at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
    at com.mmpnc.icm.server.repository.ICMHouseKeepingRepository_$$_javassist_7.create(ICMHouseKeepingRepository_$$_javassist_7.java)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
    at java.lang.reflect.Method.invoke(Method.java:611)
    at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
    at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:138)
    at org.jboss.seam.Component.callComponentMethod(Component.java:2171)
    at org.jboss.seam.Component.callCreateMethod(Component.java:2094)
    at org.jboss.seam.Component.newInstance(Component.java:2054)
    at org.jboss.seam.Component.getInstance(Component.java:1948)
    at org.jboss.seam.Component.getInstance(Component.java:1910)
    at org.jboss.seam.Component.getInstance(Component.java:1904)
    at org.jboss.seam.Component.getInstanceInAllNamespaces(Component.java:2271)
    at org.jboss.seam.Component.getValueToInject(Component.java:2223)
    at org.jboss.seam.Component.injectAttributes(Component.java:1663)
    at org.jboss.seam.Component.inject(Component.java:1481)
    at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:61)
    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
    at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
    at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
    at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
    at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
    at com.mmpnc.icm.server.repository.ICMHouseKeepingManager_$$_javassist_6.create(ICMHouseKeepingManager_$$_javassist_6.java)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
    at java.lang.reflect.Method.invoke(Method.java:611)
    at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
    at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:138)
    at org.jboss.seam.Component.callComponentMethod(Component.java:2171)
    at org.jboss.seam.Component.callCreateMethod(Component.java:2094)
    at org.jboss.seam.Component.newInstance(Component.java:2054)
    at org.jboss.seam.Component.getInstance(Component.java:1948)
    at org.jboss.seam.Component.getInstance(Component.java:1910)
    at org.jboss.seam.Component.getInstance(Component.java:1904)
    at org.jboss.seam.Component.getInstance(Component.java:1899)
    at com.mmpnc.icm.server.concurrent.PerformCloseTask.call(PerformCloseTask.java:136)
    at com.mmpnc.icm.server.concurrent.PerformCloseTask.call(PerformCloseTask.java:1)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314)
    at java.util.concurrent.FutureTask.run(FutureTask.java:149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:897)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:919)
    at java.lang.Thread.run(Thread.java:770)
    Caused by:
    javax.naming.ConfigurationException: A JNDI operation on a "java:" name cannot be completed because the server runtime is not able to associate the operation's thread with any J2EE application component.  This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request.  Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application.  Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names. [Root exception is javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".]
    at com.ibm.ws.naming.java.javaURLContextImpl.throwExceptionIfDefaultJavaNS(javaURLContextImpl.java:522)
    at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:552)
    at com.ibm.ws.naming.java.javaURLContextImpl.lookupExt(javaURLContextImpl.java:481)
    at com.ibm.ws.naming.java.javaURLContextRoot.lookupExt(javaURLContextRoot.java:485)
    at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:370)
    at org.apache.aries.jndi.DelegateContext.lookup(DelegateContext.java:161)
    at javax.naming.InitialContext.lookup(InitialContext.java:436)
    at org.apache.jackrabbit.core.util.db.ConnectionFactory.getJndiDataSource(ConnectionFactory.java:280)
    ... 114 more
    Caused by:
    javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".
    at com.ibm.ws.naming.ipbase.NameSpace.getParentCtxInternal(NameSpace.java:1969)
    at com.ibm.ws.naming.ipbase.NameSpace.retrieveBinding(NameSpace.java:1376)
    at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1219)
    at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:1141)
    at com.ibm.ws.naming.urlbase.UrlContextImpl.lookupExt(UrlContextImpl.java:1436)
    at com.ibm.ws.naming.java.javaURLContextImpl.lookupExt(javaURLContextImpl.java:477)
    ... 119 more

    Okay "damorgan", you seem to have me confused with a newbie. All I'm posting is the info that I got from my Sys Admin on the fix to my problem I encountered when trying to install Oracle 11g (11.2.0.0) on Red Hat Linux Enterprise 5. Since we're mouting onto an NFS, these are the steps he took. I'm not trying to "hide" information or post as little as possible. What other info do you want? I don't know what you are referring to when you mention "Filer, make, model, software version"? Please elaborate. I was just trying to post to others that may have encountered this problem, and I get somewhat attacked by you. I don't assume anyone can read my mind (especially you).

  • JNDI lookup fails - No such domain/application

    Hi,
    I tried to perform a JNDI lookup from a stand alone Java client towards Oracle 9iAS version 9.0.3 and failed with the following error:
    javax.naming.NamingException: Lookup error: javax.naming.AuthenticationException: No such domain/application: mindejb; nested exception is:
         javax.naming.AuthenticationException: No such domain/application: mindejb
         java.lang.Object com.evermind.server.rmi.RMIContext.lookup(java.lang.String)
              RMIContext.java:134
         java.lang.Object javax.naming.InitialContext.lookup(java.lang.String)
              InitialContext.java:345
         void Samplecom.mind.ejb.stubs.AccountComplexStubClient.main(java.lang.String[])
              AccountComplexStubClient.java:21
    Below, are the JNDI settings I am using. The application by the name mindejb was deployed and is accessible using server side JSP or servlets. When I use a stand alone OC4J, the same settings (different port) work fine!
    java.naming.factory.initial=com.evermind.server.rmi.RMIInitialContextFactory
    java.naming.provider.url=ormi://localhost:3101/mindejb
    java.naming.security.principal=admin
    java.naming.security.credentials=admin
    Thanks,
    Avi

    When you are running within an Oracle Application Server managed OC4J environment, then you should use the OPMN protocol loader we have that will insulate you from the specified ORMI port being used by OC4J.
    The OPMN port is fixed so you can always rely on it, whereas the specific ORMI port used by an OC4J instance changes depending on the startup sequence, the number of procs configured, etc.
    Here's a piece from the EJB documentation
    http://download-west.oracle.com/docs/cd/B14099_19/web.1012/b15505/access.htm#i1019709
    Location
    All ports, including the RMI port, are dynamically set by OPMN when each OC4J instance starts. When you specify the following URL in the client JNDI properties, the client-side OC4J retrieves the dynamic ports for the instance, and chooses one from the list for communication.
    java.naming.provider.url= opmn:ormi://<opmn_host>:<opmn_port>:<oc4j_instance>/<application-name>
    The OPMN host name and port number is retrieved from the opmn.xml file. In most cases, OPMN is located on the same machine as the OC4J instance. However, you must specify the host name in case it is located on another machine. The OPMN port number is optional; if excluded, the default is port 6003. The OPMN port is specified in opmn.xml.
    cheers
    -steve-

  • JNDI lookup failed:javax.naming.NameNotFoundException

    Hello:
    I have a application (not web) that publish messages to a specific topic, i want to receive these messages in a Web Service, but when the web service make the call to a class that is the JMS Client it can't find the Connection factory Name that i create in the aplication.
    I want to know what i have to do,
    I work with J2EE1.3.1 and JMS1.0.2 for the application that publish the messages
    and Jwsdp1.1, tomcat 4 and j2sdk 1.4.0 for the web service.
    I create the connection factory with this command:
    j2eeadmin -addJmsFactory jms/DurableTopicB topic -props clientID=IdTopicB
    Then in the class that the web service invoke i trying to join with this:
    try {
    jndiContext =new InitialContext();
    }catch (NamingException e){
    System.err.println("Could not create JNDI API "+
    "context:"+e.toString());
    return;
    *Look up connection factory and topic.If either  
    *does not exist,exit.                            
    try {
    topicConnectionFactory =(TopicConnectionFactory)
    jndiContext.lookup(conFacName);
    }catch (NamingException e){                      
    System.err.println("JNDI API lookup failed:"+
    e.toString());
    return;
    //System.exit(1);
    But i receive a error message in the log of Tomcat:
    JNDI API lookup failed:javax.naming.NameNotFoundException: El nombre DurableTopicB no este asociado a este contexto
    Thanks

    Hello:
    I display the full context of the connection factory in the application that publish the message:
    Full context is :
    Enviroment is : {java.naming.corba.orb=com.sun.enterprise.iiop.POAEJBORB@ec4a87}
    And in the web service when i create the initial context the full context is:
    Full context is : java:
    Enviroment is : {java.naming.factory.initial=org.apache.naming.java.javaURLContextFactory, java.naming.factory.url.pkgs=org.apache.naming}
    How can i see the connection factory in the Web Service, because the connection factory was created in other Application?

  • JNDI lookup failing

    I have a small test program that gets a Context to our server and does a
    lookup for an EJB. The lookup fails with the following client-side
    trace...
    javax.naming.CommunicationException. Root exception is
    java.lang.ClassNotFoundException: class
    com.prismadata.appserv.session.series.TimeseriesSBBeanHomeImpl_ServiceStub
    previously not found
    at weblogic.rjvm.MsgAbbrev.read(MsgAbbrev.java:181)
    at
    weblogic.socket.JVMAbbrevSocket.readMsgAbbrevs(JVMAbbrevSocket.java:505)
    at
    weblogic.rjvm.MsgAbbrevInputStream.prime(MsgAbbrevInputStream.java:134)
    at weblogic.rjvm.RJVMImpl.dispatch(RJVMImpl.java:610)
    at
    weblogic.rjvm.ConnectionManagerClient.handleRJVM(ConnectionManagerClient.java:34)
    at
    weblogic.rjvm.ConnectionManager.dispatch(ConnectionManager.java:630)
    at
    weblogic.socket.JVMAbbrevSocket.dispatch(JVMAbbrevSocket.java:393)
    at weblogic.socket.JVMSocketT3.dispatch(JVMSocketT3.java:342)
    at
    weblogic.socket.JavaSocketMuxer.processSockets(JavaSocketMuxer.java:247)
    at
    weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:23)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
    --------------- nested within: ------------------
    weblogic.rmi.UnmarshalException: Unmarshalling return
    - with nested exception:
    [java.lang.ClassNotFoundException: class
    com.prismadata.appserv.session.series.TimeseriesSBBeanHomeImpl_ServiceStub
    previously not found]
    at
    weblogic.jndi.toolkit.BasicWLContext_WLStub.lookup(BasicWLContext_WLStub.java:256)
    at
    weblogic.jndi.toolkit.WLContextStub.lookup(WLContextStub.java:545)
    at javax.naming.InitialContext.lookup(InitialContext.java:349)
    at
    com.prismadata.appserv.session.series.test.Client.main(Client.java:73)
    However, when I perform the same lookup in a servlet (admittedly running
    in the same JVM) I successfully get the home interface object back.
    Any ideas why ?
    Thanks,
    Gino

    In order to get a reference to you EJB Home interface from JNDI, your
    application has to have an access to the stub of this interface. This stub
    is generated by WL tools when you deploy your EJB. Because your servlet runs
    inside the server's VM, it has an access to this stub by default. So just
    include these stubs in CLASSPATH of your test program and you will see the
    difference.
    kesha
    "Gino Coccia" <[email protected]> wrote in message
    news:[email protected]...
    I have a small test program that gets a Context to our server and does a
    lookup for an EJB. The lookup fails with the following client-side
    trace...
    javax.naming.CommunicationException. Root exception is
    java.lang.ClassNotFoundException: class
    com.prismadata.appserv.session.series.TimeseriesSBBeanHomeImpl_ServiceStub
    previously not found
    at weblogic.rjvm.MsgAbbrev.read(MsgAbbrev.java:181)
    at
    weblogic.socket.JVMAbbrevSocket.readMsgAbbrevs(JVMAbbrevSocket.java:505)
    at
    weblogic.rjvm.MsgAbbrevInputStream.prime(MsgAbbrevInputStream.java:134)
    at weblogic.rjvm.RJVMImpl.dispatch(RJVMImpl.java:610)
    at
    weblogic.rjvm.ConnectionManagerClient.handleRJVM(ConnectionManagerClient.jav
    a:34)
    >
    at
    weblogic.rjvm.ConnectionManager.dispatch(ConnectionManager.java:630)
    at
    weblogic.socket.JVMAbbrevSocket.dispatch(JVMAbbrevSocket.java:393)
    at weblogic.socket.JVMSocketT3.dispatch(JVMSocketT3.java:342)
    at
    weblogic.socket.JavaSocketMuxer.processSockets(JavaSocketMuxer.java:247)
    at
    weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:23)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
    --------------- nested within: ------------------
    weblogic.rmi.UnmarshalException: Unmarshalling return
    - with nested exception:
    [java.lang.ClassNotFoundException: class
    com.prismadata.appserv.session.series.TimeseriesSBBeanHomeImpl_ServiceStub
    previously not found]
    at
    weblogic.jndi.toolkit.BasicWLContext_WLStub.lookup(BasicWLContext_WLStub.jav
    a:256)
    >
    at
    weblogic.jndi.toolkit.WLContextStub.lookup(WLContextStub.java:545)
    at javax.naming.InitialContext.lookup(InitialContext.java:349)
    at
    com.prismadata.appserv.session.series.test.Client.main(Client.java:73)
    However, when I perform the same lookup in a servlet (admittedly running
    in the same JVM) I successfully get the home interface object back.
    Any ideas why ?
    Thanks,
    Gino

  • JNDI lookup fails for client applications

    I am currently porting our j2ee application to weblogic 7.0. The application already
    runs successfully on Orion and Jboss. I have got everything working now except
    for our client applications, which all fail with a JNDI lookup error. The exception
    is:
    javax.naming.NameNotFoundException: Unable to resolve 'java:comp.env/ejb/QualiferInstance'
    Resolved: '' Unresolved:'java:comp' ; remaining name 'java:comp.env
    /ejb/QualifierInstance'
    at weblogic.rmi.internal.BasicOutboundRequest.sendReceive(BasicOutbound
    equest.java:109)
    at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemote
    ef.java:262)
    at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemote
    ef.java:229)
    at weblogic.jndi.internal.ServerNamingNode_WLStub.lookup(Unknown Source
    at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:338)
    at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:333)
    at javax.naming.InitialContext.lookup(InitialContext.java:347)
    at BatchIndexer.main(BatchIndexer.java:89)
    I have looked up numerous postings on various mailing lists describing similar
    problems, but none of them give an explanation which helps me.
    I am convinced that I have the ejb deployment descriptors correct because all
    our JSPs, servlets and session beans successfully lookup and use the EJBs.
    I am also convinced that I have the correct code for the JNDI lookup in our client
    applications, because they work perfectly well on Orion and Jboss and use syntax
    which is described as correct in the jsee specification, i.e. "java:comp/env/..."
    Here is the descriptor from weblogic-ejb-jar.xml for the EJB mentioned in the
    example exception above:
    <weblogic-enterprise-bean>
    <ejb-name>QualifierInstance</ejb-name>
    <jndi-name>comp/env/ejb/QualifierInstance</jndi-name>
    </weblogic-enterprise-bean>
    And here is the descriptor in the application-client.xml file:
         <ejb-ref>
              <ejb-ref-name>ejb/QualifierInstance</ejb-ref-name>
              <ejb-ref-type>Entity</ejb-ref-type>           <home>com.espritsoutron.xengine.ejb.metamodel.QualifierInstanceHome</home>
              <remote>com.espritsoutron.xengine.ejb.metamodel.QualifierInstance</remote>
              <ejb-link>QualifierInstance</ejb-link>
         </ejb-ref>
    And here is the code in the client application that attempts to perform the lookup:
    qiHome = (QualifierInstanceHome)PortableRemoteObject.narrow(context.lookup("java:comp/env/ejb/QualifierInstance"),
    QualifierInstanceHome.class);
    The annoying thing is that I know I can make this work if I change the code to
    omit the "java:" prefix, but I don't want to do this because then it would no
    longer work on either Orion and Jboss.
    P.S. I have also tried changing the jndi-name in the weblogic-ejb-jar descriptor
    to "ejb/QualifierInstance" and just "QualifierInstance", but neither of these
    make any difference. I even tried chaning it to "java:comp/env/ejb/QualifierInstance"
    but that totally breaks the server.
    Can anyone can please help with this?

    you can find the JNDI name in the JNDI tree from the admin console
    right click on your server and choose "view jndi tree".
    if you bind your ejb to ejb/QualifierInstance
    you look it up with that exact same name ejb/QualifierInstance
    Julian Fawcett wrote:
    I am currently porting our j2ee application to weblogic 7.0. The application already
    runs successfully on Orion and Jboss. I have got everything working now except
    for our client applications, which all fail with a JNDI lookup error. The exception
    is:
    javax.naming.NameNotFoundException: Unable to resolve 'java:comp.env/ejb/QualiferInstance'
    Resolved: '' Unresolved:'java:comp' ; remaining name 'java:comp.env
    /ejb/QualifierInstance'
    at weblogic.rmi.internal.BasicOutboundRequest.sendReceive(BasicOutbound
    equest.java:109)
    at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemote
    ef.java:262)
    at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemote
    ef.java:229)
    at weblogic.jndi.internal.ServerNamingNode_WLStub.lookup(Unknown Source
    at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:338)
    at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:333)
    at javax.naming.InitialContext.lookup(InitialContext.java:347)
    at BatchIndexer.main(BatchIndexer.java:89)
    I have looked up numerous postings on various mailing lists describing similar
    problems, but none of them give an explanation which helps me.
    I am convinced that I have the ejb deployment descriptors correct because all
    our JSPs, servlets and session beans successfully lookup and use the EJBs.
    I am also convinced that I have the correct code for the JNDI lookup in our client
    applications, because they work perfectly well on Orion and Jboss and use syntax
    which is described as correct in the jsee specification, i.e. "java:comp/env/..."
    Here is the descriptor from weblogic-ejb-jar.xml for the EJB mentioned in the
    example exception above:
    <weblogic-enterprise-bean>
    <ejb-name>QualifierInstance</ejb-name>
    <jndi-name>comp/env/ejb/QualifierInstance</jndi-name>
    </weblogic-enterprise-bean>
    And here is the descriptor in the application-client.xml file:
         <ejb-ref>
              <ejb-ref-name>ejb/QualifierInstance</ejb-ref-name>
              <ejb-ref-type>Entity</ejb-ref-type>           <home>com.espritsoutron.xengine.ejb.metamodel.QualifierInstanceHome</home>
              <remote>com.espritsoutron.xengine.ejb.metamodel.QualifierInstance</remote>
              <ejb-link>QualifierInstance</ejb-link>
         </ejb-ref>
    And here is the code in the client application that attempts to perform the lookup:
    qiHome = (QualifierInstanceHome)PortableRemoteObject.narrow(context.lookup("java:comp/env/ejb/QualifierInstance"),
    QualifierInstanceHome.class);
    The annoying thing is that I know I can make this work if I change the code to
    omit the "java:" prefix, but I don't want to do this because then it would no
    longer work on either Orion and Jboss.
    P.S. I have also tried changing the jndi-name in the weblogic-ejb-jar descriptor
    to "ejb/QualifierInstance" and just "QualifierInstance", but neither of these
    make any difference. I even tried chaning it to "java:comp/env/ejb/QualifierInstance"
    but that totally breaks the server.
    Can anyone can please help with this?

  • JNDI Lookup failing in specific instances

    Hi All
    We have an application deployed to OC4J 9.0.4.1 - the application consists of a collection of local/remote session beans and nearly 100 entity beans.
    We are calling a local session bean and local entity bean from a remote SB. Now in most cases our JNDI lookups work fine, however some specific ones do not.
    The following are our JNDI specific properties :
    "jndiproviderclass"
    com.evermind.server.rmi.RMIInitialContextFactory</property"url"
    ormi://HOSTNAME:23792/Twe
    "security_principal"
    admin
    "security_credentials"
    welcome
    If anyone has any ideas why some specific deployments would not work, I can provide more details.
    Thanks

    Hi Jon,
    I got it working a couple of days ago. First I tried manually but could not get it working, then I found this description of how to do it using the Enterprise Manager and then it worked. Check: http://download-uk.oracle.com/docs/cd/B31017_01/integrate.1013/b28994/adptr_db.htm#BDCFIEDJ
    I defined a connection pool, a datasource and connection factory. In 6 step you should use a DbAdapter instead of an AppsAdapter, and don't put anything in dataSourceName. I choose No Connection Pool for the connection factory.
    Regards Pete

  • Data source JNDI lookup fails in Weblogic 12.1.2

    What  is changed in the Weblogic 12.1.2 JNDI handling?
    My EJB 2.1 application has been working fine with Weblogic versions up to 12.1.1, but with version 12.1.2 it is giving the following error at startup:
    weblogic.application.ModuleException: javax.naming.NameNotFoundException: remaining name: comp/env/jdbc/DataSourceAlias
    where jdbc/DatasourceAlias is the res-ref-name of the actual datasource named jdbc/APP_DATASOURCE which is set through the admin console.
    The discovery of the datasource is performed by this piece of code :
    ds = initialContext.lookup ("java:comp/env/" + refName)
    This is what is failing with Weblogic 12. After some research I found out that in order for the datasource lookup to succeed, I have to :
    1) ignore the subcontext "comp/env" and
    2) use the actual JNDI name "jdbc/APP_DATASOURCE" instead of the reference "jdbc/DataSourceAlias"
    However for the EJBs, nothing is changed, they are found in the comp/env subcontext.
    Hope this helps someone, or let someone tell me how the migration to Weblogic 12.1.2 is supposed to be done.

    Hi,
    If it is war then try to apply following  Patch 13893259.
    Regards,
    Kal

  • JNDI lookup fails ...IMMEDIATE HELP REQUIRED !!!

    Hi
    I am new to using the WLS,currenty I am using Weblogic6.1(sp).I developed a statelessSession
    Bean and have successfully deployed it to the server.Counterfit I wrote a Client
    class to check weather my beans are working properly.My client class to be in
    breif inserts some values into the database.
    When I am trying to execute my client code it gives me out the following error
    - with nested exception:
    [javax.naming.NameNotFoundException: Unable to resolve SQLConnectionPool. Resolved:
    '' Unresolved:'SQLConn
    ectionPool' ; remaining name '']
    at com.wellmanage.Bean.MessageLoggerBean.getConnection(MessageLoggerBean.java:186)
    at com.wellmanage.Bean.MessageLoggerBean.logMessage(MessageLoggerBean.java:77)
    at com.wellmanage.Bean.MessageLoggerBean_3p5ifg_EOImpl.logMessage(MessageLoggerBean_3p5ifg_EOImpl.
    java:79)
    at com.wellmanage.Bean.MessageLoggerBean_3p5ifg_EOImpl_WLSkel.invoke(Unknown
    Source)
    at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:296)
    at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java:93)
    at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:265)
    at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:22)
    at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
    End server side stack trace
    SQLConnectionPool is the JNDI name i mentioned in the weblogic console.In the
    same fashion I also mentioned the jndilookup in my bean class with the same name
    (SQLConnectionPool)as follows
    public Connection getConnection() throws SQLException
    try
    InitialContext jndiCntx = new InitialContext();
    // DataSource ds = (DataSource)jndiCntx.lookup("java:comp/env/jdbc/SQLConnectionPool");
    DataSource ds = (DataSource)jndiCntx.lookup("SQLConnectionPool");
    return ds.getConnection();
    catch(NamingException ne)
    throw new EJBException(ne);
    SO FINALLY IT GIVES ME OUT THE ABOVE FIRST MENTIONED ERROR.i ALSO TRIED USING
    THE jnidlookup mentioned in the comments ie.."DataSource ds = (DataSource)jndiCntx.lookup("java:comp/env/jdbc/SQLConnectionPool");
    " then also it throws an error.
    CAN ANYBODY HELP ME IT A MATTER OF URGENCY...
    Thanks
    Srini

    can u post ur config.xml
    Srini wrote:
    Hi
    I am new to using the WLS,currenty I am using Weblogic6.1(sp).I developed a statelessSession
    Bean and have successfully deployed it to the server.Counterfit I wrote a Client
    class to check weather my beans are working properly.My client class to be in
    breif inserts some values into the database.
    When I am trying to execute my client code it gives me out the following error
    - with nested exception:
    [javax.naming.NameNotFoundException: Unable to resolve SQLConnectionPool. Resolved:
    '' Unresolved:'SQLConn
    ectionPool' ; remaining name '']
    at com.wellmanage.Bean.MessageLoggerBean.getConnection(MessageLoggerBean.java:186)
    at com.wellmanage.Bean.MessageLoggerBean.logMessage(MessageLoggerBean.java:77)
    at com.wellmanage.Bean.MessageLoggerBean_3p5ifg_EOImpl.logMessage(MessageLoggerBean_3p5ifg_EOImpl.
    java:79)
    at com.wellmanage.Bean.MessageLoggerBean_3p5ifg_EOImpl_WLSkel.invoke(Unknown
    Source)
    at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:296)
    at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java:93)
    at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:265)
    at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:22)
    at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
    End server side stack trace
    SQLConnectionPool is the JNDI name i mentioned in the weblogic console.In the
    same fashion I also mentioned the jndilookup in my bean class with the same name
    (SQLConnectionPool)as follows
    public Connection getConnection() throws SQLException
    try
    InitialContext jndiCntx = new InitialContext();
    // DataSource ds = (DataSource)jndiCntx.lookup("java:comp/env/jdbc/SQLConnectionPool");
    DataSource ds = (DataSource)jndiCntx.lookup("SQLConnectionPool");
    return ds.getConnection();
    catch(NamingException ne)
    throw new EJBException(ne);
    SO FINALLY IT GIVES ME OUT THE ABOVE FIRST MENTIONED ERROR.i ALSO TRIED USING
    THE jnidlookup mentioned in the comments ie.."DataSource ds = (DataSource)jndiCntx.lookup("java:comp/env/jdbc/SQLConnectionPool");
    " then also it throws an error.
    CAN ANYBODY HELP ME IT A MATTER OF URGENCY...
    Thanks
    Srini

  • RMI tunneling: JNDI lookup fails with : Disconnected: Type code out of range, is -29

    9iAS Release 2
    When trying to tunnel through Apache to the OC4J_home instance using ...
    http:ormi://<host>:<HTTPport>/<application> <admin><password>
    and then looking up a JNDI name ...
    TopicConnectionFactory connectionFactory =
    (TopicConnectionFactory)new InitialContext(p).lookup("jms/myTopicConnectionFactory");
    I get a NamingException thrown, with the message: Disconnected: Type code out of range, is -29.
    The jms.xml file is correct. It works against a standalone OC4J instance (therefore no tunneling) ...
    ormi://<host>:23791/<application> <admin><password>
    I'm connecting from a standalone client and using the RMIInitialContextFactory, the tunneling is working (changing oc4j username/password gets a SecurityException). What's missing? Do you have to change the jndi name when tunneling? What does -29 mean in english?

    Tunneling through the Apache HTTP server to an OC4J instance from remote standalone clients works on Linux installations of 9iAS but not on NT installations, failing with a 'Type Code out of range, is -29' error, JVM versions on client and server are the same. Also works against a standalone version of oc4j on NT, what's happening?

  • Jndi lookup fails on Sun app server 8

    My standalone client on java is able to lookup TopicConnectionFactory on localhost on Sun Server 7 perfectly, but fails on Sun Server 8. I've set up the resources correctly as described in the J2EE 1.4 tutorial, but I get the following error:
    SEVERE: NAM5003: CommunicationException in SerialContext lookup()
    java.lang.NullPointerException
         at com.sun.enterprise.naming.factory.ConnectorObjectFactory.getObjectInstance(ConnectorObjectFactory.java:64)
         at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:301)
         at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:148)
         at javax.naming.InitialContext.lookup(InitialContext.java:347)
    javax.naming.CommunicationException:
         at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:174)
         at javax.naming.InitialContext.lookup(InitialContext.java:347)What could be wrong??

    It turned out to be a JMS library version issue. I had files for Server 8.0, but was running 8.1. Who knew it would be that big a deal.
    Now that I have the right version, I'm able to look up topics and queues, but cannot lookup TopicConnectionFactory. The client does not return at connectionFactory = (TopicConnectionFactory)initial.lookup("jms/FieldTopicConnectionFactory"); and no error in server.log.
    Here's the rest of the code:
    try {
             Context initial = new InitialContext();
               connectionFactory = (TopicConnectionFactory)initial.lookup("jms/FieldTopicConnectionFactory"); //does not return
             dest = (Topic) initial.lookup("jms/FieldTopic"); //this works!!
    } catch{...}I run my standalone through these JVM args:
    -Dorg.omg.CORBA.ORBInitialPort=3700 -Dorg.omg.CORBA.ORBInitialHost=myserver.com

  • JNDI lookup problem in WAS 5.1

    Hello all,
    I have generated an EAR using XDoclet and MyEclipse. When I deploy this EAR on WAS 5.1, I get the following exception:
    javax.naming.NameNotFoundException: Context: WarHog/nodes/WarHog/servers/server1, name: ejb/TEDIObjectManagerLocal: First component in name TEDIObjectManagerLocal 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(NotFoundHelper.java:85)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java(Compiled Code))
         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java(Compiled Code))
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code))
         at java.lang.reflect.Method.invoke(Method.java(Compiled Code))
         at com.ibm.rmi.iiop.CDRInputStream.readBoxedIDLEntity(CDRInputStream.java:2112)
         at com.ibm.rmi.iiop.CDRInputStream.readIDLValue(CDRInputStream.java:2177)
         at com.ibm.rmi.iiop.CDRInputStream.fast_read_value(CDRInputStream.java:1734)
         at com.ibm.rmi.io.IIOPInputStream.readValueType(IIOPInputStream.java:2085)
         at com.ibm.rmi.io.IIOPInputStream.readObjectField(IIOPInputStream.java:2057)
         at com.ibm.rmi.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:1765)
         at com.ibm.rmi.io.IIOPInputStream.inputObjectUsingClassDesc(IIOPInputStream.java:1348)
         at com.ibm.rmi.io.IIOPInputStream.continueSimpleReadObject(IIOPInputStream.java:420)
         at com.ibm.rmi.io.IIOPInputStream.simpleReadObjectLoop(IIOPInputStream.java:404)
         at com.ibm.rmi.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:347)
         at com.ibm.rmi.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:200)
         at com.ibm.rmi.iiop.CDRInputStream.read_value(CDRInputStream.java:1367)
         at com.ibm.rmi.util.ProxyUtil.copyObject(ProxyUtil.java:450)
         at com.ibm.CORBA.iiop.UtilDelegateImpl.copyObject(UtilDelegateImpl.java:789)
         at javax.rmi.CORBA.Util.copyObject(Util.java:333)
         at com.wdc.tedi.interfaces._TransformationEngine_Stub.transform(_TransformationEngine_Stub.java:268)
         at com.wdc.tedi.web.TestHarnessBean.translate(TestHarnessBean.java:42)
         at com.wdc.tedi.web.TestHarnessBean.setDataBlob(TestHarnessBean.java:80)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)First of all, I don't really understand what the error means. Is it that the JNDI lookup failed when one of my beans tried to do a lookup on 'ejb/TEDIObjectManagerLocal'? I believe there's some configuration that went wrong (EJB reference binding or something) when I deployed the EAR. The reason I don't think it's a faulty code is because the EAR runs like a charm when I deploy it on Oracle 10g and Weblogic.
    I am really stuck on this problem and shall appreciate any help that I can get. I can send the code, xdoclet tags and configuration if that might assist someone.
    Thanks
    -ybh6336

    Hello all,
    I'm still stuck on this issue. Following are the entries related to my
    application when I do a 'dumpNameSpace':
       28 (top)/nodes/WarHog/servers/server1/ejb/tedi/TEDIObjectManager
       28
    com.wdc.tedi.interfaces._TEDIObjectManagerHome_Stub
       29 (top)/nodes/WarHog/servers/server1/ejb/tedi/DSValueLookup
       29
    com.wdc.tedi.interfaces._DSValueLookupHome_Stub
       30 (top)/nodes/WarHog/servers/server1/ejb/tedi/TransformationEngine
       30
    com.wdc.tedi.interfaces._TransformationEngineHome_StubObservations:
    - I only see the namespace entries for my Session beans. There's one
    entity bean also which does not show up.
    - I don't see anything for the Local Home interfaces, it shows only the
    Home interfaces.
    As additional information, I'm looking up 'TEDIObjectManagerLocal'
    using 'ejb/TEDIObjectManagerLocal'. I also tried using 'local:ejb/ejb/TEDIObjectManagerLocal' (as Karthyk suggested) and
    'java:comp/env/ejb/TEDIObjectManagerLocal', but that does not work
    either.
    Also, the XDoclet tags that I use to generate the interfaces for
    TEDIObjectManager bean are as follows:
    /* @ejb.bean name="TEDIObjectManager"
    *           display-name="TEDIObjectManager"
    *           description="TEDIObjectManager"
    *           jndi-name="ejb/tedi/TEDIObjectManager"
    *           local-jndi-name="ejb/TEDIObjectManagerLocal"
    *           type="Stateless"
    *           view-type="both"
    * @ejb.util generate="physical"
    * @ejb.ejb-ref ejb-name="TEDIObject"
    * view-type = "local"
    * ref-name = "ejb/TEDIObjectLocal"
    * @oc4j.bean jndi-name="ejb/tedi/TEDIObjectManager"
    */My ejb-jar.xml looks like following for that bean:
    <session >
             <description><![CDATA[TEDIObjectManager]]></description>
             <display-name>TEDIObjectManager</display-name>
             <ejb-name>TEDIObjectManager</ejb-name>
             <home>com.wdc.tedi.interfaces.TEDIObjectManagerHome</home>
             <remote>com.wdc.tedi.interfaces.TEDIObjectManager</remote>
    <local-home>com.wdc.tedi.interfaces.TEDIObjectManagerLocalHome</local-home>
             <local>com.wdc.tedi.interfaces.TEDIObjectManagerLocal</local>
    <ejb-class>com.wdc.tedi.ejb.TEDIObjectManagerSession</ejb-class>
             <session-type>Stateless</session-type>
             <transaction-type>Container</transaction-type>
             <ejb-local-ref >
                <ejb-ref-name>ejb/TEDIObjectLocal</ejb-ref-name>
                <ejb-ref-type>Entity</ejb-ref-type>
    <local-home>com.wdc.tedi.interfaces.TEDIObjectLocalHome</local-home>
                <local>com.wdc.tedi.interfaces.TEDIObjectLocal</local>
                <ejb-link>TEDIObject</ejb-link>
             </ejb-local-ref>
          </session>AND following for the bean that is referencing it:
    <session >
             <description><![CDATA[TransformationEngine]]></description>
             <display-name>TransformationEngine</display-name>
             <ejb-name>TransformationEngine</ejb-name>
             <home>com.wdc.tedi.interfaces.TransformationEngineHome</home>
             <remote>com.wdc.tedi.interfaces.TransformationEngine</remote>
    <local-home>com.wdc.tedi.interfaces.TransformationEngineLocalHome</local-home>
    <local>com.wdc.tedi.interfaces.TransformationEngineLocal</local>
    <ejb-class>com.wdc.tedi.ejb.TransformationEngineSession</ejb-class>
             <session-type>Stateless</session-type>
             <transaction-type>Container</transaction-type>
             <ejb-local-ref >
                <ejb-ref-name>ejb/TEDIObjectManagerLocal</ejb-ref-name>
                <ejb-ref-type>Session</ejb-ref-type>
    <local-home>com.wdc.tedi.interfaces.TEDIObjectManagerLocalHome</local-home>
    <local>com.wdc.tedi.interfaces.TEDIObjectManagerLocal</local>
                <ejb-link>TEDIObjectManager</ejb-link>
             </ejb-local-ref>
          </session>The entries in ibm-ejb-jar-bnd.xmi (generated using MyEclipse) are as
    follows for the two beans:
    <ejbBindings
             xmi:id="Session_bnd_1"
             jndiName="ejb/tedi/TransformationEngine">
             <ejbRefBindings xmi:id="EJBRefBnd_1"
    jndiName="ejb/TEDIObjectManagerLocal">
        <bindingEjbRef href="META-INF/ejb-jar.xml#EJBLocalRef_1"/>
             </ejbRefBindings>
             <enterpriseBean
                xmi:type="ejb:Session"
    href="META-INF/ejb-jar.xml#Session_TransformationEngine" />
          </ejbBindings>
    <ejbBindings
             xmi:id="Session_bnd_3"
             jndiName="ejb/tedi/TEDIObjectManager">
             <ejbRefBindings xmi:id="EJBRefBnd_2"
    jndiName="ejb/TEDIObjectLocal">
        <bindingEjbRef href="META-INF/ejb-jar.xml#EJBLocalRef_2"/>
             </ejbRefBindings>
             <enterpriseBean
                xmi:type="ejb:Session"
    href="META-INF/ejb-jar.xml#Session_TEDIObjectManager" />
          </ejbBindings>I know I'm swamping the post with code, but please let me know if anyone finds something unusual.
    NOTE: When deploying on WAS, in the 'Map EJB references to beans' step, I'm giving the following values for 'TransformationEngine' bean:
    Reference binding: ejb/TEDIObjectManagerLocal
    JNDI Name: ejb/tedi/TEDIObjectManager
    There's one other similar binding that works for 'TEDIObjectManager'
    bean:
    Reference binding: ejb/TEDIObjectLocal
    JNDI Name: ejb/TEDIObject
    Everything in ejb-jar and ibm-ejb-jar-bnd.xmi look similar for this working bean, there is one difference though, I do the lookup on this one using 'java:comp/env/ejb/TEDIObjectLocal', but I've already tried that for the other one.
    Really appreciate your time.
    Thanks
    -yogesh

  • 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

  • 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

  • JAVA client JNDI lookup for EJB session in cluster in WLS 5.1

    The documentation says :
              to obtain a Context for JNDI lookup do the following :
              Hashtable ht = new Hashtable();
              ht.put(Context.INITIAL_CONTEXT_FACTORY,
              "weblogic.jndi.WLInitialContextFactory");
              ht.put(Context.PROVIDER_URL, "t3://mycluster:7001");
              try {
              Context ctx = new InitialContext(ht);
              // Do the client's work
              catch (NamingException ne) {
              // A failure occurred
              finally {
              try {ctx.close();}
              catch (Exception e) {
              // a failure occurred
              where "mycluster" is the DNS name of my cluster. My DNS server (Windows 200
              DNS server) use round robin
              to call alernatively all the wls server node in "mycluster" and it's OK. The
              two servers of my cluster
              are called alternatively for my EJB session stateless.
              Now I unplug one of the two nodes of my cluster and the remaining server is
              called only 2 times
              and not after.
              Questions :
              -is the load balancing between the nodes of mycluster only rely on DNS or
              is there an internal
              mecanism in EJB sub to try one server then an other ?
              - do I need to obtain a new reference on JNDI Context for each call ?
              Thank's a lot.
              Farid Bellameche.
              

              I too have the same problem. My scenario is :
              I have the web tier architecture away from cluster. All ejbs are in cluster
              running in two seperate machines. We have a factory class running in
              webtier(we use servlet in this tier) which obtains home interface only once
              and stores it for future reference. When ever we need the remoteobject stub,
              we ask the factory class and which in turn uses the stored home interface to
              get the same.
              In the webtier, I list all the servers in the cluster as a part of url as
              mentioned by you.
              I started the web tier as well as Object tier cluster. I could see the
              request coming in both the machines in the cluster for the ejb. But When I
              bring one the server in the cluster,
              1. Web tier throws an exception saying that it could not connect
              to server using t3.
              2. The other machine which is running the server, also says
              'failed to create socket to : -32323234324 sever name
              using protocol t3.
              It looks like I am able to get load balance. But I am not able to get the
              fail over to be working.
              In the weblogic-ejb-jar.xml, I added the following.
              <clustering-descriptor>
              <home-is-clusterable>true</home-is-clusterable>
              <home-load-algorithm>round-robin</home-load-algorithm>
              </clustering-descriptor>
              I compiled and added the .jar file. So the jar file now has replica aware
              stubs.
              Could any one of you help me for why the fail over is not working?
              Suersh
              "Giri Alwar" <[email protected]> wrote in message
              news:[email protected]...
              > Farid,
              > (1) Yes, the stub has the logic to perform load-balancing and
              fail-over.
              > (2) In almost all cases, no. You can get the context once, store it
              and
              > use it thereafter. Please refer to
              > http://www.weblogic.com/docs51/cluster/concepts.html#1025061 for more
              info.
              >
              > A couple of notes on your situation. From what you are describing, your
              > Windows DNS server is setup to serve only one IP from the cluster (using
              > round-robin) as opposed to a list of all IP's in the cluster. Hence, the
              > initial context you obtain is tied to a single server in the cluster (the
              > one returned by the DNS). The weblogic implementation on the client side
              has
              > no idea of the existence of the other servers in the cluster. This is not
              a
              > cluster aware context. To obtain a cluster aware context, either list all
              > the IP's in the URL like t3://server1,server2,server3:7001 or have
              > "mycluster" return a list of all servers in the cluster.
              >
              > Giri
              >
              >
              > "Farid Bellameche" <[email protected]> wrote in message
              > news:[email protected]...
              > > The documentation says :
              > >
              > > to obtain a Context for JNDI lookup do the following :
              > > Hashtable ht = new Hashtable();
              > > ht.put(Context.INITIAL_CONTEXT_FACTORY,
              > > "weblogic.jndi.WLInitialContextFactory");
              > > ht.put(Context.PROVIDER_URL, "t3://mycluster:7001");
              > > try {
              > > Context ctx = new InitialContext(ht);
              > > // Do the client's work
              > > }
              > > catch (NamingException ne) {
              > > // A failure occurred
              > > }
              > > finally {
              > > try {ctx.close();}
              > > catch (Exception e) {
              > > // a failure occurred
              > > }
              > > }
              > >
              > > where "mycluster" is the DNS name of my cluster. My DNS server (Windows
              > 200
              > > DNS server) use round robin
              > > to call alernatively all the wls server node in "mycluster" and it's OK.
              > The
              > > two servers of my cluster
              > > are called alternatively for my EJB session stateless.
              > > Now I unplug one of the two nodes of my cluster and the remaining server
              > is
              > > called only 2 times
              > > and not after.
              > >
              > > Questions :
              > > -is the load balancing between the nodes of mycluster only rely on DNS
              > or
              > > is there an internal
              > > mecanism in EJB sub to try one server then an other ?
              > >
              > > - do I need to obtain a new reference on JNDI Context for each call ?
              > >
              > >
              > > Thank's a lot.
              > >
              > > Farid Bellameche.
              > >
              > >
              > >
              > >
              >
              >
              

Maybe you are looking for

  • Need to Skip the fields duaring the data upload by SQL*Loader.

    Hi all, I am not able to get how to skip some fileds in the file while uploading it thru SQL*Loader. Let us have a look the below scenario. The table has 4 columns. but in the input file came up with 6 fields. Let us assume the four fields came as fi

  • 11g BPM Composer on Solaris soooo slow

    Hi guys, We really want to use BPM Process Composer, so we installed SOA Suite 11.1.1.3 on a Solaris machine (Sun SPARC Enterprise T5440) with plenty of memory and cpu available. However it takes over 5 minutes just to login. We found by doing thread

  • Memory used by SQL Developer

    Hello I was running a query with output of around 9 lakh records. I did this with Toad earlier and now I tried with SQL Developer. I found a difference like this. When in toad the records were being fetched the memory used by Toad was not getting inc

  • Need javascript to automate hiding a layer (INDD CS4)

    Hi, We've been having a problem lately with our writers remembering to kill the DRAFT watermark layer before they export the print and web pdfs. I need a script that will automatically hide the "watermark" layer in the current document, save the docu

  • Problem in CACSDESIGN Transaction

    As we try to create an design for application by CACSDESIGN transaction, an error message appears: Table / structure XXXXXX_A_TGT_INQ_PORTAL is not registered as a generation template.