Stan, I did not specifically address some things you wrote, here's my responses to those things: anonymous wrote : All vendors have vendor-specific settings. I'm not aware of anything that keeps you from running fully-portable, spec-compliant applications on JBoss. Do you have an example? It's not that you have vendor-specific settings that keep me from running. It's that the ones you DO have don't seem to have the mojo that other vendors have. For example, other vendors have inverted-classloader hierarchy things that allow you to delegate to the parent AFTER the application's child classloader has the chance to load classes for the app - it allows me to override the parent's classloader and just for my app. You have classloader isolation techniques, but there are a whole boatload of server-supplied libraries that do not appear to be affected by that isolation... IMHO, if you ever find your people saying "just remove the log4j jar from your WAR and it will work" or something like that, you're missing the point of J2EE. The value prop of J2EE is all wrapped up in the classloader controls and (re)deployment. Anytime you cause me grief by saying something like "a local EJB from one EAR can't call another local EJB from another EAR" or "just remove log4j from your WAR and it will work", you're missing the point and limiting the ways I can use JBoss. That all said, vendor deployment descriptors are your escape hatch and your ginsu knife. It's SO EASY for me to add a specific DD to the WAR to get things to work specifically on JBoss only. Sure, it's often a hack, what do I care? It works, moving on. But, it's anywhere from hard-to-impossible for me to do things like "remove jars" because then I have to retest and rejigger my brains to get things working again on every other appserver. Hence, my accusation that JBoss was attempting a lock-in. anonymous wrote : Also, think of it this way. Would you ever bundle your own implementation of JSP with your WAR? You could certainly do so. You could take the Weblogic JSP impl and deploy it on Tomcat. But it wouldn't make much sense since both comply with the same spec. In a JEE5 container, you have the exact same situation with JSF. JSF is now a standard, spec-compliant, service. The problem is just with migration of pre-JEE5 applications. No, I would not bundle JSP with my app because the spec has always said the vendor supplies it. Similarly, if I were writing a JEE5 app, I wouldn't bundle JSF. There is no required migration for me; I should, by the spec language, be able to run unmodified J2EE 1.4 apps on your JEE5 server - which means my bundling an older JSF should be legal. If you are saying we need to migrate, you're essentially ditching backwards compatibility and you should say so someplace and you should puke a huge error if any app with DD's from earlier specs tries to deploy. Which is all probably a really bad thing unless you don't think so. I agree, after thinking about it for a bit, JEE5 is a step in the right direction. It will be good for everyone that the spec maintainers are going through a standardizing effort for many of the java optional libraries. Cheers, gDarius View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041139#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...