Hi Darius, I think your beef is really with JEE5 rather than JBoss. JBoss 4.2 is an "almost" JEE5 compliant container. JEE5 requires that JSF 1.2 be fully integrated into the container. The result is that you should no longer bundle a JSF implementation into your WAR.
So to use MyFaces with JBoss 4.2, you would need surgically remove the java.net version of JSF 1.2 that ships with the server. I'm a bit hesitant to provide instructions for that but I might be convinced to do it if customers really want/need it. But I hope you will listen to my arguments and decide if that's what you really want to do. There are compelling advantages to using the implementation that ships with the container. And if you change your WAR to be JEE5 compliant, your application will be more portable going forward. "gDarius" wrote : | | 1) You're squatting on a public namespace - you don't own javax.faces, you own org.jboss. If you want to ship your own mutant faces server-wide, fine, do it, just repackage everything so it pollutes your namespace and not mine. | As I explained above, this is how the spec tells us to do things now. We haven't stepped on the javax.faces namespace. "gDarius" wrote : | 2) You're acting very proprietary. You're not J2EE anymore, now you're J2EE+JBoss Faces+JBoss Log4J+JBoss-whatever-specific-versions-you-bundle-and-force-us-to-use. Stop doing me favors, you're in the wrong. I hereby revoke any JBoss J2EE Certification until further notice. | That's very true. JBoss 4.2 is not really a J2EE container, though it is mostly compliant with J2EE. It's goal is to take a large step toward JEE5 compliance. "gDarius" wrote : | 3) You're attempting to engage in vendor lock-in, plain and simple. I should be able to take my WAR that deploys fine on WebLogic, WebSphere, and Geronimo and deploy it on JBoss with only JBoss vendor deployment descriptor changes. | I notice that you didn't include Glassfish in that list. I think you will have the same problem on any JEE5 server. If not, I'd be very interested in how they handled having two JSF implementations in the same classloader namespace. As for vendor lock-in, JBoss has never tried to do that and we never will. We want you to use our server because it is the best, not because you are forced to. Unfortunately, being spec-compliant with JEE5 does have a few pitfalls. "gDarius" wrote : | But you take away my power in more than just the JSF case to decide what libraries and versions I can use. And, your vendor specific deployment descriptor tweaks for classloader control are toothless!! You are telling me to make a special version of my app, just for JBoss. No, it is not going to happen, I reject your vendor lock-in attempt! | 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? "gDarius" wrote : | Thoughts? Am I way off base? Oh, and by the way, citing JBoss technicalities or idiosyncrasies is no excuse. The other vendors don't share your design issues to such an extent. Tell me how to invert or suppress the appserver classloader so that I can override your JSF libraries, or I will not support deployments to JBoss. | gDarius I don't think you are way off base. You've got a legitimate gripe, but I think you just need to consider that this is a JEE5 migration problem rather than a JBoss problem per se. I don't think there is a classloader solution, but it might be worth investigation. Are you building a product that runs on many app servers? If so, you might want to consider having both a J2EE version and a JEE5 version. There are great advantages to the JEE5 way of doing things. You get all the features of JSF 1.2, JSP 2.1, and JSTL 1.2. Plus, you get things like dependency injection on your managed beans. See http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossWithJSFCDDL. 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. Regards, Stan http://jsf.jboss.org View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040967#4040967 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4040967 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
