Hi there, My question is mostly about J2EE component design. There is a complex distributed J2EE application with multiple JNDI namespaces, running on WebSphere. Web and EJB components use ServiceLocator in order to locate business services. Initially I decided to use a specific ServiceLocator for every component that lives in a separate container, with BaseServiceLocator defining all the common functionality. Another approach I am thinking of is to create a single ServiceLocator that would keep a HashMap of JNDI contexts. The benefit that I see in this way: whenever there is a need in a new JNDI context, you don't need to create a new ServiceLocator. You just add a new naming factory/provider pair into the configuration file and call getInstance(KEY) of the ServiceLocator. ServiceLocator will use the KEY to obtain JNDI properties from the configuration file, check if the HashMap contains a corresponding initial context, and, depending on the result, either return an existing initial context, or create a new one and store it in the HashMap. Perhaps this HashMap has to be synchronized. What do you, dear experts, think about this? Which approach you think is the most appropriate in terms of scalability and performance?
Thank you.<br /> <br />Alec
subject: ServiceLocator for multiple JNDI contexts