JNDI lookup of DataSource fails

I'm trying to create a DataSource as follows:
Connection connection = null;
String ACCOUNT_DATASOURCE = "weblogic.jdbc.AccountDB";
try {
Context ctx = new InitialContext(System.getProperties());
DataSource ds = (DataSource)ctx.lookup(ACCOUNT_DATASOURCE);
connection = ds.getConnection();
catch (Exception e) {
The client window reveals:
javax.ejb.CreateException: java.lang.NullPointerException
at weblogic.rmi.internal.BasicOutboundRequest.sendReceive(BasicOutboundR
equest.java:85)
at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteR
ef.java:274)
at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteR
ef.java:243)
at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:90)
at $Proxy1.create(Unknown Source)
at helloWorld.Client.main(Client.java:22)
Destroying account..
The server window reveals:
javax.naming.NameNotFoundException: Unable to resolve weblogic.jdbc.AccountDB.
R
esolved: 'weblogic.jdbc' Unresolved:'AccountDB' ; remaining name ''
<<no stack trace available>>
Via the console GUI I created a connection pool, which frequently disappears -
I do not understand at all why this pool seems so transient but it doesn't sound
good, and a data source, which does seem to persist, whose JNDI name corresponds
exactly to the name used for the lookup above. I've seen some usage of the form
java:comp/env/jdbc/... is this simply an arbitrary and therefore optional prefix,
or does it have some arcance meaning of which I am unaware?
Finally, the weblogic-ejb-jar.xml file defines the BMP entity bean and its associated
JNDI name for the database connection.
I've also created the cloudscape database via a .ddl file and copied it across
to the ~/wlserver6.1_beta/samples/eval/cloudscape/data directory (this might not
be the correct place)
Any ideas or suggestions most welcome - I've currently come to a grinding halt
with this.

Did you make sure the DataSource (and the underlying connection pool were
actually "deployed" to a target server after you created them? That bit me
for a while...
If you open up the console and open up the "Servers" folder on the left and
right click on your server (myserver) and select "View JNDI Tree", do you
see your DataSource under the jdbc node?
greg
"David Franklin" <[email protected]> wrote in message
news:[email protected]...
>
I'm trying to create a DataSource as follows:
Connection connection = null;
String ACCOUNT_DATASOURCE = "weblogic.jdbc.AccountDB";
try {
Context ctx = new InitialContext(System.getProperties());
DataSource ds = (DataSource)ctx.lookup(ACCOUNT_DATASOURCE);
connection = ds.getConnection();
catch (Exception e) {
The client window reveals:
javax.ejb.CreateException: java.lang.NullPointerException
atweblogic.rmi.internal.BasicOutboundRequest.sendReceive(BasicOutboundR
equest.java:85)
atweblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteR
ef.java:274)
atweblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteR
ef.java:243)
at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:90)
at $Proxy1.create(Unknown Source)
at helloWorld.Client.main(Client.java:22)
Destroying account..
The server window reveals:
javax.naming.NameNotFoundException: Unable to resolveweblogic.jdbc.AccountDB.
R
esolved: 'weblogic.jdbc' Unresolved:'AccountDB' ; remaining name ''
<<no stack trace available>>
Via the console GUI I created a connection pool, which frequentlydisappears -
I do not understand at all why this pool seems so transient but it doesn'tsound
good, and a data source, which does seem to persist, whose JNDI namecorresponds
exactly to the name used for the lookup above. I've seen some usage ofthe form
java:comp/env/jdbc/... is this simply an arbitrary and therefore optionalprefix,
or does it have some arcance meaning of which I am unaware?
Finally, the weblogic-ejb-jar.xml file defines the BMP entity bean and itsassociated
JNDI name for the database connection.
I've also created the cloudscape database via a .ddl file and copied itacross
to the ~/wlserver6.1_beta/samples/eval/cloudscape/data directory (thismight not
be the correct place)
Any ideas or suggestions most welcome - I've currently come to a grindinghalt
with this.

