These patterns apply broadly to application architecture.
Reinventing the Wheel
This term doesn't need any description. When developing software, you usually have two choicesbuild on top of an existing technology or start from scratch. While both can be applicable in different situations, it is nevertheless useful to analyze existing technology before reinventing the wheel to develop functionality that already exists and can satisfy the requirements. This saves time, money as well as leveraging knowledge that developers already might have.
This occurs when the software is either partly or wholly dependent on a specific vendor,. One advantage of J2EE is its portability, but it still gives vendors the opportunity to provide rich proprietary features. Assuredly, such features can aid during development, but they can also have a reverse impact at times. One such problem is loss of control. You're probably familiar with the feeling that the feature you need is always six months away. Another such problem is when vendor changes to the product break your software, degrade interoperability, force constant upgrades, etc.
One solution is to provide an isolation layer on top of the proprietary stuff. For example, Commons Logging allows you to plug in any logging framework such as Log4J or Java Logging.
Table 2 lists few antipatterns for common application layers. To obtain a more complete list of antipatterns in each layer, refer to AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis.
Table 2. Common J2EE Antipatterns: The table lists antipatterns commonly found in the various layers of J2EE applications.
||Too much session data
Embedded Navigational Information
||Common Functionality in Every Servlet
Accessing Fine-grained EJB Interfaces
Overloading queues in JMS
||Assuming SOA = Web service
||Hardcoded JNDI lookups
Not leveraging EJB container
The next page of this article describes the antipatterns listed in Table 2 for each application layer.