web-dev-qa-db-fra.com

Aucun pilote approprié trouvé pour la connexion à la base de données Oracle

J'ai une petite application Java, qui s'exécute tous les jours et vérifie la présence de données dans la base de données à l'aide de Cronj Schedular et tout fonctionne bien, mais j'ai récemment constaté que cela échouait à cause de 

Java.sql.SQLException: No suitable driver found for jdbc:Oracle:thin:@160.110.xx.xxx:1521/test

En même temps, lorsque je lance mon code de test pour vérifier la connectivité de la base de données, elle fonctionne correctement sans exception ci-dessus. Je suis incapable de comprendre. Bien que le code ait légèrement changé, cela n’était lié à aucune base de données ou connexion à une base de données. Quelqu'un m'aide-t-il?

dbconf.Java 

public class dbconf {

    private Connection connect;
    private String connstr;

    public Connection getConnection() throws SQLException {
        connstr = "jdbc:Oracle:thin:@160.110.xx.xxx:1521/test";

        try {
                String uname = "scott";
                String pass = "tiger";
                Class.forName("Oracle.jdbc.OracleDriver").newInstance();
                connect = DriverManager.getConnection(connstr, uname, pass);

        } catch (Exception e) {
            System.out.println(e.toString());
        }

            return connect;
    }
}

J'utilise ojdbc6.jar et Oracle11g

Edité - Fichier journal d'application 

Wed Jul 01 09:25:17 IST 2015:------- Initializing -------------------
Wed Jul 01 09:25:17 IST 2015:------- Scheduling Jobs ----------------
Wed Jul 01 09:25:17 IST 2015:------- Job Started Running ----------------
Thu Jul 02 06:00:00 IST 2015 : Job Executed..!! Bschedularv2.2
Java.sql.SQLException: No suitable driver found for jdbc:Oracle:thin:@160.xxx.67.xxx:1521/test
Sat Jul 04 06:00:00 IST 2015 : Job Executed..!! Bschedularv2.2
Sun Jul 05 06:00:00 IST 2015 : Job Executed..!! Bschedularv2.2
Java.sql.SQLException: No suitable driver found for jdbc:Oracle:thin:@160.xxx.67.xxx:1521/test

Donc, vous pouvez voir, Il a échoué les 3 et 6 juillet. Mais entre les deux, tout s'est bien passé.

== Mise à jour 1 ==

Il semble que personne ne lise ma question correctement, j’ai clairement indiqué que cela fonctionnait bien un jour, mais qu’il échouait un jour. Si c'était un problème de classpath, alors il n'aurait pas dû être exécuté n'importe quel jour. 

=== Mise à jour 2 ===

Bon nombre des réponses ci-dessous étaient inutiles, mais peu avaient une vision logique. J'ai utilisé printStracktrace et essayé de déboguer chaque point et j'ai enfin eu un indice. Il y a 3 jours, j'ai déployé la nouvelle version de l'application sur le même serveur (printStackTrace et SysOut inclus). Les deux premiers jours ont fonctionné correctement. Aujourd'hui, il a échoué avec l'erreur suivante. 

INFO: Illegal access: this web application instance has been stopped already.  Could not load com.schedular.job.BirthdayJob.  The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
Java.lang.IllegalStateException
    at org.Apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.Java:1600)
    at org.Apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.Java:1559)
    at org.quartz.simpl.LoadingLoaderClassLoadHelper.loadClass(LoadingLoaderClassLoadHelper.Java:59)
    at org.quartz.simpl.CascadingClassLoadHelper.loadClass(CascadingClassLoadHelper.Java:99)
    at org.quartz.simpl.CascadingClassLoadHelper.loadClass(CascadingClassLoadHelper.Java:138)
    at org.quartz.impl.jdbcjobstore.StdJDBCDelegate.selectJobDetail(StdJDBCDelegate.Java:852)
    at org.quartz.impl.jdbcjobstore.JobStoreSupport.acquireNextTrigger(JobStoreSupport.Java:2816)
    at org.quartz.impl.jdbcjobstore.JobStoreSupport$40.execute(JobStoreSupport.Java:2759)
    at org.quartz.impl.jdbcjobstore.JobStoreSupport$40.execute(JobStoreSupport.Java:2757)
    at org.quartz.impl.jdbcjobstore.JobStoreSupport.executeInNonManagedTXLock(JobStoreSupport.Java:3787)
    at org.quartz.impl.jdbcjobstore.JobStoreSupport.acquireNextTriggers(JobStoreSupport.Java:2756)
    at org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.Java:272)

