Announcement Announcement Module
Collapse

Spring Dynamic Modules forum decommissioned in favor of Eclipse Gemini Blueprint

With the official first release of Eclipse Gemini Blueprint shipped, the migration of the Spring Dynamic Modules code base to the Eclipse Foundation, as part of the Gemini project, has been completed.

As such, this forum has been decommissioned in favour of the Eclipse Gemini forums.
See more
See less
Spring-DM 1.1.0, Seam, Facelets, and Tomcat 6.0.16 Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring-DM 1.1.0, Seam, Facelets, and Tomcat 6.0.16

    I was able to get my Seam webapp working with Spring-DM 1.1.0 and Tomcat 6.0.16, although I had to workaround some issues. Here are the workarounds I made:

    1) The Spring-DM bundle for Tomcat 6.0.16 is missing the classes from the org.apache.tomcat.dbcp package (the Spring-DM bundle for Tomcat 5.5.23 has these classes).

    2) My webapp uses the root context path, which is specified as the empty string ("") for Tomcat (specifying "/" does not work). I wanted to specify an empty Web-ContextPath, but the DefaultContextStrategy throws an Exception in this case. I had to use my own ContextPathStrategy to accept an empty Web-ContextPath.

    3) Also, my webapp specifies its Context in META-INF/context.xml. I had to modify TomcatWarDeployer to use the Context in META-INF/context.xml as follows:

    Code:
        private Context createDefaultContext(String contextPath, String docBase) {
            StandardContext context = new StandardContext();
    
            context.setDocBase(docBase);
            context.setPath(contextPath);
            // ADDED the following two lines
            File configFile = new File(docBase, "META-INF/context.xml");
            if (configFile.exists()) context.setConfigFile(configFile.getAbsolutePath());
    
            ContextConfig config = new ContextConfig();
            context.addLifecycleListener(config);
            return context;
        }
    4) The JSF ConfigureListener was not starting properly. I had to add the following lines to web.xml

    Code:
       <listener>
          <listener-class>com.sun.faces.config.ConfigureListener</listener-class>
        </listener>
    
        <context-param>
          <param-name>com.sun.faces.expressionFactory</param-name>
          <param-value>org.apache.el.ExpressionFactoryImpl</param-value>
        </context-param>
    5) Seam was having problems scanning my webapp for components, so I had to add a custom Scanner and specify it with a property named org.jboss.seam.deployment.scanners.

    6) Also Facelets was having trouble scanning my webapp for tag libraries, so I had to extract all files of the form /META-INF/*taglib.xml, and explicitly add them with the facelets.LIBRARIES context-param in web.xml

    I hope others find this helpful.

  • #2
    Seam 2.0.2 GA

    I forgot to mention this was Seam 2.0.2GA

    Comment


    • #3
      Nice work!

      Comment


      • #4
        ryokota, nice work indeed! Thanks for sharing this with others. Regarding the work arounds:

        1) Spring-DM migrated to BRITS for most of its dependencies. Have you tried using Tomcat 6.x from the SpringSource bundle repository? That one should work out nicely.

        2) I've raised an issue for "/" (OSGI-565)

        4) Interesting - I wonder why you need to specify these. I'll have a look at it.

        6) Have you tried the Faces library in BRITS?

        I'll try to find a slot for trying JSF in OSGi myself and see if there are any improvements that can be made for it inside Spring-DM itself (I can't think of any at this point).

        Comment


        • #5
          Hi Costin,

          1) The Tomcat 6.0.16 library was from BRITS.

          4 and 6) The JSF and facelets libraries were in my WAR. Perhaps if I used the ones from BRITS I wouldn't need those workarounds.

          Thanks for the great work!

          Comment


          • #6
            Hello ryokota,

            I am currently working on a similar setup (Seam 2.0.2.SP1, Facelets 1.1.14, Richfaces 3.2.1.GA and Tomahawk 1.1.7). Like you, I had to supply a custom scanner for Seam components and provide a suitable EL expression factory (org.jboss.el.ExpressionFactoryImpl) in web.xml. Moreover, I had to patch com.sun.facelets.compiler.TagLibraryConfig to look for taglibs in the given bundle resources.

            With this setup, I was able to reduce the necessary jars in WEB-INF/lib to
            • com.springsource.com.sun.facelets
            • javassist
            • jboss-seam
            • jboss-seam-debug
            • jboss-seam-ui
            • richfaces-api
            • richfaces-impl
            • richfaces-ui
            • tomahawk
            • tomahawk-facelets-taglib
            Ideally, it should be possible to include JSF libs as an external dependency but the resolution of taglib files in META-INF proves difficult. Moreover, JSF uses a lot of dynamic class loading which is not really compatible with OSGi.

            My setup is working fine but I would be interested in your solution with respect to necessary libraries in WEB-INF/lib. Maybe it is possible to externalize even more dependencies and reduce the need for hacks/workarounds?

            Comment


            • #7
              Hi alex1002,

              My requirement was that the WAR work in both Spring-DM and in a non-Spring-DM environment, so I did not work too hard to try to move jars out of WEB-INF/lib in the WAR. This led to the aforementioned workarounds.

              Comment


              • #8
                ... ah, I understand. Unfortunately, the workarounds are also necessary in a minimal WAR setup. We probably have to wait for JSF implementations and Seam to support OSGi out of the box.

                Comment

                Working...
                X