paul.nowak wrote: Matt, thanks for the comments. I made an error on the version of Plone. It's 2.5 Plone running on Zope 2.9x.
In regards to the additional products, we have a skin installed and we have a product that we had custom developed for us that connects to a PostgreSQL database. We've looked at slow PostgreSQL queries causing problems and have not been able to find an issue. We've also tested for the case where the PostgreSQL server is down and have not been able to create an issue. We therefor...
It's sometimes argued that the Java Community Process's development procedures are secretive and that the general public is excluded from participating. While this may have been the case in the past, it's no longer true. The majority of JCP Expert Groups now do their work in an open and transparent manner, and this mode of operation is becoming increasingly common.
As early as 2004, recognizing the importance of community involvement in the JSR development process, the JCP's Process Document was revised to encourage open communications. We now require that JSR submissions include "a transparency plan, which outlines the tools and techniques that the Spec Lead will use, during the creation and development of the specification, and for communicating the progress within the EG to Community Members, EC Members and the public. The EC will expect the Spec Lead to operate the JSR in accordance with this plan."
Even before transparency was made a requirement, JSR 166: Concurrency Utilities - led by Doug Lea (long-time member of the JCP's Executive Committee) - blazed the trail. Doug had already developed a widely adopted concurrency library through an open source process. When he decided to standardize it through the JCP, he naturally chose to run the JSR as an open source project, with the full and active participation of the public and of future users and implementers of the specification. Doug's commitment to open and transparent development processes paid off, as he explained: "the java.util.concurrent package is better than the package it evolved from by virtue of thousands of e-mail comments/discussions, design and code reviews, systematic tests, and so on. What we have are saner APIs, better specs, better tests, more user experience, more discussion, more code reviews, more design reviews than what we started with."
Since then an increasing number of JSRs have been run in an increasingly open and transparent manner. Common techniques include public mailing lists, the use of blogs and Wikis to keep the broader development community informed and involved, and open source development processes. There are many more "open JSRs" than I can list here (java.net alone hosts about 30 separate JSR projects - here's the complete list of projects), but we can at least consider some examples.