Just a quick note to self on Spring Security Default Target URLs. In one of my recent projects, I noticed that suddenly my Spring Security based login does not use the specified default target url in the configuration. Instead, it was hitting the root of the application always. This application was working perfectly fine until recently, and default target URL has not been changed since.
The Spring Security definition was:
<security:logout logout-url="/!/signout" logout-success-url="/!/signin" />
After debugging through Spring Security code, I noticed that the defaultTargetURL of AbstractAuthenticationTargetUrlRequestHandler is not set to my value, but it uses the default ‘/’. Then after some digging up, it turned out that I’ve added a new Authentication Success Handler to my definition for a different purpose, and when an authentication-success-handler-ref is present in the configuration, the ‘default-target-url’ element in XML configuration is not used.
To fix this, the solution was to specify the default target URL on my authentication success handler bean as follows.
<property name="defaultTargetUrl" value="/!/" />
The reason behind this is, the value we provide on the XML configuration goes to the default authentication success handler only. When we define our own, that value goes no where, so we need to specify it manually on the bean itself. This ate up about 15 mins of my time, before luckily noticing that the success handler change was the reason.
Two days back, I got my ADSL router fried due to a near field lightening strike, and I had to replace the router. I bought a D-Link DSL 2750u and configured it, my MBA happily connected, and everything was working fine.
This morning, when I woke up, I was in for a surprise, because suddenly my MBA stopped recognising the WiFi Network. It sees all other WiFi networks, connects without any hiccups to those, but not this one. I tried the typical first aids – restarting router, restarting my laptop, no luck. My mobile and other devices can connect to the WiFi network without any problems, but not the Mac Book Air. At random times, MBA sees the WiFi network, but when I try to connect it says ‘A Connection Timeout Has Occurred’ (WTH?).
After few minutes spent on Google, saw that Apple devices are known to have some problems with particular WiFi Channels. I checked the WiFi Channel on my router and saw that it was set to AUTO. I changed it to Channel 6, and voila – the MBA see’s and connects to the WiFi smoothly.
So if you are facing any WiFi issues on your Mac devices, try changing the Wireless Channel. On my D-Link Router, it was found in the Administration Console under Wireless -> Basic Settings.
This is going to be a short post on one of the issues I came across when I was trying to use LinkedIn DustJS on my Mac Book. I was trying out DustJS for one of the new projects I’m working on, and I came across ‘DusterJS’ (https://github.com/dmix/dusterjs/), which is a watcher that could monitor your .dust files and convert them on-the-fly to compiled dust templates. This is a life saver when it comes to developing dust templates, and kudos to the author for writing such a great tool.
Integration Testing is an often overlooked area in enterprise development. This is primarily due to the associated complexities in setting up the necessary infrastructure for an integration test. For applications backed by databases, it’s fairly complicated and time-consuming to setup databases for integration tests, and also to clean those up once test is complete (ex. data files, schemas etc.), to ensure repeatability of tests. While there have been many tools (ex. DBUnit) and mechanisms (ex. rollback after test) to assist in this, the inherent complexity and issues have been there always.
But if you are working with MongoDB, there’s a cool and easy way to do your unit tests, with almost the simplicity of writing a unit test with mocks. With ‘EmbedMongo’, we can easily setup an embedded MongoDB instance for testing, with in-built clean up support once tests are complete. In this article, we will walkthrough an example where EmbedMongo is used with JUnit for integration testing a Repository Implementation.
I’ve been using STS (SpringSource Tool Suite) on OS X Lion for sometime now, and today I realized that it’s getting a bit slow. I thought of tuning the heap size a bit to give it more memory, so I went into the installation to look for eclipse.ini, and there was none. So I googled, and found that STS bundles a ‘sts.ini’ file instead. Unfortunately for me, I wasn’t able to find this one in the folder either! Startled, I tried searching on the directory, etc, but it was not there. After googling around a bit more, I found in Spring Forums that the actual sts.ini file for Mac OS comes inside the application bundle. So if you are using Mac OS, and want to edit the sts.ini file, here are the steps.
- Go to your STS installation, and right-click on STS Application
- Select ‘Show Package Contents’
- A new Finder window will open and show the content of the application bundle. Go to ‘Contents’ directory in this window.
- Inside ‘Contents’, go to ‘MacOS’ directory
In this folder (Contents/MacOS) you will find the actual executable (STS) and the STS.ini file. Do your changes to STS.ini file (ex.changing Xmx) and save it just like you would under Linux / Windows with eclipse.ini / sts.ini.