So this weekend I deployed http://www.playerviewer.com (shameless attempt at self promotion!). I've spent a lot of time with EC2 on Sonar / Jenkins boxes, but never deployed over Tomcat on it in production other than small tests.
One thing I found during the inital deployment that really started to be a constant theme...
stop tomcat, download war, delete old war folder, move war, start tomcat.
This started to become a pain, so I ended up just using a shell script.
So the maven process in my pom is to move my war to a directory, that then gets uploaded to http://www.mysite.com/deploy/ROOT.war and my shell script does the rest.
There are probably much nicer ways to do this such as using ant to ftp the script to the location for the shell script to download it, but it's not really that important.
Also - all the code from player viewer is available open source here
Thursday, 9 May 2013
Suppose you make a method private in Java, experience tells us this is bread and butter stuff and only methods inside this class can access the private methods. However, in the following example I'll show how setting methods as private isn't always safe.
From here, we can see if we had an instantiated User object, we could just call user.getFirstName(); However - what if we wanted to get the password? We can use reflection to access this private method.
This is where the Method object in the Java.lang.reflect package is useful. If I was to reflect this method back into an object, I'm able to set the accessibility of this object.
The accessibility method call is important as it will turn off any encapsulation checks on this method invocation. We can then simply invoke this method as shown below to result in the password being printed out.
This is one of the many reasons why storing your passwords in plain text in a compiled object, even if you make the methods private, is dangerous.