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?
Hi Alec! First, please don't cross-post! Please continue the discussion in the thread in the J2EE forum. Second, besides our "Be Nice" rule, there is only one more thing we'd like to ask you to do: please adjust your display name so that it conforms to our Naming Policy. You can do so in your profile. Thank you very much, and have a nice time at the Ranch!
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
subject: ServiceLocator for multiple JNDI contexts