When using the term 'lifecycle' the Guys at Spring are referring to the construction and destruction of your beans and usually this is in relation to the construction and destruction the Spring Context. There are those occassions when the management of your bean's lifecycle is not a trivial task as there's the need for it to perform its own internal set up. This is usually true when your bean has to interact with an external system including: loading a file, opening a socket or reading some data from the database. It doesn't really matter what it is, to solve this problem all you need is for Spring to call your bean when it's both loading the Spring Context and closing it down.
To that end Spring has three ways of calling your code during initialisation and shut down. These are:
Java tips, observations, bugs and problems from the world of Spring, Weblogic, Oracle, MySQL and many other technologies...
Monday, 28 January 2013
Monday, 21 January 2013
How Do You Organise Maven Sub-Modules?
Being an itinerant programmer one of the things I've noticed over the years is that every project you come across seems to have a slightly different way of organising its Maven modules. There seems to be no conventional way of characterising the contents of a project's sub-modules and not that much discussion on it either. This is strange, as defining the responsibilities of your Maven modules seems to me to be as critical as good class design and coding technique to a project's success. So, in light of this dearth of wisdom, here's my two penneth worth...
Labels:
Configuration,
Convention,
Design,
environment,
Maven
Friday, 11 January 2013
Super Quick Tomcat App Deployment Using a PULL Script
If you managed to read my last blog you'll remember that I demonstrated a simple script for creating a new tomcat installation on a server by splitting the tomcat binaries from the conf files, storing the binaries on a FTP server and the conf files in version control, with a script recombining the two parts.
The next and most obvious improvement to this idea is to create a system for automatically deploying an application once it has compiled and passed its unit tests. There are many ways of doing this,
The next and most obvious improvement to this idea is to create a system for automatically deploying an application once it has compiled and passed its unit tests. There are many ways of doing this,
Wednesday, 2 January 2013
Super Fast Tomcat Installation using FTP and Version Control
When talking about Continuous Delivery one of the tests that both Martin Fowler and Jez Humble often mention is their "flame thrower" test. It goes something like this: Jez will say "How long would it take you to get up and running if Martin and I went into your machine rooms armed with flame throwers and axes and started attacking your servers"?
Labels:
Configuration,
devops,
Installation,
shell script,
Subversion,
SVN,
Tomcat
Subscribe to:
Posts (Atom)