Wednesday, November 19, 2014

Installing a JDK on windows without admin rights

Here at the office I do not have admin rights.
This is a pain because I cannot update the JDK to a version I'd like/have to use.
Well there is an option.

Download the desired JDK from the regular location.
Open the executable file using 7-zip or something similar. The executable contains only a single file named tools.zip. Unzip that file to a location where you want the JDK installed and you have write access to, for instance c:\development\jdk-8.20.
This will create the installation structure, although many of the jar file components are still compressed. These must be de compressed using a tool provided with the JDK itself, unpack200, that is found in jre\bin.
Locate all .pack files using dir *.pack /s/b and de-compress each of them using upack200:

c:\development\jdk-8.20\jre\bin\unpack200.exe -v -r path\file.pack path\file.jar.
The '-v' option provides for verbose output and the '-r' option removes the original pack file afterwards.

Tuesday, August 05, 2014

Mocking the InitialContext

Unit testing with JNDI

One of the issue's with unit tests is that it is not always easy to control the java.naming.InitialContext provided to the object under test.
Mock frameworks cannot create mocks for JRE classes like InitialContext, so how can we solve this challenge?

One solution could be to create a simple implementation for the javax.naming.spi.InitialContextFactory that returns a mock implementation provided by mockito. Through configuration, our implementation is then used.

public class InitialContextFactoryMock implements InitialContextFactory {

  private static Context mockContext;

  /**
    * The mockContext is created here to be able to use the {@link Context}
    * mock object while defining the expectations.
    * Remember to call this method each time a new test case is run.
    * 
    * @return a fresh {@link Context} mock.
    */
  public static Context getMockContext() {
    mockContext = mock(Context.class);

    return mockContext;
  }

  /**
    * This factory returns the {@link Context} mock created earlier.
    */
  public Context getInitialContext(Hashtable environment) throws NamingException {
    return mockContext;
  }
}

To use the InitialContextFactoryMock you need to specify it in the jndi.properties:


java.naming.factory.initial=the.mocks.InitialContextFactoryMock

Friday, November 09, 2012

Free IT related ebooks

From a post on the LinkedIn Open Source Group, I've got this link pointing to a lot of free IT related ebooks, without to go through data-harvesting sites: http://cfajohnson.com/computers/pdflinks.shtml?

I hope this is helpfull to anyone else.

Tuesday, April 12, 2011

Fine grained authorization with Spring Security 3

For a project I'm currently working on the authorization requuirements are such that we need method level authorization.
The projects will create a REST service whoes functionality I will not describe here, but it is based on Spring MVC, requires authentication based on Kerberos and user ID/password and fine grained authorization based on roles. The roles are taken from the Active Directory.

Since Spring is already used and because we need two distinct manners for authentication, spring security seems to be the best choice for this.
Using spring security, the authorization checks can be configured using annotations on the MVC controller using @PreAuthorize("hasRole('ROLE_USER')") and the like.

Starting with spring security works like a breeze, until you try to step outside of the boundaries.
Setting up simple authentication based on hard coded user ID's with hard coded password and hard coded roles goes like this:
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xmlns:sec="http://www.springframework.org/schema/security"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
          http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.0.xsd
          http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd
    ">

    <sec:http auto-config="true">
        <sec:intercept-url pattern="/*" access="ROLE_USER" />
    </sec:http>

    <sec:authentication-manager alias="authenticationManager">
        <sec:authentication-provider>
                <sec:user-service>
                    <sec:user authorities="ROLE_USER"
                        name="jim" password="morisson"/>
                    <sec:user authorities="ROLE_USER,ROLE_OPERATOR"
                        name="stevie" password="vaughan"/>
                    <sec:user authorities="ROLE_USER,ROLE_OPERATOR,ROLE_DEPLOYMENT_ENGINEER"
                        name="brian" password="jones"/>
                </sec:user-service>
        </sec:authentication-provider>
    </sec:authentication-manager>
</beans>

According to the documentation, all you need to do to enable the @PreAuthorize annotation is adding <sec:global-method-security pre-post-annotations="enabled"/>
So I did, but the authorization checks did not kick in at all.
I have been struggling with this for a while until I stumbled over this post on stackoverflow. The solution is as simple as it is strange, I only needed to move the line <sec:global-method-security pre-post-annotations="enabled"/> from the security-context.xml to the dispatcher-servlet.xml. Nowhere else can I find this suggestion, even in Peter Mularien's book its written as:
Instructing Spring Security to use method annotations
We'll also need to make a one-time change to dogstore-security.xml, where we've got the rest of our Spring Security configuration. Simply add the following element right before the <http> declaration:

<global-method-security pre-post-annotations="enabled"/>

It seems that the above declaration registers a bean post-processor that is applied to the context in which it is declared, that means that declaring it in the security context, the post-processor is not applied to beans declared in the web context.

Wednesday, February 02, 2011

Create mock objects in spring configuration

In case you ever need to supply a mock object in spring configuration, here's a snippet that does just that:

<!-- Define the Mockito class as factory for creating the mock -->
<bean id="restTemplate" class="org.mockito.Mockito" factory-method="mock">
  <!-- The constructor contains the full name of the class being mocked -->
  <constructor-arg value="org.springframework.web.client.RestTemplate"/>
</bean>


The defined restTemplate bean can be be referenced in other bean definitions, for instance the object under test.

Wednesday, August 11, 2010

How to test a class that directly uses java.rmi.Naming

While in the process of doing a handover of a project, some pieces of the projects source do not comply with the code standard. In this holiday season the original developer wasn't available, so I made my sleeves wet and hands dirty again, and started fixing it.

The major thing the code lacked was a proper unit test with coverage higher than 80%, well it didn't have a unit test at all.
Adding a unit test normally is not a big deal, but in this case, the class, a simple servlet that connects to a remote RMI object and calls a status method on it, directly uses java.rmi.Naming.
java.rmi.Naming is notorious for its static methods, which are hard to mock when unit testing.
There are great products out there, like powermock that can actually mock static methods, but not in system classes.
I could change the servlet code and provide a wrapper around accessing the java.rmi.Naming class, but I didn't want to change the code.

Instead I chose to not mock java.rmi.Naming, but instead just create my own instance:
@BeforeClass
public static void initNamingRegistry() throws RemoteException {
// Create a local registry with an arbitrary port number
rmiRegistry = LocateRegistry.createRegistry(9901);
This registry is alive and kickin' during the execution of my test suite, so I can now register the mock object that implements the remote business interface:
@Before
public void registerRemoteMock() throws Exception {
// Register the mock of the remote business object
rmiRegistry.bind("testName", remoteMock);
}
Then the actual servlet method can bet tested:
@Test
public void testSomeBehaviour()
// Prepare the mocks
when(requestMock.getParameter("name").thenReturn("val");
...
// Call the test method
testObject.doGet(requestMock, responseMock);

// Verify the calls if needed
verify(remoteMock).doIt();
Nice, clean and simple!

Thursday, June 26, 2008

Passed !!

Grade: P
Score: 75
Comment: This report shows the total points that could have been awarded in each section and the actual amount of points you were awarded. This information is provided in order to give you feedback on your relative strengths on a section basis. The maximum number of points you could have received is 100, minimum to pass is 70.

Class Diagram (44 maximum) .......................... 31
Component Diagram (44 maximum) ...................... 32
Sequence/Collaboration Diagrams (12 maximum) ........ 12