We are currently at an impass in regard to configuring our J2EE environments. Essentially we are developing using an app server on each developer desktop, with additional app servers for integration, system testing, staging and production (note: no centralised development server). We have several inter-dependent applications operating within these environments.
We are unable to deploy all required components to each desktop app server as some components depend upon the server environment. Therefore a developer working on their own application needs to perform JNDI lookups against a JNDI naming service other than the container's local service. This means that we need a different IntialContext depending on the particular component being sought.
For example...application_A running on a developer desktop needs to reference certain beans from application_B in a "stable" environment on a seperate container. Each container has a seperate JNDI naming service. Therefore application_A needs to be concurently making JNDI requests against both JNDI naming services.
Our question is: What is the accepted wisdom on configuring an application environment such that components in one container can access multiple InitialContexts? (In a way that won't break as the application code moves through Dev - Integration - Test - Prod...)
Any thoughts greatly appreciated,
Good question. Someone please answer this. "Context" is a very cloudy concept to me.
If I understand your question right, you want to construct multiple initial contexts in a way that won't break your calling code even if it were moved to integration, testing and production servers. If this is correct assumption, then I suggest maintain all the required initialcontexts environment settings in a central location may be some central JNDI (say, "ldap://centraldir:389/o=root"). Maintain an entire table of components->initialcontext settings (probably as a type Collection) under this root context. So now all components would get the root initial context and then would get hold of the table that has the component->initialcontext enviroment settings and would then construct the actual initial context for the naming service on the target app server.
So now since all the initialcontext settings are in a central location, you would have a fairly easy task at administration, while moving the app to integration/staging servers.
I understand, this is a pretty abstract solution. But I believe this can be one of the ways to achieve your kind of functionality. Let me know what are the shortcomings of this approach, if any.
Hope this helps,