- Using XML for configuration
- Component Configuration in J2EE
- Component Configuration using the Preferences API
- A Common CCI architecture
- Conclusions
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Component Configuration in J2EE
J2EE technologies began using XML configuration files even before the parser was added to the SDK. For this essay, we will use web applications as a representative example. We could equally well have chosen EJB applications--they have a CCI that is equivalent for our purposes.
Web applications keep application configuration in a deployment descriptor 1 named web.xml. The deployment descriptor can be quite substantial and is responsible for:
mapping resource names to servlets, JSPs, and filters
declaring lifecycle listeners
creating application-wide environment values
setting servlet initialization parameters
configuring login and role-based security
The web.xml file has a document type descriptor (DTD). Web containers and tools are encouraged to use this DTD to make sure that the deployment descriptor is structurally correct, and to implement semantic checks as well.
Web applications and CCI lookup
The rules for lookup are simple and complete. There is a one-to-one correspondence between applications and web.xml files, and the web.xml file must be located in the WEB-INF subdirectory of the application. This makes it easy and straightforward to access application setup. On the negative side, there is no standard way to share configuration information across applications, or to configure common libraries that are used by more than one application.
Web applications and CCI scope
The spatial scope of web application configuration is well-defined. The specification documents whether each element applies to the entire application or to a particular named resource such as a servlet, JSP, or filter.
Temporal scope is left up to container vendors. The servlet specification says nothing about when web.xml entries are read, or whether their values are cached. Implementers have a degree of freedom here. In practice, configuration settings are likely to be read once when an application is loaded into the container, and only re-read if the application is shutdown and restarted.
Vendors almost always define their own CCI elements, beyond the standard ones in web.xml. For example, the reference implementation for servlets (Tomcat) stores container-wide settings in server.xml. The specification does not dictate anything about such vendor extensions, and so the rules for spatial and temporal scope are completely ad hoc.
Web applications and CCI metadata
CCI metadata makes it possible to develop generic development and deployment tools. J2EE applications do not expose configuration information through a standard API. However, they do not need to. Since the deployment descriptor has a DTD, and since it lives in a well-known location, it is easy to use the XML tools of your choice to manipulate J2EE deployment descriptors..
This approach is reasonable during development, but is inefficient at runtime. The container must use its own XML parser to read the descriptor. If you then use your own parser to access the descriptor as well, you are doing the same work a second time, wasting processor time and memory. So, for performance reasons it would be nice to have a standard API onto CCI data.
Conclusion: J2EE approach not sufficiently generic
J2EE applications do answer most of the challenges for a CCI: They define the rules for configuration lookup, and they define the spatial scope of configuration settings. There is no standard API for accessing deployment descriptor data, but you can do this yourself since it is XML and lives in a well-known place.
The real problem with using web application configuration as a model for a general CCI is that it is not at all generic. For example, web applications define configuration scopes that are solution domain specific, i.e. web applications and named resources. Although I will not examine them here, EJB and JMS CCIs are similar to web application CCIs and have the essential the same capabilities and drawbacks.
A general purpose model would need to apply to any kind of Java deployment. The Preferences API 2 was designed to be just such a model, so we will look at that next.