Browsed by
Category: Tools

Apache Shiro part 1 – selecting a Java security framework

Apache Shiro part 1 – selecting a Java security framework

apache sharp logo
What is Shiro?
Apache Shiro is an open source Java security framework which makes authentication, authorization and cryptography very easy to use with a simple and small configuration. It is very portable because of its independence from the used application frameworks and covers all kinds of scenarios from console over desktop client to web applications.

Why Shiro?
I searched for a security solution (authorization and authentication) which I plan to reuse in multiple “pet projects” without having to think about the same problem over and over again. My actual project is a web project based on Java EE 7 and has at the moment a JSF/Primefaces frontend. I plan to extend the application with a REST interface and an alternative UI technology for personal testing/learning and research purposes. Maybe there will also be an iOS app later on which should use the then existent REST endpoint. With that in mind I need a flexible framework to support securing JAX-RS endpoints as well as my actual JSF UI.
I previously had some experience with the Java EE standard solution JAAS as well as the JBoss project Picketlink. Additional to that I’ve worked in projects using Spring Security (but had not much to do with it) which seems to be the industry standard nowadays but besides that I did a little research about possible alternatives I wasn’t aware of and came up with Apache Shiro and Keycloak.
This four/five tools and frameworks were the solutions I considered and researched which would be the best fit for me.

Read More Read More

Find and kill a process on a specific port (lsof)

Find and kill a process on a specific port (lsof)

terminal-app
You might all have experienced the situation when you want to start a server either from within your IDE or via the terminal to only get the error that the “port is already in use” and the startup is aborted. This is mostly caused by aborting the server or a crash of the IDE which started it and not terminating it properly. When using macOS (or any other BSD or a Linux) there is a simple solution for this.

For such purposes macOS comes with the “lsof” command which stands for “list open files”. Its purpose is to show who is using a specific file or in our case who is using a specific port. After identifying the process it is easy to terminate it using the “kill” command.

Read More Read More

Solution for the IntelliJ issue on macOS Sierra

Solution for the IntelliJ issue on macOS Sierra

intellij-idea
Jetbrains has come up with a solution for the scrolling problem with IntelliJ IDEA based IDEs under macOS Sierra. They released a modified JDK8 which hast to be set as boot JDK for IntelliJ. You can download the JDK here.
For setting it as the boot JDK you need to got to action menu. This is reached under macOS by pressing ⌘ + ⇧ + a (in other words cmd + shift + a) buttons and entering in the search box the term “switch IDE boot JDK”.
intellij-switch-jdk
The new JDK will be part of the next stable release of IntelliJ and is actually available as part of the 2016.3 EAP.
As this seems to fix the scrolling issue there are still reports of problems with the context click behavior.

Scrolling issue with macOS Sierra and IntelliJ IDEA [UPDATE]

Scrolling issue with macOS Sierra and IntelliJ IDEA [UPDATE]

intellij-idea
If you rely on IntelliJ (or any other IDE based on the IntelliJ platform like WebStorm i.e.) for your daily work and use a touchpad (no matter if the Macbook internal or the magic trackpad) you should not upgrade to Sierra at the moment. The issue is that the scrolling behavior in IntelliJ is extremely sensitive which makes a controlled scrolling nearly impossible. IntelliJ seems to doesn’t know of a way to fix this at the moment and filed itself a radar at Apples bug tracker. As you can find complains from users of other Apps with the same problem as well (VLC and Minecraft i.e.) it seems plausible that the ball on this is in Apples field.

As Jetbrains obviously have done nothing wrong with its implementation to trigger this issue it would have been a good move from them to address the issue to their customers early (previous to the sierra release) so that they could have waited with the macOS upgrade until the problem is solved. If you are interested you can find a discussion about the problem at their bug tracker.

Not knowing how long it will take Apple or Jetbrains to solve the issue the easy workaround for the users is using a mouse as it affects the trackpad only. I use the magic mouse but every other mouse should work fine, too.

Update 03.10.16

Jetbrains has come up  with a solution for the problem which you can find here

eclipse workspace in use

eclipse workspace in use

eclipse logo

As I’m a huge fan of IntelliJ IDEA I don’t use eclipse very often during the last years but I have a dedicated project where I need to regularly use for creating deployments and connect with some remote test servers. So I have to deal with eclipse and its problems, too. A recurring problem for me with eclipse is that it stumbles upon its own not cleaned up metadata which causes problems that are not obvious to solve at first sight. Most of them are gladly quick to fix if you know what you have to do.

A common problem of that sort is when, after selecting the workspace, eclipse fires up a popup with the message “The default workspace … is in use or cannot be created. Please choose a different one”. Most of the time the workspace is not in use but the problem can be caused by an unexpected closing of eclipse which prevents it from cleaning up its metadata correctly. The solution for this is easy. Just navigate to the workspace folder and delete the .lock file in the hidden .metadata directory..

If you are using a mac like me the easiest way is to do it on the shell because the finder by default doesn’t show hidden folders.

cd ~/yourWorkspaceDirectory/.metadata
rm .lock 

Now eclipse should start with your workspace as expected.