Singleton problem

Question

Hi,
I have a Singleton and I want it to behave like this:
First time it's called it must receive a String parameter in the constructor in order to set class variable. Subsequent calls, just return the created instance. Something like this
public class LogParser extends MainParser {
  private static LogParser logParser = null;
  private String pathToLogXmlFile;
  //First time call
  public static LogParser getFirstTimeInstance(String pathToLogXmlFile) {
    if (logParser == null)
      return new LogParser(pathToLogXmlFile);
    else
      return logParser;
  //Subesequent calls use this one
  public static LogParser getInstance() throws WrongInstanceCallException {
    if (logParser == null)
      throw new WrongInstanceCallException() ;
    else
      return logParser;
  }but I don't think this is a good design! Can you give me some notes?
thanks in advance,
Manuel Leiria

Answer 1

try this
package forums;
public class LogParser {
  private static LogParser theInstance = null;
  private String logfilename = null;
  private LogParser(String logfilename) {
    this.logfilename = logfilename;
  public static LogParser getInstance(String logfilename) {
    if (theInstance == null)
      theInstance = new LogParser(logfilename);
    return theInstance;
  public static LogParser getInstance() throws IllegalArgumentException {
    if(theInstance == null) throw new IllegalArgumentException("Use LogParser.getInstance(logfile) to Initialise LogParser");
    return theInstance;
  public String getLogfilename() {
    return this.logfilename;
  public static void main(String[] args) {
    LogParser lOne = LogParser.getInstance("my.log");
    LogParser lTwo = LogParser.getInstance();
    System.out.println(lTwo.getLogfilename());
}... and yeah there really is no way (that I know of) to do this "cleanly"... you're allways gonna be left with an Exception case somewhere... I use an unchecked exception for this, because I believe any "uninitialised" errors should be found in the very first unit test execution... probably before you've even finished programming your program.
keith.