Forum Stats

  • 3,837,095 Users
  • 2,262,225 Discussions
  • 7,900,202 Comments

Discussions

Simple JDBC via JNDI lookup on weblogic : RmiDataSource_12120_WLStub error?

Hi All,

  Really basic problem here hopefully.

Environment :

    Jdeveloper 11g

    Java 1.6

    Weblogic 12.1.2

    ojdbc6.jar

    database 11.2

All I'm doing is trying to code a very simple JDBC test from Jdeveloper to weblogic.

Without using JNDI, it all works fine using the following code :

        OracleDataSource ods = new OracleDataSource();

        ods.setUser("user");

        ods.setPassword("pwd");

        ods.setDriverType("thin");

        ods.setServerName("mycomputer.uk.oracle.com");

        ods.setDatabaseName("orcl");

        ods.setPortNumber(1521);        

        Connection conn2 = ods.getConnection();

        DatabaseMetaData meta = conn2.getMetaData();

        System.out.println("JDBC is " + meta.getDriverVersion());          

        System.out.println("Obj ods was: " + ods.getClass().getName());

the final s.o.p  prints out 'OracleDataSource.'

But with this code :

        Hashtable ht2 = new Hashtable();

        ht2.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.WLInitialContextFactory");

        ht2.put(Context.PROVIDER_URL, "t3:/mycomputer.uk.oracle.com:7001");

        Context ctx4 = null;

        ctx4 = new InitialContext(ht2);  

        javax.sql.DataSource ds = (javax.sql.DataSource)ctx4.lookup("jdbc/ConnectionTest1");  

        System.out.println("Obj was: " + ds.getClass().getName());

        Connection conn=((OracleDataSource)ds).getConnection();

The lookup works, but it fails on the last Connection line with the error :

Exception in thread "main" java.lang.ClassCastException: weblogic.jdbc.common.internal._RemoteDataSource_Stub cannot be cast to oracle.jdbc.pool.OracleDataSource

   -> now that was using  wlclient.jar  in the project properties in Jdeveloper,  wlclient,jar having been copied from the weblogic install.

However if I build wlfullclient.jar  on the weblogic server, copy that over to Jdev and use that instead in the project properties - extra library jar, I get a slightly different error :

Exception in thread "main" java.lang.ClassCastException: weblogic.jdbc.common.internal.RmiDataSource_12120_WLStub cannot be cast to oracle.jdbc.pool.OracleDataSource

This is bog-standard code out of the JDBC developer's guide. so this must surely be some noddy schoolboy error related to wrong versions or jar files or something?

The final S.o.p in the second set of code says  'Obj was: weblogic.jdbc.common.internal.RmiDataSource_12120_WLStub'

so I can understand why the cast is failing,  but the question is how can the code be modified to get this to work?  As said I'm not sure it is even the code at fault because

it is directly lifted from all the standard examples out there..

thanks!!!



Tagged:

Answers

  • Casting to an OracleDataSource is not standard JDBC. Remove that cast and just call getConnection() and be happy.

    Joe Weinstein-Oracle
  • This is bog-standard code out of the JDBC developer's guide. so this must surely be some noddy schoolboy error related to wrong versions or jar files or something?

    Post the link to that JDBC developer's guide that you say has that same code.

    The only remotely similar code I found was in the UCP Developer's guide.

    The sample code there shows setting the factory class that the pool should use:

      pds.setConnectionFactoryClassName("oracle.jdbc.pool.OracleDataSource");

    Weblogic is not likely to be using an Oracle extension class.

  • Thanks People!

      sometimes you can't see the wood for the trees.   Removing the unecessary cast was half the solution :-)

    I also found that the code *still* failed (but with a different error) if I used wlclient.jar  .

    I changed to wlfullclient.jar ,  and it all started working swimmingly  :-)

    However, that leads me onto the next and hopefully last simple question.   As you have probably guessed, I'm trying to get my head round the various options for JDBC both in a standalone client and a running-under-weblogic  scenario.

    One bit of example code I see just about everywhere is this :

    Context ctx = new InitialContext();

    ctx.bind("jdbc/sampledb", ods);

    This I lifted from   "Database JDBC Developer's Guide and Reference, 11g Release 1 (11.1)   B31224-04"    here :  http://docs.oracle.com/cd/B28359_01/java.111/b31224/urls.htm


    just search on ctx.bind to see what I mean.  The question is - in what scenarios would you code it this way?

    As an experiment, I ran ctx.bind to bind a new datasource :

           // at this point ds has been looked up from the context ctx4 and all works fine

            ctx4.bind("fred", ds);

            javax.sql.DataSource ds5 = (javax.sql.DataSource)ctx4.lookup("fred");

            Connection conn5= ds5.getConnection();

    - this all works fine as well, so my understanding is you can temporarily bind to a new name, but I'm trying to get my head round when you would do this?

    A revelation today was that weblogic itself comes with its own JDBC manual!  For 10.3.6 it is here :   http://docs.oracle.com/cd/E23943_01/web.1111/e13726.pdf

    So for someone trying to get into this, I am a bit bewildered as to which doc to start with..

    (  The ultimate goal here is to code a JDBC test to put load on a test database to investigate tuning options , and I want to code the JDBC connection in as many different ways as possible , to compare performance, so I want to do

    a client connection using the old DriverManager, another client using a datasource hard-coded, a third client using a datasource looked up from weblogic  (where there are all sorts of parameters to fiddle around with)  and lastly from a servlet/business component running under weblogic itself.)

      So apologies for my floundering around with this.   If you can suggest a good self-learning 'stream' that would be most helpful.  :-)

    regards and thanks.

  • If you are running a standalone java program to do JDBC, it can/should use the oracle driver directly to talk directly to the DBMS.

    Performance going from client to WebLogic to DBMS and back will have to have some specific reasons for doing it that way,

    to counterbalance the performance hit.

    Joe Weinstein-Oracle
This discussion has been closed.