Similar Messages

  • Caching of JNDI lookup'ed DataSources???

    What is the recommened pratice, using bean-managed Entity Beans, in regards to
    looking up the DataSource object from the JNDI tree?
    Is the best way to store the DataSource object in the session context when setEntityContext
    is called and release it on unsetEntityContext?
    or
    is it best if we lookup the DataSource object in every method and returns it back
    to the pool at the end of the same method? Like in the PETStore example from SUN.
    In a article from SUN "Seven Rules for Optimizing Entity Beans" they recommend
    to cache even DataSource objects. What is BEA's recommendation on this?
    http://developer.java.sun.com/developer/technicalArticles/ebeans/sevenrules
    Regards,
    Steen
    http://developer.java.sun.com/developer/technicalArticles/ebeans/sevenrules/

    I recommend doing the JNDI look-up in the setEntityContext method and
    storing the DataSource in a member variable.
    You should get the JDBC connection from the DataSource in each method
    and return it in each method.
    -- Rob
    Steen Laursen wrote:
    >
    What is the recommened pratice, using bean-managed Entity Beans, in regards to
    looking up the DataSource object from the JNDI tree?
    Is the best way to store the DataSource object in the session context when setEntityContext
    is called and release it on unsetEntityContext?
    or
    is it best if we lookup the DataSource object in every method and returns it back
    to the pool at the end of the same method? Like in the PETStore example from SUN.
    In a article from SUN "Seven Rules for Optimizing Entity Beans" they recommend
    to cache even DataSource objects. What is BEA's recommendation on this?
    http://developer.java.sun.com/developer/technicalArticles/ebeans/sevenrules
    Regards,
    Steen
    http://developer.java.sun.com/developer/technicalArticles/ebeans/sevenrules/
    AVAILABLE NOW!: Building J2EE Applications & BEA WebLogic Server
    by Michael Girdley, Rob Woollen, and Sandra Emerson
    http://learnWebLogic.com

  • 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

  • Distributed Queue/JMX - JNDI lookup on startup fails

    Hi,
    I have a problem starting up Camel routes on a cluster via JMX. Although I have a NotificationListener registered that tries to startup the routes when the server sends a STATE=RUNNING lifecycle event, I cannot start the all Camel routes due to a "JMSException, Destination not found".
    But, when I remote debug the application and put a breakpoint in, wait let's say 5 secs, then the JNDI lookup works and everything is fine.
    I have unsuccessfully tried to play with the deployment order or my ear (by default the JMSServer is started with a priority of 1000), no luck. I have also put a poll method in, that waits until the JMSServer and the Destinations (=queues) are available, again no luck.
    Anyone able to assist with that issue?
    Best Regards,
    Sebastian

    I found the reason for the late binding. We are using "migratable target" in our cluster. When I remove the migratable target I have no issue whatsoever. Is there a way to either tweak the config or configure the Migratable targets in a way to by-pass this issue?
    Regards,
    Seb

  • JNDI Lookup of ConnectionFactory fails from inside Glassfish application

    This may very well end up being a glassfish specific question.
    I've got a stand-alone WAR using JSF, where I have a backing bean use some helper objects that will send a JMS message. When this WAR is running from inside of Glassfish, it fails to do the lookup of the ConnectionFactory.
    The application pulls the Queue JNDI and the Provider URL from a database, and uses a env Hashtable to do the JNDI InitialContext (which succeeds.) Using this Context, the ConnectionFactory lookup fails.
    The remote server in this instance is WebLogic 9.2 (the JNDI is publically available with no user authentication, verified with a JMS developer tool we use internally.)
    Here's the stacktrace...
    2007-10-15 19:48:04,514 ERROR [net.acadiasoft.shared.jms.util.JMSSenderHelper:130] NamingException: messageFactory not found
    javax.naming.NameNotFoundException: messageFactory not found
    at com.sun.enterprise.naming.TransientContext.doLookup(TransientContext.java:216)
    at com.sun.enterprise.naming.TransientContext.lookup(TransientContext.java:188)
    at com.sun.enterprise.naming.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:74)
    at com.sun.enterprise.naming.LocalSerialContextProviderImpl.lookup(LocalSerialContextProviderImpl.java:111)
    at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:339)
    at javax.naming.InitialContext.lookup(InitialContext.java:351)
    at net.acadiasoft.shared.jms.util.JMSSenderHelper.getConnectionFactory(JMSSenderHelper.java:128)
    at net.acadiasoft.shared.jms.util.JMSSenderHelper.init(JMSSenderHelper.java:58)
    at net.acadiasoft.shared.jms.util.JMSSenderHelper.<init>(JMSSenderHelper.java:36)
    at net.acadiasoft.web.shared.jms.util.AdminJmsHelper.<init>(AdminJmsHelper.java:19)
    at net.acadiasoft.web.server.pages.SchedulerBackingBean.deleteJobs(SchedulerBackingBean.java:75)

    I've found the problem, and it's something I simply overlooked. I don't know why I didnt realize, but i was setting the java.naming.factory.initial env variable to what Glassfish uses, not WebLogic.

  • JNDI Lookup of EJB fails

    Hello,
    I have installed JDeveloper 9.0.3 on windows. I created a workspace and sample project for testing. Added a CMP EJB (Dept) using JDevs "create EJB from table option", added a client to test the EJB using JDevs 'New Sample Client" option, compiled the project and ran the sample client. I get the following error in the embedded OC4J
    javax.naming.NameNotFoundException: Dept not found
         java.lang.Object com.evermind.server.rmi.RMIContext.lookup(java.lang.String)
    I have not changed any bit of configuration and code generated by JDev.
    I tried this because I was getting the same error in a working project imported from other machine.
    Any solution?
    Thanks in advance.
    NAG

    First you need to run the EJB and then run the client.
    Here is something to guide you:
    http://otn.oracle.com/products/jdev/htdocs/handson/j2ee/j2ee13hos.html#lab2
    By the way, why are you using such an old version of JDeveloper? Isn't it time to upgrade to 9.0.5 or at least 9.0.4?

  • Format of the JNDI name for lookup in DataSource

    Hi
    a) I have made a datasource in Weblogic 10.3 called SQL and its JNDI name as jdbc/SQLDS.
    The driver was BEA'S Type 4 Driver for MS SQL Server
    Now I am trying to lookup the datasource through an application. I have used the following
    lines of code:
    InitialContext context = new InitialContext();
    DataSource ds = context.lookup("jdbc/SQLDS");
    Connection conn = ds.getConnection();
    The Application was a success.
    I saw in some articles that you can refer to the datasource by even java:comp/env/jdbc/SQLDS,
    instead of just jdbc/SQLDS. I tried both ways and I was able to run the application.
    b) Then I made another datasource in Weblogic 10.3 called SQL1 and its JNDI name as jdbc/SQL1.
    The driver was MS SQL Server Type 4 Driver for versions 2000, 2005
    Now I am trying to lookup the datasource through an application. I have used the following
    lines of code:
    InitialContext context = new InitialContext();
    DataSource ds = context.lookup("jdbc/SQL1");
    Connection conn = ds.getConnection();
    The Application was a success.
    I saw in some articles that you can refer to the datasource by even java:comp/env/jdbc/SQL1,
    instead of just jdbc/SQL1. I tried the first way and it didnt work. It gave me a NullPointerException
    at the line Connection conn = ds.getConnection();
    c)Then I made a 3rd datasource in Weblogic 10.3 called SQL2 and its JNDI name as jdbc/SQL2DS.
    The driver was MS SQL Server Type 4 Driver for versions 2000, 2005
    Now I am trying to lookup the datasource through an application. I have used the following
    lines of code:
    InitialContext context = new InitialContext();
    DataSource ds = context.lookup("jdbc/SQL2DS");
    Connection conn = ds.getConnection();
    The Application was a success.
    I saw in some articles that you can refer to the datasource by even java:comp/env/jdbc/SQL2DS,
    instead of just jdbc/SQL2DS. I tried the first way and it didnt work. Again, it gave me a NullPointerException
    at the line Connection conn = ds.getConnection();
    I was confused why the 2nd and 3rd way didnt work . Is it becaue I used Microsoft's MS SQL Server Type 4 Driver?
    I have added the jar file in the WEBLOGIC_CLASSPATH. Why is it not recognising java:comp/env/jdbc/SQL2DS ?
    I would be grateful if somebody could give me ideas on this...
    Thanks
    Neeti

    To use application scoped or indirect JNDI lookups (i.e. java:comp/env/...) you usually need to define a &lt;resource-ref&gt; entry in your deployment descriptor(s). Not sure what type of application you are using to test (web-app, EJB,) but for java:comp/env/ lookups to work, you need to define resource references. The fact that your first test succeeded is somewhat strange. Without the resource reference definitions, I would have expected your JNDI lookups to fail with a NamingException instead of the lookup returning NULL for the datasource.
    Assuming you are doing your test from a web-app, you need to add &lt;resource-ref&gt; definitions to your web.xml file similar to the following:
    &lt;resource-ref&gt;
    &lt;res-ref-name&gt;*jdbc/SQL2DS*&lt;/res-ref-name&gt;
    &lt;res-type&gt;java.sql.DataSource&lt;/res-type&gt;
    &lt;res-auth&gt;Container&lt;/res-auth&gt;
    &lt;/resource-ref&gt;
    and then add &lt;reference-descriptor&gt; definitions to your weblogic.xml file similar to the following:
    &lt;reference-descriptor&gt;
    &lt;resource-description&gt;
    &lt;res-ref-name&gt;*jdbc/SQL2DS*&lt;/res-ref-name&gt;
    &lt;jndi-name&gt;*jdbc/SQL2DS*&lt;/jndi-name&gt;
    &lt;/resource-description&gt;
    &lt;/reference-descriptor&gt;
    Once you do these steps your lookup("java:comp/env/jdbc/SQL2DS") should function properly from within your web-app.

  • 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).

  • Failed in WD JNDI lookup in QA  Portal

    Hello Experts,
    I am facing the issue in custom WD application in QA portal system, in dev portal the application is working fine and after transporting the objects into QA portal ,while on preview the iview its giving me error : "Failed in WD JNDI lookup ".
    I have tested the WD application from Web dynpro console and its working fine , even i have created iview in QA portal and its working fine but while transporting the iview from DEV to QA Portal is not working . Can any one help me on that .
    Your help will highly appreciated ..
    Details error :
    com.sapportals.portal.prt.runtime.PortalRuntimeException: Failed in WD JNDI lookup. javax.naming.NameNotFoundException: No child found in WebDynproContext with name home~eth_dis
        at com.sap.portal.pcm.iview.admin.AdminBaseiView.createAttrSetLayersList(AdminBaseiView.java:357)
        at com.sap.portal.pcm.iview.admin.AdminBaseiView.getAttrSetLayersList(AdminBaseiView.java:205)
        at com.sap.portal.pcm.iview.admin.AdminBaseiView.getCustomImplementation(AdminBaseiView.java:148)
        at com.sap.portal.pcm.admin.PcmAdminBase.getImplementation(PcmAdminBase.java:530)
        at com.sapportals.portal.ivs.iviews.IviewServiceObjectFactory.getObjectInstance(IviewServiceObjectFactory.java:442)
        ... 40 more

    Hi Shanti,
    Thanks for the quick response.
    My portal version is EP 7 with SP21 .As I mention in my thread that I have tested custom application on QA Portal  and its working fine. But the problem is only appearing with the transported iview into QA portal.
    Regards
    Rashi

  • 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.

  • 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-

  • PortalRuntimeException: Failed in WD JNDI lookup.

    Hi Experts
    We are getting the following exception when we try to run our WD application in an iView :
    com.sapportals.portal.prt.runtime.PortalRuntimeException: Failed in WD JNDI lookup. javax.naming.NameNotFoundException: No child found in WebDynproContext with name xxxxx.com
    If we deploy and run our application as such on the server,it works fine.This issue comes only after we have integrated it in the iview.
    Please provide some pointers.

    Hello Kunal
    when you integrate it in an iView, pcd address/location should be there atttributes..i think it's missing
    Bhudev

  • Javax.naming.NamingException: Failed in WD JNDI lookup

    Hi,
               I have deployed wdj applications,some times its working fine ,but some other times its through the following errors.
    javax.naming.NamingException: Failed in WD JNDI lookup
    Any one please suggest me
    Thanks,
    Venu

    Hi Friend,
    I am not sure what Other Reason can be for this problem mean while check these links. Hope it will help.
    /message/6928201#6928201 [original link is broken]
    /message/6315352#6315352 [original link is broken]
    Regards
    Jeetendra

  • 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

  • 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?

