7 Replies Latest reply on Oct 9, 2007 4:44 AM by Daniel Kimmig

    Please decouple seam-gen from JBoss

    Daniel Kimmig Newbie

      I was thinking about requesting a feature concerning seam-gen for a long time. That feature would have been to make seam-gen aware of other containers such as Glassfish and more important Tomcat.

      Although I am happy to see that there is work in progress to decouple seam-gen from JBoss AS(*), I think it is quite disappointing that you rule out Tomcat like that. Bringing Tomcat to seam-gen would help Seam adoption much more then Glassfish imho, because the biggest concern about Seam adoption is still the environment restriction it emposes. By aggressively showing RAD with seam-gen on a container like Tomcat, much of the "Do i need to use EJB on one of those huge and complicated appservers?"-FUD could be negated.

      As Michael Yuan pointed out in his blog ( http://www.michaelyuan.com/blog/2007/07/24/seam-20-and-tomcat/ ), there are two ways to use Seam on Tomcat, either with Embedded JBoss MC or without the MC but restricted to Seam POJOs. If that is the case, why is it so hard to ask the user during seam-setup which container he chooses and if he enters Tomcat, then ask which of these two options should be used.

      My concern for this issue relies in the fact that in my company we evaluated Seam and found its features quite nice, especially for a new project that needs JSF components ajaxified with each other. It was great to read about seam-gen, a tool that supposedly should get you started with the project structure and build process. Unfortunately a lot of development effort has been done using Spring/Hibernate on Tomcat during the last years and therefor all of theapplications are hosted on a unique instance of Tomcat.


      I think I am by far not alone with an environment like that. If you want to compete with Spring, you need to be able to live in the same environment that Spring does. This is the only way that you can make developers choose Seam for their next project. Because in real life, no one will port their production applications to a different container/appserver JUST to make the new project executable.


      (*) http://jira.jboss.org/jira/browse/JBSEAM-1619

        • 1. Re: Please decouple seam-gen from JBoss
          Christian Bauer Master

          Less requesting and more contributing, please.

          • 2. Re: Please decouple seam-gen from JBoss
            Pete Muir Master

            As Christian says, this is a great area to contribute back to Seam in. It's not hard at all to ask the user what server he wants to build for (or perhaps better IMO to provide all options in the generated project) - it just needs someone to write up the ant and configuration files :)

            • 3. Re: Please decouple seam-gen from JBoss
              Jacek Zebrowski Newbie

              AFAiK there are eclipse profiles for AS'es other than JBoss - in that case creating eclipse project for seam is possible and quite easy (if i did it anyboty can :) plus it gives you way more flexibility than seam-gen generated structure.

              If there's such need i Can write a tutorial about setting up project in pure eclipse without seam-gen's help.

              • 4. Re: Please decouple seam-gen from JBoss
                Dan Allen Master

                I am going to go out on a limb here and say that Tomcat is what got us in the hot water that is burning our skin today. The whole viewpoint that application servers are big and heavyweight is antiquated. What people don't realize is that Tomcat is more "proprietary" and difficult to use than just using an application server. (Shoot, Glassfish starts nearly as fast as Tomcat these days! - http://raibledesigns.com/rd/entry/glassfish_2_vs_tomcat_6)

                Please don't assume that I am biased towards application servers or I have any investment in them at all. One year ago I would have been the first person to slander application servers. After taking a very extensive look at Seam, I realize that we have painted ourselves into a corner by discarded services like JNDI and JTA and trying to run on pure servlet containers. It is actually harder to go without them.

                While Tomcat support is interesting from an academic perspective, it is simply not that beneficial. Besides, all you have to do to "upgrade" Tomcat to an application server is to dump the embedded JBoss in the global library directory of Tomcat. While on the one had this just turns JBoss inside out, putting Tomcat on top rather than the application server itself, it at least allows you to use the services that are known, supported, and capable.

                All this isn't to say that Seam isn't supporting Tomcat. I think all of the examples run on Tomcat. What I am saying is that frankly I don't think it is the right direction anymore.

                You should really give the Java EE spec another look, especially with Web Beans on the way. Tomcat is just a module, a servlet module. If you want to use Tomcat, just write servlets or Struts apps.

                These opinions are my own. I am not speaking for the Seam developers.

                • 5. Re: Please decouple seam-gen from JBoss
                  Daniel Kimmig Newbie

                  The problem is - I absolutely agree with your opionion *personally*. But that is not making my company/other developer teams just switch our existing hosting servers to new containers.

                  If Seam developers choose to only support JEE containers because of that opinion (that I personally share), then thats fine. But I dont think that advertising "runs on Tomcat" is the right thing do to, if in reality you pursuit a totally different strategy. Again my personal opinion is, that abusing a servlet container for everything is not the best idea in the world.

                  Oh well, although I think that making the existing tools aware of other containers would help Seam adoption, I am happy to at least get Glasshfish support in seam-gen in Seam 2 GA without contributing anything to the project myself.

                  • 6. Re: Please decouple seam-gen from JBoss
                    Dan Allen Master

                    Given that we agree on the general principle, and I have had my chance to voice my rant, let's dig further into the underlying issue.

                    Is putting the JBoss Embedded runtime in Tomcat's classpath an unreasonable request? (this is a real question, not hypothetical)

                    In Seam 1.2.1, it was possible to use the embeddable EJB3 per application (it went in the WAR file). In Seam 2.0, a move was made to the JBoss Embedded runtime. In doing so, the Seam developers drew that conclusion that starting an JBoss Embedded runtime will work if a single WAR file is deployed, but would cause a problem if multiple WAR files tried to use it. It might be possible to get the JBoss Embedded runtime working from within the WAR again, but the limitation of multiple WAR files would remain (without additional work).

                    Let's answer the first question and then figure out where to go next. We should also give instructions for how to use Jetty if we are going to put forth more information/fixes for Tomcat. However, if the answer to the question above is "no", then we should move on to doing the same with Jetty.

                    By the way, a move from Tomcat to JBoss is pretty easy. At my business, we develop on Tomcat/Jetty and then go to production in JBoss (we aren't deploying any Seam apps yet).

                    • 7. Re: Please decouple seam-gen from JBoss
                      Daniel Kimmig Newbie

                      Well, at our company these changes are slowing the adoption of Seam, because I analyzed Seam's Tomcat features during the 1.2.1 times and was happy to see that you would just have to throw some EJB3 jars at it and you could package it as a straight war file. No container changes needed, nothing.

                      In other words, Seam was not as invasive to Tomcat as it is now.



                      I know it is not a big thing to drop a shared lib in Tomcat, but try to convince some Spring zealots from the early days to modify their beloved production Tomcat. They will rant about how much superior and lightweight their friggin IoC container is. I would not have to listen to that, if I had the ability to just drop them a final war file ;)