Jul 13, 2015 6:00:00 AM org.Apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped already.  Could not load com.schedular.job.BirthdayJob.  The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
Java.lang.IllegalStateException
    at org.Apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.Java:1600)
    at org.Apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.Java:1559)
    at org.quartz.simpl.LoadingLoaderClassLoadHelper.loadClass(LoadingLoaderClassLoadHelper.Java:59)
    at org.quartz.simpl.CascadingClassLoadHelper.loadClass(CascadingClassLoadHelper.Java:99)
    at org.quartz.simpl.CascadingClassLoadHelper.loadClass(CascadingClassLoadHelper.Java:138)
    at org.quartz.impl.jdbcjobstore.StdJDBCDelegate.selectJobDetail(StdJDBCDelegate.Java:852)
    at org.quartz.impl.jdbcjobstore.JobStoreSupport.retrieveJob(JobStoreSupport.Java:1385)
    at org.quartz.impl.jdbcjobstore.JobStoreSupport.triggerFired(JobStoreSupport.Java:2964)
    at org.quartz.impl.jdbcjobstore.JobStoreSupport$43.execute(JobStoreSupport.Java:2908)
    at org.quartz.impl.jdbcjobstore.JobStoreSupport$43.execute(JobStoreSupport.Java:2901)
    at org.quartz.impl.jdbcjobstore.JobStoreSupport.executeInNonManagedTXLock(JobStoreSupport.Java:3787)
    at org.quartz.impl.jdbcjobstore.JobStoreSupport.triggersFired(JobStoreSupport.Java:2900)
    at org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.Java:336)
javajdbcoracle11gdriversqlexception
14
Ravi

Comme quelqu'un m'a approché pour la solution de ce problème. Je le poste maintenant.

  1. J'ai annulé le déploiement de l'application qui posait ce problème et nettoyé tous les fichiers associés du serveur.
  2. Ensuite, j'ai redémarré le serveur Tomcat. Ainsi, tous les fichiers temporaires et le cache seront effacés.
  3. Ensuite, j'ai déployé la même application et elle a commencé à fonctionner sans problème.
0
Ravi

Ne conservez pas le nom du pilote de manière statique. Utilisez l'API JDBC + Java pour obtenir le nom de la classe du pilote comme suit:

public class dbconf {

    private Connection connect;
    private String connstr;

    public Connection getConnection() throws SQLException {
        connstr = "jdbc:Oracle:thin:@160.110.xx.xxx:1521/test";

        try {
                String uname = "scott";
                String pass = "tiger";
                Class.forName(OracleDriver.class.getClass().getName().toString()).newInstance();
                connect = DriverManager.getConnection(connstr, uname, pass);

        } catch (Exception e) {
            System.out.println(e.toString());
        }

            return connect;
    }
}

Il est préférable que vous fassiez une faute de frappe ou que vous vérifiiez si ojdbc6.jar est correctement défini dans le chemin de compilation.

J'espère que cette information aide ...

0
Ram72119

Une solution possible est la suivante: Allez à Observateur d'événements -> Archives Windows et supprimez les événements d'application et les événements système (NE PAS supprimer les événements de sécurité!). Après cela, redémarrez votre ordinateur et tout ira bien.

0
grlouk

Le format correct pour votre URL JDBC n’est pas celui que vous avez écrit: 

connstr = "jdbc: Oracle: thin: @ 160.110.xx.xxx: 1521/test";

mais soit

connstr = "jdbc: Oracle: thin: @ // 160.110.xx.xxx:1521/test";

ou

connstr = "jdbc: Oracle: thin: @ 160.110.xx.xxx: 1521: test";

selon que "test" est un service ou un SID.

Le fragment de journal que vous avez montré ne montre pas que la méthode getConnection a fonctionné le 4! Cela montrait seulement qu'aucune erreur n'était commise. Cela peut simplement signifier que la méthode n'a jamais été appelée (aucune connexion n'a donc été tentée).