Maybe you are looking for

  • Error in updating to table WRPT

    Hi All, I am trying to update lenght, width and height for Material . After i save the article and go back "It gives Express Document " which doesnot save the changes .. When i checked SM31 it gives error" Error in updating to table WRPT" Regards Vik

  • Remote client copy fails.

    Remote client copy fails. The error message and info is given below. Help me to proceed. Client copy The client copy you started has terminated Client Copy could not start because of Repository differences Diagnosis The table definitions differ betwe

  • How to Block Specific IP Address (YouTube)

    This is a follow-up question to one I posted earlier this week. I want to block YouTube (and a handful of other sites) from my stepson's new iMac and it was suggested I try/use Leopard's "Parental Control" feature. I tried that, but the problem is, w

  • S.M.A.R.T. Says 'hard drive is failing' - how to wipe?

    As the title says - S.M.A.R.T. says one of my internal hard drives is failing, and then prevents me from highlighting it to repair or erase. I have successfully copied the hard drive to a new drive, but how do I now wipe the failing drive?

  • Mac mail virus?

    I have a feeling that Iv picked up a worm or virus that has taken over my MobileMe mail account. I haven't gotten any mail to my MobileMe account so went to look. That's when I noticed that on the 29th and 30th I sent out 30 separate e-mails using 'v