This is where I feel the Sun enterprise vision for Java failed. The idea is that application servers only vary by implementation and any Java app can be dropped into any container and “just work”.

If you read their literature from the early days, they also had specific roles called out, like developers who just wrote beans, assemblers who just took beans and assembled them into ejb jar’s and setup deployment descriptors, and of course, system admins who manage the application server itself, which as previously stated, is completely decoupled from the apps within it.

In reality, it never works out that way. There always needs to be something different about the app to deploy it into another container.

Examples:

• Database connection pooling – every app server is different. Some web apps even do it themselves.
• Caching – JBoss in particular has classes within its packages that facilitate cluster-wide cache invalidations. Can’t just drop your code into Jetty anymore.
• Testing – if ops wants to upgrade Tomcat, what needs to be tested? Is it safe? Only engineering can tell and QA can verify.
• Configuration management – because container configuration is not part of the Java EE spec, configuration files are always container-specific. It’s very common for application installers to configure the container for you, by either checking configuration files into source control or writing scripts to update the container’s config files.
• Class paths – where do all of your JAR’s go? I know they say to put everything into WEB-INF/lib and WEB-INF/classes. Hah. What about JDBC driver? Oh yea, that goes under $TOMCAT_HOME/lib. Or $JBOSS_HOME/server/servername/deploy/lib or something like that. Then you upgrade JBoss and now it’s $JBOSS_HOME/standalone/lib. Don’t expect ops to upgrade that without dev. And don’t get me started on log4j classpath issues.
• Containers often have prebuilt ways to solve problems for you, but you sacrifice portability. For example, I often see HTTP compression handled at the container or web server level If, as a developer, you want to enable this, would you setup a servlet filter within your web app for it, or “flip the switch” on your container and/or web server?

My list could go on and on.

I find it stupid and ridiculous to ask for some one with a specific server implementation experience.

Based on my limited experience, our development team is also responsible for the J2EE container. We make sure that the code and server together solve the problem we’re working on. Who else would have such insight as to what tools or frameworks are needed for the code to run effectively? The sysadmin is then responsible for the machine itself and for making the J2EE container play nice with everything else (firewalls, etc.).

What kinds of features exist amongst Java application containers that require such specialized skill?

I think it comes down to frameworks here. A codebase built upon Struts and Hibernate need not care, really, which container it’s running on.

In the end, experience in a specific J2EE container need not matter so long as the application or the frameworks it’s built on handle the differences for you. Yet, even if this is true, experience with that container could still be seen as a plus.

(3+ years developing on JBoss)