Category Archives: programming

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

Drupal 8 entity access permission problems

Sometimes even when you think you’ve given all the correct permissions to a user role Drupal still denies access to a node. This happened to me this week at work unfortunately and I spent some time digging through Drupal 8’s codebase to track down where and why it does this. So in case someone else has this problem as well, these calls in order are the interesting code parts to check out.

AccessManager::check
AccessManager::performCheck
EntityAccessCheck::access
Node::access
ContentEntityBase::access
EntityAccessControlHandler::access

In my case from the bottom of this stack turned out to be one of the modules that denied access. EntityAccessControlHandler::access method calls ModuleHandler::invokeAll to query the modules if they will allow access. Let’s see that Drupal method in version 8.3.x:

public function invokeAll($hook, array $args = []) {
$return = [];
$implementations = $this->getImplementations($hook);
foreach ($implementations as $module) {
$function = $module . ‘_’ . $hook;
$result = call_user_func_array($function, $args);
if (isset($result) && is_array($result)) {
$return = NestedArray::mergeDeep($return, $result);
}
elseif (isset($result)) {
$return[] = $result;
}
}

return $return;
}

As we can see it calls a hook, and passes the arguments that go into the method. The hooks are the following typically:

entity_access
node_access

The arguments are the following:

[ $entity, $operation, $account ]

Operations in case of access can be the following:

create
read
update
delete

Using these information we can filter the calls and list which module(s) deny access and then check out what their problem is

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!

Authenticating users against Active Directory with PHP

A co-worker of mine asked how this can be done, since I’ve already had some experience querying AD with Java and PHP. It’s been some time ago so I had to think about a little but then I realized it’s easy. Just use LDAP bind!

Consider the following PHP code snippet:

$ldaphost = ‘ldap://dc.mycompany.local’;
$ldapport = 389;

$user = ‘DOMAIN\user’;
$password = ‘password’;

$ldapconn = @ldap_connect( $ldaphost, $ldapport );
if( $ldapconn )
{

ldap_set_option( $ldapconn, LDAP_OPT_PROTOCOL_VERSION, 3 );
ldap_set_option( $ldapconn, LDAP_OPT_REFERRALS, 0 );

$ok = @ldap_bind( $ldapconn, $user, $password );
if( $ok )
{
ldap_unbind( $ldapconn );
}
else
{
echo ‘Failed to bind to LDAP server:’ . “\n”;
echo ldap_error( $ldapconn ) . “\n”;
}
}
else
{
echo ‘Failed to connect to LDAP server’ . “\n”;
}

It is important to prefix the user’s name with the domain otherwise it won’t accept it and obviously in real life you’d want to use LDAPS and not send the password over the wire in clear text, but the basic idea is the same.

Remote debugging Tomcat7 servlets with Netbeans

At work we still use Tomcat 7 in production and I needed to set up debugging for various development systems. This article shows how to enable Tomcat 7 remote debugging

Enabling Tomcat 7 remote debugging via JDWP

Linux

I use Ubuntu 16.04 LTE so I’ll use that in the example, but other distros will not be that much different, except for the path and (re)starting the service of course.

  • Edit or create the file /usr/share/tomcat7/bin/setenv.sh and put in the following content:

    export JAVA_OPTS=”-Xdebug \
    -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n”

    Note: Obviously if the file already exists and it already has some content, then just add the parameters instead of adding the entire line.

  • Restart Tomcat

    sudo service tomcat7 restart

Windows

  • Go to the Tomcat binary directory, which is by default

    c:\Program Files\Apache Software Foundation\Tomcat 7.0\bin

  • Start the program Tomcat7w.exe
  • Switch to the java tab and add the following lines to the Java options textbox:

    -Xdebug
    -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n

    Note: It is important that each of the parameters should be added on separate lines, and that lines should have no whitespaces in the end!

  • Restarts Tomcat 7

    net stop tomcat7
    net start tomcat7

