Service Locator

[roul ravashimka]

Hello Everyone,

We implement a service locator as a singleton with a cache.
cache = Collections.synchronizedMap(new HashMap());
How does it become a singleton?Is it by using a synchronizedMap?
Does the synchronizedMap make it a sigleton?
What about the multiple classloaders in the J2EE container which make it impossible to be a true singleton?
Could anyone offer some help?
best regards,
Roul

[Ilja Preuss]

Originally posted by Roul Ravashimka:
We implement a service locator as a singleton with a cache.
cache = Collections.synchronizedMap(new HashMap());
How does it become a singleton?Is it by using a synchronizedMap?
Does the synchronizedMap make it a sigleton?

No, not at all.
Why do you want to make it a singleton in the first place?

[roul ravashimka]

I'm wrong about:
cache = Collections.synchronizedMap(new HashMap());
would make it a singleton.
In the book J2EE Core Patterns, the say that it is implemented as a singleton. But how do you achieve this?
Is it because you cant say: ServiceLocator sl = new ServiceLocator();
You can only say: ServiceLocator sl = ServiceLocator.getInstance();
Althought they also say that the J2EE container has multiple class loaders, thereby it can't be a singleton.
Why i think it should be a singleton? If it's a singleton, there would be only one instance, so only one cache to be maintained.
If it isn't a singleton, there can be more than one instance, so also more than one cache which needs to be filled up with EJB Home objects,...

[S Manch]

You can make a class singleton by overloading its default constructor to be protected and having a factory class inherit from it. The factory class will have a method that will give you the singleton instance anytime you ask it!
Hope this helps.
sanjay.

[Michael Ernest]

My coffee hasn't sunk in yet, but I think:

public class Singleton
{
   private Singleton single = null;
   private Singleton() {      
   }
   public static Singleton makeMe() {
      if (single == null)
         single = new Singleton();
      return single;
   }
}

would do for starters.
Amend or criticize at will -- still groggy.

[Lasse Koskela]

Or just

public class Singleton
{
   private static final Singleton single = new Singleton();
    private Singleton() {
    }
    public static Singleton getInstance() {
        return single;
    }
}

Anyway, the singleton pattern doesn't strictly say "exactly one instance" but a "known, limited number of instances"...

[Stan James]

Never use that "if null let's create one" code in a multi-threaded or multi-processor environment, even if you learned it from Sun sample code. It's flat broken. Here are a few links if you need convincing: http://www.javaworld.com/javaworld/javaqa/2002-04/01-qa-0412-doublelock.html
This kind of cache doesn't really have to have exactly one instance in the world. One per JVM in a distributed setup is fine, and one or two extras due to class loader quirks wouldn't cause any loss of life. But the cache adds value by sharing cached items with many client objects, and singleton or utility (all static methods & variables) classes are handy ways to do that.
Give some thought as to how caches get loaded. That's frought with nearly as much danger as the singleton pattern itself.
[ April 10, 2004: Message edited by: Stan James ]