Impossible de démarrer la base de données derby à partir de Netbeans 7.4
J'ai téléchargé Netbeans 7.4 et Java 7 mise à jour 51. Je reçois le message d'erreur ci-dessous lorsque je tente de démarrer Java DB ou connexion derby de Netbeans. Il s'agit d'un Windows 8 PC. J'ai téléchargé la version pour Windows XP 32 bits au travail. Cela fonctionne très bien. Je ne suis pas sûr de ce qui manque.
Thu Jan 16 00:48:23 EST 2014 : Security manager installed using the Basic server security policy.
Thu Jan 16 00:48:24 EST 2014 : access denied ("Java.net.SocketPermission" "localhost:1527" "listen,resolve")
Java.security.AccessControlException: access denied ("Java.net.SocketPermission" "localhost:1527" "listen,resolve")
at Java.security.AccessControlContext.checkPermission(AccessControlContext.Java:372)
at Java.security.AccessController.checkPermission(AccessController.Java:559)
at Java.lang.SecurityManager.checkPermission(SecurityManager.Java:549)
at Java.lang.SecurityManager.checkListen(SecurityManager.Java:1134)
at Java.net.ServerSocket.bind(ServerSocket.Java:375)
at Java.net.ServerSocket.<init>(ServerSocket.Java:237)
at javax.net.DefaultServerSocketFactory.createServerSocket(ServerSocketFactory.Java:231)
at org.Apache.derby.impl.drda.NetworkServerControlImpl.createServerSocket(Unknown Source)
at org.Apache.derby.impl.drda.NetworkServerControlImpl.access$000(Unknown Source)
at org.Apache.derby.impl.drda.NetworkServerControlImpl$1.run(Unknown Source)
at Java.security.AccessController.doPrivileged(Native Method)
at org.Apache.derby.impl.drda.NetworkServerControlImpl.blockingStart(Unknown Source)
at org.Apache.derby.impl.drda.NetworkServerControlImpl.executeWork(Unknown Source)
at org.Apache.derby.drda.NetworkServerControl.main(Unknown Source)
C'est ce que j'ai fait:
Découvrez exactement où Java la maison est en exécutant cette instruction à partir de NetBeans 7.4:
System.out.println (System.getProperty ("Java.home"));Voici le résultat pour mon cas:
C:\Program Files\Java\jdk1.7.0_51\jre
ce qui est assez important pour moi, je modifiais un autre
Java.policyet n'a pris aucun effet et m'a perdu une couple d'heures.Pour raison de
Java.policyest un fichier de style Unix en lecture seule, je l’ai ouvert et édité avec notepad ++ et exécuté en tant qu’administrateur (sous le même Java home):C:\Program Files\Java\jdk1.7.0_51\jre\lib\security\Java.policy
Ajoutez uniquement ces lignes dans le fichier après la première attribution:
grant { permission Java.net.SocketPermission "localhost: 1527", "listen"; };- Enregistrez le fichier, ce qui est un peu délicat pour la raison de la permission. Mais si vous exécutez notepad ++ ou tout autre programme d'édition en tant qu'administrateur, vous pouvez résoudre le problème.
Ensuite, essayez de connecter la base de données à partir de NetBeans, cela fonctionne pour moi.
Bonne chance.
Selon Notes de version de Java ™ SE Kit de développement 7, mise à jour 51
Modification des autorisations de socket par défaut
Les autorisations de socket par défaut affectées à tout le code, y compris le code non approuvé, ont été modifiées dans cette version. Auparavant, tout le code pouvait lier n'importe quel type de socket à un numéro de port supérieur ou égal à 1024. Il est toujours possible de lier des sockets à la plage de ports éphémère de chaque système. La plage exacte des ports éphémères varie d’un système d’exploitation à l’autre, mais elle se situe généralement dans la plage haute (de 49152 à 65535, par exemple). La nouvelle restriction est que la liaison de sockets en dehors de la plage éphémère nécessite désormais une autorisation explicite dans la stratégie de sécurité du système.
La plupart des applications utilisant des sockets client tcp et un gestionnaire de sécurité ne verront aucun problème, car ceux-ci se lient généralement à des ports éphémères. Les applications utilisant des sockets datagramme ou des sockets TCP serveur (et un gestionnaire de sécurité) peuvent rencontrer des exceptions de sécurité où aucune n'a été vue auparavant. Si cela se produit, les utilisateurs doivent vérifier si le numéro de port demandé est attendu et, le cas échéant, une autorisation de socket peut être ajoutée à la stratégie de sécurité locale pour résoudre le problème.
Cela signifie que vous devez définir explicitement les autorisations de votre application pour pouvoir accéder à la plage de ports comprise entre 1025 et 49151. Vous pouvez donc accorder cette permission en ajoutant cette ligne à la liste des permissions accordées:
Visitez votre répertoire personnel Java et accédez à votre fichier de règles à l'adresse $Java_HOME/jre/lib/security/Java.policy et apportez les modifications suivantes.
grant{
//List of granted permissions
permission Java.net.SocketPermission "localhost:1527", "listen";
}
Voir http://www.Oracle.com/technetwork/Java/javase/7u51-relnotes-2085002.html pour obtenir une description du "problème". Rechercher autre-libs/javadb
En fonction de vos besoins, ce que j'ai fait était de modifier la politique de sécurité par défaut.
cd $Java_HOME/jre/lib/security
Modifier Java.policy _ (faites d'abord une sauvegarde!)
Ajouter ce qui suit
grant codeBase "file:${Java.home}}/../db/lib/*" {
permission Java.security.AllPermission;
};
Notez que ceci est mon exigence.
J'accorde à toutes les applications qui utilisent l'utilitaire u51 JRE l'autorisation de démarrer Derby.
[~ # ~] éditer [~ # ~]
L’autre solution serait d’utiliser un ensemble d’autorisations moins permissives, comme:
grant codeBase "file:${Java.home}}/../db/lib/*" {
permission Java.net.SocketPermission "localhost:1527", "listen,resolve";
};
NetBeans utilise par défaut la version Derby installée avec GlassFish. Donc, mes autorisations ressemblent à ceci sur le Mac. Ce sera similaire sur Windows, mais le chemin devra changer.
grant codeBase "file:/Applications/NetBeans/glassfish-4.0/javadb/lib/*" {
permission Java.net.SocketPermission "localhost:1527", "listen,resolve";
};
Vous pouvez également résoudre le problème utilisateur par utilisateur en accordant l’autorisation nécessaire dans un fichier nommé .Java.policy dans votre répertoire personnel.
Fonctionne sur les systèmes Unix et Windows comme documenté ici: http://docs.Oracle.com/javase/7/docs/technotes/guides/security/PolicyFiles.html
Cela peut être utile si le fichier de stratégie à l’échelle du système est écrasé, par exemple lors de la mise à jour de votre JDK, ou si vous n’avez pas l’autorisation de modifier le fichier système.
C'est ce que j'ai dans mon $HOME/.Java.policy:
grant {
permission Java.net.SocketPermission "localhost:1527", "listen";
};
Comme les mesures supérieures ne fonctionnaient pas, j'ai ajouté l'autorisation suivante à la fin de la section d'autorisation principale:
permission Java.net.SocketPermission "localhost:1527", "listen,resolve";
Cela me faisait penser un peu jusqu'à ce que je tombe sur ce qui suit dans le wiki NetBeans
autorisations accordées par JavaDB
JavaDB accorder des autorisations
Comment accorder des autorisations pour Java DB/Comment démarrer Java DB
Relatif à la question # 239962
JDK 7u51 apporte des améliorations en matière de sécurité qui posent des problèmes de démarrage Java DB sur cette Java version.
Lorsque vous essayez de démarrer DB à partir de NetBeans, vous obtiendrez probablement l'exception:
Java.security.AccessControlException: accès refusé ("Java.net.SocketPermission" "localhost: 1527" "listen, resol")
La même exception que vous obtiendrez en commençant à utiliser script/db/bin/startNetworkServer
Parce qu’il n’existe aucun moyen approprié de le réparer du côté de NetBeans et que cela devrait être fixé du côté de la base de données Java.
Il existe plusieurs façons de traiter ce problème. Je ne mentionnerai que le moyen le plus simple. Vous devez démarrer DB manuellement à partir de la ligne de commande.
• Démarrer Java DB avec l'argument -noSecurityManager.
(Emplacement JDK 7u51)/db/bin/startNetworkServer -noSecurityManager
Bien que ce ne soit pas exactement une solution, il est utilisable comme solution de contournement rapide.
J'en ai un peu marre de l'approche d'Oracle en matière de sécurité ces derniers temps. Ils semblent essayer de nous protéger de nous-mêmes d'une manière qui conviendrait davantage aux utilisateurs naïfs qu'aux programmeurs. Mon avis est que le code que je mets sur ma propre machine devrait être capable de faire tout ce dont il a besoin. C'est ma faute si je mets du code là-bas qui fait de mauvaises choses. Ce n’est clairement pas une perspective universellement fiable, mais cela m’a travaillé pendant environ 35 ans. Sur cette base, j'ajoute ceci à mon fichier /lib/security/Java.policy:
grant codeBase "file:/-" {
permission Java.security.AllPermission;
};
notez que le fichier:/- correspond à n’importe quel fichier du système et que le bloc d’octroi dit en substance "Si la classe est chargée à partir de ce système de fichiers, faites-lui confiance".
Une alternative consiste à changer le port que JavaDB écoute, pour être maintenant dans la plage haute (telle que de 49152 à 65535). Allez dans Fenêtre-> Services, puis cliquez avec le bouton droit de la souris sur Java DB et dans la "Boîte de dialogue Propriétés de la base de données Java", allez à "Emplacement de la base de données", qui dans mon système correspond à "C:\Users\ahernandeza.netbeans -derby "Dans ce répertoire, éditez ou créez le fichier derby.properties, et ajoutez/modifiez la ligne: derby.drda.portNumber = XXXX Où XXXX est le nouveau port, dans mon cas, j'ai mis 51527 et ai très bien fonctionné.
EDIT Au premier coup d'œil, cela a fonctionné, le service a bien démarré, mais lors de la création ou du démarrage d'une base de données au Nouveau-Brunswick, j'ai eu l'erreur Impossible de se connecter. Je ne parviens pas à établir une connexion à jdbc: derby: // localhost: 1527/sample Bien que j'ai changé le numéro d'impression à 51527, il essaie de se connecter à 1527.
Si Linux, alors
file=`find $(dirname $(readlink -f $(which Java)))/.. -iname 'Java.policy'`; grep 1527 $file || Sudo sed -i '0,/"listen"/{s/"listen".*/\0\n\tpermission Java.net.SocketPermission "localhost:1527", "listen";/}' $file
cat $file
il trouve automatiquement votre Java et modifie les autorisations
J'ai trouvé une solution rapide à ce problème - Démarrez votre JavaDB à partir de la ligne de commande\terminal comme suit:
<base folder>/db/bin/startNetworkServer -noSecurityManager
Ensuite, il fonctionne correctement sans ajouter de nouvelles autorisations.
Ma solution à cela était de réinstaller jdk 1.7.45, de désinstaller Netbeans et de le réinstaller en sélectionnant le jdk obsolète. Je ne sais pas s’il existe un moyen de changer sdk dans NB sans le réinstaller, mais cela a fonctionné de cette façon.