I was reading some articles about jakarta projects and thinking why are there so many frameworks and still difficult to tie them together. I think that one of the biggest challenges we have is the lack of a common configuration API. We lack a well defined standard and there is no de-facto standard. I could not find any project that is focused on this aspect. While the industry is heavily focused on common API standards, the configuration is killing the componentization and slowling the effort.
What do you think? Is such an API possible? If there was such an API, wouldnt it be such easier to tie in different pieces together? Would it be possible to pick components off the shelf and plug in to build custom projects? If Sun doesn't do anything, should the java community (jakarta, alphaworks, ...) agree on a de-facto standard for mutual benefit?
I agree that a standard configuration API would be very helpful, but I am not sure it will be much help tying pieces together. The API would (at best) define a standard way to define and retrieve configuration values, but could not reasonably define what the configuration values mean.
I think what you really want is a more generalized component standard. J2EE has too many different kinds of components (JavaBeans, EJBs, Servlets, MBeans) used in lots of different circumstances. I have mixed feelings about whether this is good or bad, but some sort of convergence on component standards would go farther toward simplifying integration.
I do agree with you that its not possible to define what the values mean. Yes component standardization has good and bad things of its own. However thats not the issue I was referring to.
The issue I wanted to discuss is just about configuration. For example, JBOSS works with Tomcat. If you want to replace it with some other servlet container, say for example JRun, its difficult because of all kind of configuration issues. If we had a standard format, directory structure, notation and so on, not only would it make it easier for everybody to configure different pieces picked off the shelf but also make it easier for developers to supply different kind of configuration overrides etc.
As per my experience, a lot of post development time is spent in configuration issues during development, testing, installation, production environment etc. If I download any component off sourceforge.net, each one has different configuration structure. Anybody who downloads any component has to first understand the configuration structure before they can configure it. Then you find that the homegrown configuration API has limitations and bugs. Then you have to patch it up and so on.
A major advantage I see is that it makes it possible to write ant tasks to configure components when installed. This would make everything scriptable and hence powerful like UNIX power tools. For example, if you install websphere, even though it is highly configurable, you cannot do it with some script.
I think this is necessary before we can achieve true componentization.