Category Archives: java

Netbeans 8.1 “No tests executed”

Recently I’ve started to learn and practise unit testing in Java using JUnit to improve my productivity and confidence in my own code. Netbeans is quite useful for tests too, because it automates many things while writing and running the tests. However today I noticed something weird: I wrote some tests and I could run them just fine by themselves from the projects widget using the context menuitem “test file”, however when I wanted to “test project” from the run menu, Netbeans said “No tests executed” in the test window. I started digging and unfortunately I couldn’t find anything useful. However I noticed that in all the examples the test classes were called XYZTest, while my test classes are were named TestXYZ. I tried to rename then and guess what? Renaming them solved the problem. So to sum my experiences up:

If you want Netbeans to find and run your test classes name them like this: XYZTest. Where XYZ can be of course an arbitrary string that is legal in a class name in Java.

Advertisements

Tomcat 7 servlet context parameters

In desktop applications we typically configure our application by reading a config file, and using the values found.

In a Java web application however there’s a better way, because there’s already a config file we can use, and this is the web.xml file, where we can place the so called context init parameters, that are loaded during the web application’s startup. In this article I’m going to show how this works.

There are 3 things we must do to make this all work

  • Create a so called ContextListener subclass that will listen to events such as context initialization (servlet startup).
  • Tell Tomcat we have such a listener class and that it should tell it about such events, by referencing our class in the web.xml file
  • Place the parameters and values in the web.xml file

This is how a ContextListener class looks like:

package something.something.darkside;

import javax.servlet.ServletContext;
import javax.servlet.ServletContextListener;
import javax.servlet.ServletContextEvent;

public class ContextListener implements ServletContextListener
{
@Override
public void contextInitialized( ServletContextEvent event )
{
final ServletContext context = event.getServletContext();
final String dbdriver = context.getInitParameter( “dbdriver” );
final String dburl = context.getInitParameter( “dburl” );
}

@Override
public void contextDestroyed( ServletContextEvent event )
{
}
}

As we can see the class has 2 methods that need to be implemented, the contextInitialized and contextDestroyed events. We can read the context parameters in the contextInitialized class and then do whatever we want with them.

Let’s now see the relevant parts of such a web.xml file:

<?xml version=”1.0″ encoding=”UTF-8″?>
<web-app xmlns=”http://java.sun.com/xml/ns/javaee&#8221;
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance&#8221;
xsi:schemaLocation=”http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd&#8221;
version=”3.0″>
<context-param>
<param-name>dbdriver</param-name>
<param-value>com.mysql.jdbc.Driver</param-value>
</context-param>
<context-param>
<param-name>dburl</param-name>
<param-value>jdbc:mysql://localhost/database</param-value>
</context-param>
<listener>
<listener-class>something.something.darkside.ContextListener</listener-class>
</listener>

As we can see we have 2 parameters here dbdriver, and dburl, which are database connection configuration parameters in this case. Also we have the context event listener class references. If we restart Tomcat now when starting up the servlet it will tell the context listener about the startup and it can read the parameters.

That’s it. It’s this simple!

Java applet woes with https

Last year I created a simple Asterisk ( a VOIP server software ) extension monitor java applet for a client. It worked fine, but there was a problem when trying to load it from a https URL. It kept throwing exceptions.
Since it doesn’t send or receive any sensitive information, and it works inside an office in a closed system, it wasn’t a problem, just had to make sure the applet is loaded from http.

However today I had to deal with the applet again, and I wanted to solve this problem this time. On Windows 8 ( Windows 7, and Linux with OpenJDK IcedTea plugin doesn’t seem to be affected this time ) it kept throwing me these exceptions:

java.lang.ExceptionInInitializerError
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at sun.security.jca.ProviderConfig$2.run(Unknown Source)
at sun.security.jca.ProviderConfig$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.jca.ProviderConfig.doLoadProvider(Unknown Source)
at sun.security.jca.ProviderConfig.getProvider(Unknown Source)
at sun.security.jca.ProviderList.getProvider(Unknown Source)
at sun.security.jca.ProviderList.getService(Unknown Source)
at sun.security.jca.GetInstance.getInstance(Unknown Source)
at javax.net.ssl.SSLContext.getInstance(Unknown Source)
at com.sun.deploy.net.protocol.https.Handler$Initializer$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.net.protocol.https.Handler$Initializer.<clinit>(Unknown Source)
at com.sun.deploy.net.protocol.https.Handler.openConnection(Unknown Source)
at java.net.URL.openConnection(Unknown Source)
at sun.net.www.protocol.jar.JarURLConnection.<init>(Unknown Source)
at sun.plugin.net.protocol.jar.CachedJarURLConnection.<init>(Unknown Source)
at sun.plugin.net.protocol.jar.Handler.openConnection(Unknown Source)
at java.net.URL.openConnection(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.getJarFile(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.access$800(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.ensureOpen(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.<init>(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Caused by: java.security.AccessControlException: access denied (“java.lang.RuntimePermission” “loadLibrary.sunec”)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at sun.plugin2.applet.AWTAppletSecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkLink(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at sun.security.ec.SunEC$1.run(SunEC.java:60)
at sun.security.ec.SunEC$1.run(SunEC.java:58)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.ec.SunEC.<clinit>(SunEC.java:58)

While I was googling around, I found this stackexchange discussion, that is about basically the same exception. So I tried the offered solution, and guess what? It worked.
So apparently the JRE doesn’t have permission to access it’s own libraries while running an applet from a https URL.

So to reiterate the solution: If for whatever reason you encounter this exception, try adding the following to your java.policy file in the JRE’s lib/security directory:

grant codeBase “file:${{java.ext.dirs}}/*” {
permission java.security.AllPermission;
};

Interestingly enough, on Windows 7 the policy file already has this entry! Which is plain weird.