Java Reference
In-Depth Information
common one today is where developers take over Java EE
security through the use of JAAS modules rather than relying
on built-in spec compliant application server mechanisms for
authentication and authorization. Be very wary of going
beyond the authentication mechanisms provided by the Java
EE specification. This can be a major source of security holes
and vendor compatibility problems. Likewise, rely on the
authorization mechanisms provided by the servlet and EJB
specs, and where you need to go beyond them, make sure you
use the spec's APIs (such as getCallerPrincipal()) as the basis
for your implementation. This way you will be able to
leverage the vendor-provided strong security infrastructure
and, where business needs require, support more complex
authorization rules.
Other common problems include using persistence
mechanisms that are not tied into the Java EE spec (making
transaction management difficult), relying on inappropriate
Java Standard Edition facilities (like threading or singletons)
within your Java EE programs, and "rolling your own"
solutions for program-to-program communication instead of
staying within supported mechanisms like Java 2 Connectors,
JMS, or Web services. Such design choices cause no end of
difficulty when moving from one Java EE compliant server to
another, or even when moving to new versions of the same
server. Using elements outside of Java EE often causes subtle
portability problems. The only time you should ever deviate
from a spec is when there is a clear problem that cannot be
addressed within the spec.
Finally, be careful about adopting new technologies too early.
Overzealously adopting a technology before it has been
integrated into the rest of the Java EE specification, or into a
