7 Replies Latest reply on Jan 7, 2002 5:49 AM by bezdicek

    JNDI / EJBs & Oracle

    bezdicek

      Hi there,

      I am facing quite a tricky problem which I was not able to solve. I try to use the JNDI from my JBoss/2.4.3 AppServer to get a Session Bean which I want to use in a Java Stored Procedure on my Oracle DB (8.1.7).
      So far it seems that the context to the JBoss JNDI can be established but the lookup fails. I tried to make a Socket Connection to the JNDI Port from inside the Database and it worked (receiving a java.rmi.MarshalledObject) so it cant be a permission problem.
      Deploying the jboss-client libraries failed (I think that might be a JDK Version issue) so I use the oracle (aurora) jndi classes.

      Has anyone solved this issue (or can describe why it cant be solved)?

      thx

        • 1. Re: JNDI / EJBs & Oracle
          terry_ray

          Hi,

          I'm pretty sure you won't be able to use the aurora JNDI classes to get a context to the JBoss JNDI implementation. To get a context in JBoss, you'll need the org.jnp.interfaces.NamingContextFactory as the initial context factory. You'll need support for JNP. The aurora classes would have no knowledge of supporting JNP.

          You're probably correct in the JDK version problem. I believe the Oracle 8i JVM is still on 1.2 or possibly 1.1.7. Is it possible to try running Oracle on a more recent JDK and then attempting to load the JBoss client jars again? If you can get the JNP stuff loaded, you can probably create the initial context you need.

          Just a thought. Good luck.

          Terry

          • 2. Re: JNDI / EJBs & Oracle
            bezdicek

            the jnp classes havent been the problem to get resolved I can deploy them (jnp-client.jar). The funny thing is, that it seems that I get a InitialContext, but all the properties I seet doesnt seem to affect it. So when I do a InitialContext.list() I get back something but not the things available via JBoss JNDI (I get bin etc service system test and webdomains, but neither a queue nor a Bean).
            So it looks like it makes an InitialContext without any environments passed.
            Any hints?

            • 3. Re: JNDI / EJBs & Oracle
              terry_ray

              It sounds like you are getting a context to the Oracle container, even when passing settings for the JBoss environment. Are you using an account that would have permissions to modify the container settings? I'm not sure if this would need to be a db sa account or an os privileged user account (or both). But, you would definitely need access to modify the properties of the Oracle environment. Even so, if it is hard-wired to Oracle, there may be no way to change it.

              I'm assuming you've tried this from a stand-alone app outside the Oracle database and it works fine. Maybe you can store the HomeHandle of the bean to the file system (or do it the Oracle way and store it in the database) and retrieve it from your stored procedure without JNDI. I know this not would be an elegant solution, but it might work...

              • 4. Re: JNDI / EJBs & Oracle
                markd

                Are you doing something like this:

                String dbName = "java:/OracleDB";
                entityBeanContext = new InitialContext();
                DataSource ds = (DataSource) entityBeanContext.lookup(dbName);
                con = ds.getConnection();
                ps = con.prepareStatement(queryString);
                ps.setInt(1, serviceInstanceUid);
                ps.setInt(2, metricTypeUid);
                ps.setTimestamp(3, startDate);
                ps.setTimestamp(4, endDate);
                result = ps.executeQuery();

                And the do you have something like this in your ejb-jar.xml:

                <ejb-name>YourBean</ejb-name>
                .
                .
                .
                <session-type>Stateless</session-type>
                <transaction-type>Container</transaction-type>
                <resource-ref>
                <res-ref-name>java:/OracleDB</res-ref-name>
                <res-type>javax.sql.DataSource</res-type>
                <res-auth>Application</res-auth>
                </resource-ref>


                Where OracleDB is the JNDI name that you used to configure the datasource.

                • 5. Re: JNDI / EJBs & Oracle
                  bezdicek

                  No I am not trying something like this.
                  Config like this
                  JBoss Application server running lots of EJBs (Session and MDB).
                  What I want to do is to trigger from a java stored procedure from inside the oracle-DB a session bean deployed at JBoss to start and process (is a quite a complicate process producing loads of data). running oc4j is a possibility but not a nice one, due to some special characteristics of our beans and framework.

                  any hints?

                  • 6. Re: JNDI / EJBs & Oracle
                    terry_ray

                    Hi,

                    I just wanted to follow up on this post about trying to get an initial context into JBoss JNDI from an Oracle Java Stored Procedure. I am currently trying to do something very similar except I’m trying to access a JMS TopicConnectionFactory instead of an EJB. I’m also finding that my stored procedure code doesn’t create the initial context for JBoss. I was curious about if anyone has had any success doing this. If so, please share some info on it. I suspect that the Java environment in Oracle is "hard-wired" so that you cannot change the initial context to an external container (JBoss) but if there is a way to do this, I'd love to hear about it. Thanks.

                    • 7. Re: JNDI / EJBs & Oracle
                      bezdicek

                      Hi!

                      As far as i found out, there is some kind of a bug in the jndi implementation oracle did, it does not pass to the correct SPI classes if the type of request for a jndi is different than specified in the oracle SPI classes. I have not found a workaround so far.