Attaching Netbeans debugger to Tomcat 7

Now that we have Tomcat running with the remote debugging on we can attach Netbeans to debug.

  • Click debug – attach debugger, a dialog box will appear
  • Select Java Debugger (JPDA) as the Debugger
  • Select SocketAttach as Connector
  • Fill in host / IP address to the host field
  • Fill in port to the Port field, in this example the port is 8787, but obviously it can be any non-taken port
  • Click OK
  • If everything went OK the debugging tab should show up showing the running threads

…and that’s it! Happy bug hunting!

New linter integration plugins for KDevelop

Hi there!
I’ve just moved some linter integration plugins to the KDE infrastructure (scratch repos), therefore making them generally available.
They are fairly simple plugins, all 3 of them are alike in that they just run an external tool, and bring the results (the issues found) into KDevelop’s GUI. The found issues then will be in the problems toolview, in their own separate tab. The tools can check either a single file or all files in the project. You can see the workflow and configuration options in the videos included. There are also user’s manuals and tech manuals in the docs directories of each repo.

kdev-clangcheck
This plugin integrates Clang’s static code analysis feature, providing C/C++ static code analysis.

Git repository:
git://anongit.kde.org/scratch/laszlok/kdev-clangcheck.git

kdev-pylint
This plugin integrates a linter called Pylint, and as the name suggests it’s a Python code analyzer.

Git repository:
git://anongit.kde.org/scratch/laszlok/kdev-pylint.git

kdev-jshint
This plugin integrates a linter called JSHint, and as the name suggests it’s a Javascript code analyzer.

Git repository:
git://anongit.kde.org/scratch/laszlok/kdev-jshint.git

New GUI for kdev-cppcheck

Hi there!

As you all probably know CppCheck is static code analyzer tool for C and C++. KDevelop has a plugin that provides a front-end for it, and the plugin is called kdev-cppcheck.

The good news is I’ve updated it’s GUI and now it uses the KDevelop Problem Checker Framework.

In the past it used to have it’s own toolview, where it showed issues in different formats (flat issue list, grouped by files, grouped by issue severity), based on the settings set in a KCM module.

Here’s a screenshot showing and example of this

20150722_000003008

What I’ve done is break up that KCM module, and create a per project settings window, and a general global settings window. The global settings window allows you to set the location of the cppcheck tool

20150722_000003009

The per project settings window allows one to set the rest: parameters, and what should be checked

20150722_000003010

Also the results area now shown in the problems toolview, just like problems found by the background parser, in it’s own tab.

20150722_000003011

Here’s a video showing the workflow

New GUI for kdev-krazy2

Hi there!

First of all let me introduce some concepts for readers who are unfamilair with them.

What is krayz2?

Krazy2 is a set of code tests (basically static code analysis) for KDE developers.

What is kdev-krazy2?

kdev-krazy is a plugin for KDevelop, that provides a frontend for Krazy2, so it can be run directly from KDevelop. The resulting issues also show up in KDevelop.

What’s changed?

I’ve given some love to this plugin lately: First I ported it to KF5 so it can run in the latest KDevelop. Now I’ve changed it’s GUI so it now uses the new KDevelop Problem Checker Framework.

Up until now the plugin had it’s own toolview. That’s where settings could be changed, analysis started, and that’s where the issues showed up. Let’s see some screenshots!

The first one shows the main KDevelop window, with the plugin loaded, showing the krazy2 toolview docked in the bottom (fairly large picture, feel free to click).

20150720_000002991

Clicking either the “Select paths” or “Select checkers” buttons shows settings dialogs, not surprisingly you can select paths and chekers in them. The next 2 screenshots shows those.

20150720_000002992

20150720_000002993

Finally the result of the analysis is shown in the toolview

20150720_000002994

All this was in the past. Now the settings can be changed in the per project settings window

20150720_000002995

20150720_000002996

The analysis can be started from the Run menu.