0
jwenting

Il semble que le problème réside dans le fait que votre fichier jar tente de remplacer par ojdbc14.jar et de l'ajouter à Class-path si vous utilisez Eclipse en procédant comme suit: - Eclipse -> (Sélectionnez le projet) Accédez à Propriétés - > Chemin de construction Java -> Choisissez Ajouter un fichier ou Ajouter un fichier externe.

0
Dharamendra Prajapati

Si possible, affichez la méthode println for DriverManager.getConnection () . Vous obtiendrez peut-être un objet de connexion nul de la base de données sans aucune exception, lors d’échecs.

SQLException reason = null;
for(DriverInfo aDriver : registeredDrivers) {
    if(isDriverAllowed(aDriver.driver, callerCL)) {
        try {
            println("    trying " + aDriver.driver.getClass().getName());
            Connection con = aDriver.driver.connect(url, info);
            if (con != null) {
                println("getConnection returning " + aDriver.driver.getClass().getName());
                return (con);
            }
        } catch (SQLException ex) {
            if (reason == null) {
                reason = ex;
            }
        }

    } else {
        println("    skipping: " + aDriver.getClass().getName());
    }

}
if (reason != null)    {
    println("getConnection failed: " + reason);
    throw reason;
}
println("getConnection: no suitable driver found for "+ url);
throw new SQLException("No suitable driver found for "+ url, "08001");
0
Amit Parashar

Pas sûr que ça aide, mais c'est le code pour lequel je dois faire la même chose, 

    try { 
        Class.forName("Oracle.jdbc.driver.OracleDriver"); 
    } catch (ClassNotFoundException e) { 
        System.out.println("Could not load the driver"); 
    } 

    Connection conn = DriverManager.getConnection                                     ("jdbc:Oracle:thin:@ten10:1521:acdb", user, pass);

Donc, pas tout à fait le même Class.forName, mais le même formulaire pour le protocole.

La classe de nom est essentielle, car elle garantit que le chargeur de classes a chargé le pilote Oracle jdbc. 

Ce qui pourrait se produire est un problème de connectivité sur la machine sur laquelle le code est exécuté, de sorte que l'emplacement contenant le fichier ojdbc6.jar (indiqué sur le chemin de classe) ne soit pas toujours accessible (si ce n'est pas sur un disque local?) .

0
Yann TM

Il semble que "ojdbc6.jar" ne soit pas dans le CLASSPATH de votre serveur d'applications.

0
sriharichander

Quand il dit qu'il ne peut pas trouver de classe, il ne peut pas trouver de classe.

D'après mon expérience, ce type de problèmes, qui fonctionnent parfois et qui ne le sont pas parfois, sont liés aux threads. Mon hypothèse est ClassLoader est le chargement de votre classe async, donc appeler une connexion juste après le chargement peut être le problème. avez-vous essayé de charger la classe Oracle dans une partie statique? quelque chose comme:

public class dbconf {

static {
  Class.forName("Oracle.jdbc.OracleDriver");
}

public Connection getConnection() throws SQLException {
    String connstr = "jdbc:Oracle:thin:@160.110.xx.xxx:1521/test";
    try {
        String uname = "scott";
        String pass = "tiger";
        return DriverManager.getConnection(connstr, uname, pass);
    } catch (Exception e) {
        System.out.println(e.toString());
    }
}
}

Autre problème: votre code est-il compilé tous les jours (par livraison continue ou ...)?

0
alizelzele

Je ne suis pas familier avec "schedular" mais votre dernière mise à jour suggère que vous avez des threads qui n'ont pas été arrêtés proprement d'un précédent déploiement/redéploiement précédent. Il existe un bulletin d’information JavaSpecialists sur la façon d’arrêter les threads proprement .

Je me demande si votre code d’arrêt de la servlet désenregistre le pilote de la base de données? À partir de votre pile, il semble que vous exécutiez Tomcat. Même si votre code ne désenregistre pas directement le pilote, je pense que Tomcat 7 et versions ultérieures vont désenregistrer les pilotes dans le cadre de la détection/atténuation des fuites de mémoire de Tomcat.

Cela pourrait expliquer pourquoi le pilote est parfois présent et parfois pas.

0
Ryan