Unable to start derby database from Netbeans 7.4

JavaNetbeansDerby

Java Problem Overview


I downloaded Netbeans 7.4 and Java 7 Update 51. I get the below error when I try to start Java DB or derby connection from Netbeans. This is on a windows 8 PC. I downloaded the version for windows xp 32 bit at work. It works fine. I am not sure what is missing.

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)

connection properties java db properties

Java Solutions


Solution 1 - Java

This is what I did:

  1. Find out exactly where the java home is by executing this instruction from NetBeans 7.4 :

System.out.println(System.getProperty("java.home"));
This is the output for my case:
C:\Program Files\Java\jdk1.7.0_51\jre

which is quite important for me, I was modifying another java.policy and took no effect and wasted me a couple of hours.

  1. For reason of java.policy is an unix style file and read-only, I opened and edited it with notepad++ and executed as administrator (under the same java home):

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

Add only these lines into the file after the first grant:

<pre>grant {
    permission java.net.SocketPermission "localhost:1527", "listen";
};</pre>

3. Save the file, which is a little tricky for reason of the permission. But if you run notepad++ or any other edit program as administrator, you can solve the problem.

Then try to connect the database from NetBeans, it works for me.

Good luck.

Solution 2 - Java

According to Java™ SE Development Kit 7, Update 51 Release Notes

> Change in Default Socket Permissions > > The default socket permissions assigned to all code including untrusted code have been changed in this release. Previously, all code was able to bind any socket type to any port number greater than or equal to 1024. It is still possible to bind sockets to the ephemeral port range on each system. The exact range of ephemeral ports varies from one operating system to another, but it is typically in the high range (such as from 49152 to 65535). The new restriction is that binding sockets outside of the ephemeral range now requires an explicit permission in the system security policy. > > Most applications using client tcp sockets and a security manager will not see any problem, as these typically bind to ephemeral ports anyway. Applications using datagram sockets or server tcp sockets (and a security manager) may encounter security exceptions where none were seen before. If this occurs, users should review whether the port number being requested is expected, and if this is the case, a socket permission grant can be added to the local security policy, to resolve the issue.

This means that you have to explicity set the permissions for your application to be able to access the ports range between 1025 and 49151. You can therefore grant this permission by appending this line in the list of permissions granted:

Visit your Java Home Directory and access your policy file at $JAVA_HOME/jre/lib/security/java.policy and make the following changes.

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

Solution 3 - Java

See http://www.oracle.com/technetwork/java/javase/7u51-relnotes-2085002.html for the description of the "problem". Search other-libs/javadb

Depending on your requirement, what I did was go and modify the default security policy

cd $JAVA_HOME/jre/lib/security

Edit java.policy (make a backup first!)

Add the following

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

Note that this is my requirement.

I'm granting every app who uses the u51 JRE the permission to start Derby.

EDIT

The alternative would be to use a less permissive set of permissions like:

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

NetBeans, by default, uses the derby version installed with GlassFish. So my permissions look like this on the Mac. It will be similar on Windows, but the path will need to change.

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

Solution 4 - Java

Because the upper measures didn't work I added the following permission to the end of the main permission section:

permission java.net.SocketPermission "localhost:1527", "listen,resolve";

Solution 5 - Java

You can also solve the problem on a per-user basis by granting the needed permission in a file called .java.policy in your home directory.

Works on both Unix and Windows systems as documented here: http://docs.oracle.com/javase/7/docs/technotes/guides/security/PolicyFiles.html

This might be useful if the system-wide policy file gets overwritten, for example when updating your JDK, or if you don't have permission to edit the system file.

This is what I have in my $HOME/.java.policy:

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

Solution 6 - Java

I got a bit fed up with Oracle's approach to security lately. They seem to be trying to protect us from ourselves in ways that would be more appropriate to naive users than programmers. My view is that the code I put on my own machine should be able to do whatever it needs to. It's my fault if I put code there that does bad things. Clearly not a universally reliable perspective, but it's worked for me for about 35 years. On that basis, I add this to my /lib/security/java.policy file:

grant codeBase "file:/-" {
    permission java.security.AllPermission;
};

note that the file:/- matches any file on the system, and the grant block says, in essence, "if the class is loaded from this file system, then trust it".

Solution 7 - Java

This was doing my head in for a bit until I stumbled across the following in the NetBeans wiki

JavaDB grant permissions

> JavaDB grant permissions >
> How to grant permissions for Java DB / How to start Java DB >
> Related to issue #239962 >
> JDK 7u51 comes with some security improvements which are causing > problems with starting Java DB on this Java version. >
> When you try to start DB from NetBeans you will probably get the > Exception: >
> java.security.AccessControlException: access denied > ("java.net.SocketPermission" "localhost:1527" "listen,resolve") >
> The same exception you will get while starting using script location>/db/bin/startNetworkServer > > Because there is no suitable way to fix it on the NetBeans side and > this should be fixed on the side of the Java DB. >
> There are several ways how to deal with this problem. I will mention > only the easiest way. You have to start DB manually from command line. > > • Start Java DB with -noSecurityManager argument.
>
> (JDK 7u51 location)/db/bin/startNetworkServer -noSecurityManager

Although it’s not exactly a solution it is usable as a quick workaround.

Solution 8 - Java

My solution to this was to reinstall jdk 1.7.45, uninstall netbeans and reinstall it selecting the outdated jdk. Don't know if there is a way to change sdk in NB without reinstalling it but it worked this way.

Solution 9 - Java

Well, one alternative is to change the port JavaDB listens to, to be now in the high range (such as from 49152 to 65535). Go to Window->Services, then right click Java DB and in "Java DB Properties Dialog" goto to "Database Location", which in my system is "C:\Users\ahernandeza.netbeans-derby" In that directory edit or create the file derby.properties, and add/edit the line: derby.drda.portNumber=XXXX Where XXXX is the new port, in my case i put 51527 and worked just fine.

EDIT At fisrt glance it worked, the service started just fine, but when creating or starting a database in NB, i got the error Unable to connect. CAnnot establish a connection to jdbc:derby://localhost:1527/sample Although i changed the pprt to 51527, it tries to connect to 1527

Solution 10 - Java

If linux, then

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

it automatically finds your java and changes permissions

Solution 11 - Java

I found a quick solution to this problem - Start your JavaDB from the command line\terminal like so:

<base folder>/db/bin/startNetworkServer -noSecurityManager

Then it runs fine without adding new permissions.

Solution 12 - Java

The problem is the Java 7u51, it have a bug that affect Derby and other programs and libraries, I suggest to install the Java 7u45

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionSuperman9999View Question on Stackoverflow
Solution 1 - Javauser2060065View Answer on Stackoverflow
Solution 2 - JavaPatrick WView Answer on Stackoverflow
Solution 3 - JavaChuk LeeView Answer on Stackoverflow
Solution 4 - JavaLeoTomView Answer on Stackoverflow
Solution 5 - JavaAndreaView Answer on Stackoverflow
Solution 6 - Javauser230146View Answer on Stackoverflow
Solution 7 - Javauser3381021View Answer on Stackoverflow
Solution 8 - Javauser3206735View Answer on Stackoverflow
Solution 9 - JavaAlejandro Hdez. AngelesView Answer on Stackoverflow
Solution 10 - Javatest30View Answer on Stackoverflow
Solution 11 - JavaDanielView Answer on Stackoverflow
Solution 12 - JavaGianluigi PieriniView Answer on Stackoverflow