20150720_000002997

The results show up in the problems toolview, the same way that problems detected by the background parser, in a separate tab

20150720_000002998

Here’s a video showing how it all works

 

KDevelop Checker Framework – pushed

Hi there!

I’m pleased to announce that the KDevelop Checker Framework has been pushed to the KDevPlatform repository. Here are some details about it:

GUI changes

  • Moved ProblemModel to shell
  • Reworked the Problems toolview. Now it works like this:
    • ProblemModels are added to ProblemModelSet.
    • ProblemReporterFactory makes instances of ProblemsView.
    • ProblemsView takes the models from ProblemModelSet (also subscribes for updates about them, so if one is added or removed it can add/remove their views) and it provides a tabbed widget where the views for them can be added. It creates instances of ProblemTreeView which show the problems in ProblemModel, and adds them to the tabs. Also the tabs shows the number of problems in the ProblemModels.
    • The toolview will only add actions that are supported by the model (for example: filtering, grouping, reparsing, showing imports. Obviously reparsing doesn’t make sense for runtime problem checkers)

See the video:

  • First it shows that the “old” problem reporter still works as intended (which also uses the new code now)
  • Then from 1:07 onward it shows an example problem model/view working with randomly generated test data.
  • It shows the features of the new model(s), that is filtering by files/project and issue severity.
  • It also shows the grouping support (grouping by severity, and path.

ProblemModel details

  • Broke up ProblemModel into 2 parts
    • Base ProblemModel that provides the QAbstractItemModel interface for views and can use various ProblemStores to store problems. By default it uses FilteredProblemStore.
    • ProblemReporterModel is basically the old ProblemModel that grabs problems from DUChain, it’s a subclass of ProblemModel.
  • ProblemStore simply stores problems as a list (well technically it stores them in a tree, but it only has 1 level, so it’s a list). There’s no filtering, no grouping. It’s perfect for ProblemReporterModel since it does filtering itself when grabbing the problems from DUChain.
  • FilteredProblemStore DOES filtering, and grouping itself. It stores problems in a tree (ProblemStoreNode subclasses). The tree structure depends on the grouping method, which is implemented with GroupingStrategy subclasses.
  • Moved WatchedDocumentSet and it’s subclasses from ProblemModel to ProblemStore, as it is really a detail that the model itself doesn’t need, however ProblemStore which stores the problems needs it actually.
  • Created a new Problem class, DetectedProblem and moved both this and the “old” Problem class in under the IProblem interface. The intent here was to create a class with a clear interface for problems, which ProblemStore can simply store. I wanted to eventually clear the problems out of DUChain and replace the “old” Problem class with it. However I realized that it’s not practical because of the “show imports” feature which shows the problems from imported contexts. Unfortunately DUChain is the class that knows those, and it’s way too much work to get it out from it. Not to mention it doesn’t even make sense, since it’s really something that logically belongs there.

Using this new system is fairly straightforward:

All one has to do is instantiate a model, add it to the model set:

KDevelop::ILanguageController *lc =  KDevelop::ICore::self()->languageController();
KDevelop::ProblemModelSet *pms = lc->problemModelSet();
m_model = new KDevelop::ProblemModel(this);
pms->addModel(“Test”, m_model);

Then later inject problems into it:

KDevelop::DetectedProblem *p = new KDevelop::DetectedProblem();
p->setDescription(“Some message”);
p->setFinalLocation(KDevelop::IndexedString(“/just/a/bogus/path/yada.cpp”));
p->setSource(KDevelop::IProblem::Plugin);
p->setSeverity(KDevelop::IProblem::Error);
model->addProblem(KDevelop::IProblem::Ptr(p));

Here’s a class diagram about the relevant classes:

20150714_000002956

kdev-krazy2 ported to KF5

Good news everyone!

The KDevelop frontend for Krazy tools has been ported to KF5, so it now works with the KF5 version of KDevelop.

20150714_000002954