Impossible de démarrer la base de données derby à partir de Netbeans 7.4

Question

J'ai téléchargé Netbeans 7.4 et Java 7 Update 51. Le message d'erreur ci-dessous s'affiche lorsque j'essaie de démarrer une connexion Java DB ou Derby à partir de Netbeans. Ceci est sur un PC Windows 8. J'ai téléchargé la version pour Windows XP 32 bits au travail. Ça fonctionne 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)
 

Answer 1

C'est ce que j'ai fait:

1. Savoir exactement où l'accueil java est par l'exécution de cette instruction de NetBeans 7.4 :

   Système..println(System.getProperty("java.home"));

   C'est la sortie de mon cas:

   C:\Program Files\Java\jdk1.7.0_51\jre

   ce qui est assez important pour moi, j'ai modifier un autre java.policy et n'a pas pris effet et le gaspillage de moi un couple d'heures.

2. Pour des raisons d' java.policy est un unix fichier de style et en lecture seule, j'ai ouvert et édité avec notepad++ et exécuté en tant qu'administrateur (sous le même accueil java):

   C:\Program Files\Java\jdk1.7.0_51\jre\lib\security\java.la politique

   Ajouter seulement ces lignes dans le fichier après la première subvention:

   subvention {
    permission java.net.SocketPermission "localhost:1527", "écouter";
   };

3. Enregistrez le fichier, ce qui est un peu difficile en raison de l'autorisation. Mais si vous lancez notepad++ ou tout autre programme d'édition en tant qu'administrateur, vous pouvez résoudre le problème.
   
   Puis essayez de vous connecter la base de données à partir de NetBeans, il fonctionne pour moi.

Bonne chance.

Answer 2

Selon le Java SE Development Kit 7, mise à Jour 51 Notes de Version

Changement de Socket par Défaut des Autorisations

La valeur par défaut prise autorisations attribuées à l'ensemble du code, y compris un code non fiable ont été modifiées dans cette version. Auparavant, l'ensemble du code a été en mesure de lier n'importe quel type de socket à tout numéro de port supérieur ou égal à 1024. Il est toujours possible de lier les sockets à la plage de ports éphémères sur chaque système. La portée exacte de ports éphémères varie d'un système d'exploitation à l'autre, mais il est généralement dans le haut de gamme (comme de 49152 à 65535). La nouvelle restriction est que la liaison sockets en dehors de la plage éphémère maintenant nécessite une autorisation explicite dans le système politique de sécurité.

La plupart des applications client à l'aide de sockets tcp et un responsable de la sécurité ne verrez pas de problème, tant que celles-ci se lient à des ports éphémères de toute façon. Applications à l'aide de datagram sockets ou le serveur de sockets tcp (et un responsable de la sécurité) peuvent rencontrer des exceptions de sécurité où aucun n'a été vu avant. Si cela se produit, les utilisateurs devraient examiner si le numéro de port requis est prévu, et si c'est le cas, une prise octroi d'autorisation peut être ajoutée à la stratégie de sécurité locale, pour résoudre le problème.

Cela signifie que vous devez explicitement définir les autorisations pour que votre demande puisse être en mesure d'accéder aux ports de gamme entre 1025 et 49151. Par conséquent, vous pouvez accorder cette autorisation en ajoutant cette ligne dans la liste des autorisations accordées:

Visitez votre Répertoire d'Accueil Java et accéder à votre fichier $JAVA_HOME/jre/lib/security/java.policy et apportez les modifications suivantes.

grant{
     //List of granted permissions
     permission java.net.SocketPermission "localhost:1527", "listen";
}

Answer 3

Voir http://www.oracle.com/technetwork/java/javase/7u51-relnotes-2085002.html pour la description du "problème". Recherche d'autres-libs/javadb

En fonction de vos besoins, ce que j'ai fait était d'aller modifier la stratégie de sécurité par défaut

cd $JAVA_HOME/jre/lib/security

Edit java.policy (faites d'abord une sauvegarde!)

Ajouter le suivant

grant codeBase "file:${java.home}}/../db/lib/*" {
        permission java.security.AllPermission;
};

Notez que c'est mon exigence.

Je suis l'octroi de chaque application qui utilise le u51 JRE la permission de commencer Derby.

MODIFIER

L'alternative serait d'utiliser un moins permissif définir des autorisations telles que:

grant codeBase "file:${java.home}}/../db/lib/*" {
    permission java.net.SocketPermission "localhost:1527", "listen,resolve";
};

NetBeans, par défaut, utilise le derby de la version installée avec GlassFish. Donc, mes autorisations de ressembler à ça sur le Mac. Elle sera similaire sur Windows, mais le chemin sera nécessaire de modifier.

grant codeBase "file:/Applications/NetBeans/glassfish-4.0/javadb/lib/*" {
    permission java.net.SocketPermission "localhost:1527", "listen,resolve";
};

Answer 4

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";
 

Answer 5

Vous pouvez également résoudre le problème sur une base par utilisateur, par l'octroi du besoin de la permission dans un fichier appelé" .java.policy dans votre répertoire home.

Fonctionne sur Unix et les systèmes Windows, comme indiqué ici: http://docs.oracle.com/javase/7/docs/technotes/guides/security/PolicyFiles.html

Cela peut être utile si le système politique à l'échelle fichier sera écrasé, par exemple lors de la mise à jour de votre JDK, ou si vous n'avez pas la permission de modifier le système de fichier.

C'est ce que j'ai dans ma $HOME/.java.policy:

grant {
    permission java.net.SocketPermission "localhost:1527", "listen";
};