Case-sensitive passwords and @StaticResource

Many years ago I worked for a company providing services for scientists. Sometimes we got trouble tickets regarding authentication, and I’ll never forget this one. The user had really tried everything to log in. We saw his countless tries in the logs after he contacted us for help. We followed up with the user on the phone checking each of the typical errors, caps-lock, keyboard layout, etc, but no success. Fortunately our policy was to auto-generate an initial password, make the user change it on the first log in, and store that encrypted. But we had the initial password, since he hadn’t been able to log in. So we tried it, and it worked without problems. We generated a new password, sent him the registration mail, and asked him to try again. Guess what, no success. But then we realized something, the password hash in his requests didn’t change between his old log in attempts and the new ones. So we asked him if he had entered the same password as before, and he said “yes, it didn’t change”. We double-checked, and the generated password was definitely different from the first one, and we told him, but he said: “No, the website still says: ‘Your password is case-sensitive‘!”.

Variations of this problem is something developers are facing a lot of times. Especially in training situations when you try to keep up with your peers, it’s very easy to simply copy and paste stuff like this and wonder why the icon doesn’t show up:

private static String ICON="path/to/your/icon.png"
Annotations are brilliant for fixing this kind of problem, and they are making a NetBeans Platform developers (and trainers) live so much easier. When I give a NetBeans Platform Workshop we have a lot of tutorials, and way back we spent a *lot* of time fixing Service Registrations in the META-INF/services folder.

Wrong file names, wrong paths inside the file, moved the Service Implementation to another package, even a simple typo will screw up everything, and you have to run the application to find out something is wrong. And it got even worse when it came to examples using layer.xml, where registrations can span multiple screens of XML.

@ServiceProvider and layer-generating Annotations totally fixed that problem. But still we sometimes had these typical String-copy errors:

private static String ICON="path/to/your/icon.png"

But since NB 7.1 there’s also a solution for this. Simply add @StaticResource to your code, and the IDE will clearly point out the problem:

@StaticResource will check for the presence of your resource and warn you if it’s not there. By default it checks for absolute paths in the source path, but there are modifiers to also check relative paths, and analyze the classpath. Really helpful!

Dieser Eintrag wurde in netbeans geschrieben. Link merken.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>