Announcement Announcement Module
Collapse
No announcement yet.
Web Personality Module: no more web.xml? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Web Personality Module: no more web.xml?

    Hello,

    Section in Programmer Guide describes new manifest entries for Web modules but doesn't mention web.xml.
    Does it mean that all configuration like security, filters, servlet mappings must be defined in MANIFEST.MF?
    Did I understand it correctly?

    Also can you specify exact directory structure for Web module please?
    (Guide tells that "Directory structure similar to a standard WAR")

    --
    Olexandr

  • #2
    Web Personality Module: no more web.xml?

    Hello,
    I understand the same as you : no web.xml anymore and all the web configuration stuff in the manifest.
    Concerning the structure of the jars : putting your web ressources (jsp, images, ...) and your java classes at the root of the jar works fine.

    Indeed, i wonder what was wrong with the old web.xml.
    It appears that all the specific manifest headers introduced to support web modules map to an existing element of the web.xml.
    While XML may sometimes be a little verbose, it's more structured and less cryptic and error-prone than a manifest file ... And a good XML tool can help writing it from the DTD/XSD.

    So my question for the SpringSource folks : why did you introduce a new format ?
    It was too JEE-associated ?

    Fabien

    Comment


    • #3
      Web Personality Module: no more web.xml?

      Hi Olexandr,

      > Section in Programmer Guide describes new manifest entries for Web modules
      > but doesn't mention web.xml.

      For web modules, we auto-generate a suitable web.xml with a properly configured DispatcherServlet for your bundle. By "properly configured", I mean that the DispatcherServlet is configured to use the ApplicationContext created by Spring-DM for your bundle (e.g., built using standard Spring-DM semantics for locating your configuration files in /META-INF/spring/*.xml). The same is true for any DelegatingFilterProxy instances you might typically configure for a Spring MVC application. The DelegatingFilterProxy is configured to use the same ApplicationContext created by Spring-DM. The DispatcherServlet and DelegatingFilterProxy are both configurable via Web-* manifest headers as described in the programmer guide.

      Thus, there is no need to configure web.xml manually.

      > Does it mean that all configuration like security, filters, servlet mappings
      > must be defined in MANIFEST.MF?

      Yes, for version 1.0.0.beta1 of the SpringSource Application Platform this is the case.

      > Also can you specify exact directory structure for Web module please?
      > (Guide tells that "Directory structure similar to a standard WAR")

      The structure for a web module is identical to that of a standard Java EE WAR, with the following exceptions:

      - web.xml will be auto-generated based on metadata present in
      /META-INF/MANIFEST.MF. Thus if /WEB-INF/web.xml is present in your
      web module, it will be overwritten at deployment time.
      - classes and libs should be placed in /WEB-INF/classes and /WEB-INF/lib,
      respectively. Thus, you should *not* place any classes or JARs in the
      root of your web module's bundle, as these resources would then be
      available via HTTP requests, which would effectively be a security hole.
      - As the web module passes through the deployment pipeline, its contents
      will be introspected, and any classes or JARs discovered in /WEB-INF/classes
      and /WEB-INF/lib will be automatically added to the Bundle-Classpath of
      your web module before it is installed in the Platform.

      I hope this clears up all of your questions!

      Regards,

      Sam

      Comment


      • #4
        Web Personality Module: no more web.xml?

        Hi Fabien,

        > Concerning the structure of the jars : putting your web ressources (jsp,
        > images, ...) and your java classes at the root of the jar works fine.

        That's mostly correct.

        Web resources such as images, HTML, CSS, JavaScript, etc. should be placed
        in the root of your web module, the same as for a standard Java EE WAR file.

        However, as I mentioned in my previous post, you do *not* want to put your
        classes and JARs in the root. Rather, you should place them in
        /WEB-INF/classes and /WEB-INF/lib, respectively. The same holds true for
        classpath resources (e.g., log4j.properties): they should go in
        /WEB-INF/classes.

        > Indeed, i wonder what was wrong with the old web.xml.

        There's absolutely nothing wrong with web.xml. In fact, we auto-generate
        one for you!

        > It appears that all the specific manifest headers introduced to support web
        > modules map to an existing element of the web.xml.

        That's more or less true, except you might have noticed that you don't need
        to specify the class for the DispatcherServlet and DelegatingFilterProxy.

        > While XML may sometimes be a little verbose, it's more structured and less
        > cryptic and error-prone than a manifest file ... And a good XML tool can help
        > writing it from the DTD/XSD.

        I agree, and we are in fact considering allowing developers to provide a
        version of web.xml that we will then augment with the necessary configuration
        to support hooking up a DispatcherServlet to the ApplicationContext created
        by Spring-DM for your web module.

        > So my question for the SpringSource folks : why did you introduce a new format ?
        > It was too JEE-associated ?

        No, that's definitely not the case. :-p

        The reason we introduced the Web-* manifest headers was to simplify
        configuration of typical Spring MVC based applications.

        I'll be blogging this week on the various deployment and packaging options
        for the S2AP. I'll also be updating the programmer guide with more detail on
        these topics. So stay tuned and keep your comments and recommendations coming!

        Thanks,

        Sam

        Comment


        • #5
          Web Personality Module: no more web.xml?

          Hello Sam,

          Now it is much clearer.

          But if we have such different project structure, what about compatibility with Spring DM web projects?
          For example s2ap admin console (pickupplatform.admin.web-1.0.0.beta.war) is a Spring DM project.

          1. If we want to include it into PAR we have to rework it to Web Personality Module project structure?
          It seems yes, because it has web.xml and applicationContext.xml in WEB-INF, so how it is supposed to be done - do you have project converters?

          2. s2ap eclipse tooling recognizes PAR and Bundle projects and deploy/hot-refresh them.
          Exploded projects are supported so no need to make deployment archives during development.
          Do you plan to make such integration for plain Spring DM projects?

          Thank you for developing great products!

          Olex

          Comment


          • #6
            Web Personality Module: no more web.xml?

            Hi Olex,

            > Now it is much clearer.

            Great. Glad to be of service!

            > But if we have such different project structure, what about compatibility
            > with Spring DM web projects?

            Spring-DM supports standard Java EE WAR deployment. The SpringSource Application Platform also supports the standard WAR format. Thus there is no compatibility issue there.

            On the other hand, the S2AP provides the PAR format as an additional packaging option for an entire application and its constituent bundles. Thus the current web module format typically only makes sense within the scope of a PAR.

            > For example s2ap admin console (pickupplatform.admin.web-1.0.0.beta.war)
            > is a Spring DM project.

            That is partially correct. It looks very much like a Spring-DM supported WAR; however, there are some slight differences. Most notably, there is an OsgiContextLoaderListener configured in web.xml which sets the parent ApplicationContext of the root WebApplicationContext to the application context created for the bundle by Spring-DM. This provides a logical hierarchy of Spring application contexts for your Spring MVC application which is somewhat different than the hierarchy supported by Spring-DM.

            Please note, however, that the use of OsgiContextLoaderListener and the packaging structure of the admin console is subject to change as we gather valuable feedback from users like yourself.

            > 1. If we want to include it into PAR we have to rework it to Web Personality
            > Module project structure?

            No, that's not necessary. S2AP currently supports deploying WARs within a PAR.

            > It seems yes, because it has web.xml and applicationContext.xml in WEB-INF,
            > so how it is supposed to be done - do you have project converters?

            No, we do not have any project converters as this time, but if you feel it would be a good idea, feel free to create a new JIRA issue requesting such a feature from the S2AP Tools here:

            https://issuetracker.springsource.com/secure/CreateIssue!default.jspa

            > 2. s2ap eclipse tooling recognizes PAR and Bundle projects and
            > deploy/hot-refresh them. Exploded projects are supported so no need to make
            > deployment archives during development.
            > Do you plan to make such integration for plain Spring DM projects?

            Since "Spring DM projects" are either standard OSGi bundles or WARs, there is nothing special about their structure, and there should be no problems deploying them to the S2AP. If you run into issues trying to do so, please create a new JIRA issue.

            > Thank you for developing great products!

            You're welcome!

            And keep the comments coming.

            Sam

            Comment


            • #7
              Web Personality Module: no more web.xml?

              Sam,

              As you discourage the use of the OsgiContextLoaderListener as it is subject to change, I went the SpringDM->SpringMVC way.

              I configured my web.xml as described in "8.7. Spring-MVC Integration" of the Spring-DM documentation.
              However I get a class not found on the org.springframework.osgi.web.context.support.OsgiB undleXmlWebApplicationContext

              Searching for it, I could not find it. Is the M2 of SpringDM used by the platform?

              Philippe

              Comment


              • #8
                Web Personality Module: no more web.xml?

                Hi Philippe,

                > As you discourage the use of the OsgiContextLoaderListener as it is subject to change,
                > I went the SpringDM->SpringMVC way.

                I wasn't exactly discouraging use of OsgiContextLoaderListener. Rather I just wanted to point out that this is beta software and can therefore change. However, Spring-DM's web support is also not yet final. So either option you choose is subject to change at this juncture.

                > I configured my web.xml as described in "8.7. Spring-MVC Integration" of the Spring-DM
                > documentation. However I get a class not found on the
                > org.springframework.osgi.web.context.support.OsgiB undleXmlWebApplicationContext
                >
                > Searching for it, I could not find it. Is the M2 of SpringDM used by the platform?

                Yes, version 1.0.0.beta of S2AP is built on Spring-DM 1.1.0.M2A; however, we do not rely on any functionality provided by Spring DM's web support. That's why your bundle could not find Spring-DM's OsgiBundleXmlWebApplicationContext.

                To achieve the same goal with the Platform, you should be able to use the following class as a drop-in replacement:

                com.springsource.platform.web.dm.PlatformOsgiBundl eXmlWebApplicationContext

                Note that in contrast to Spring-DM's OsgiBundleXmlWebApplicationContext, PlatformOsgiBundleXmlWebApplicationContext provides support for correct thread context classloader propagation as well as locating resources within an exploded bundle via Spring's ResourceLoader abstraction.

                Regards,

                Sam

                Comment


                • #9
                  Web Personality Module: no more web.xml?

                  Sam,

                  Thanx, It works, more or less, atleast the context is now started, problem that I now have is the tiles configuration fails, will lookinto that later.

                  Philippe

                  Comment


                  • #10
                    Web Personality Module: no more web.xml?

                    hello all,

                    can anybody pls describe how to configure HttpSessionAttributeListener,HttpSessionActivation Listener and ServletContextListener in MANIFEST.MF

                    thanks

                    Comment


                    • #11
                      Web Personality Module: no more web.xml?

                      Hi Michael,

                      > can anybody pls describe how to configure HttpSessionAttributeListener,
                      > HttpSessionActivationListener and ServletContextListener in MANIFEST.MF

                      There's currently no support for configuring Servlet container listeners via manifest headers. So I've created a JIRA for that here:

                      https://issuetracker.springsource.com/browse/PLATFORM-39

                      Good catch!

                      Thanks,

                      Sam

                      Comment


                      • #12
                        Web Personality Module: no more web.xml?

                        thanks sam,

                        what if i define them in web.xml ...do they get overridden..or are they simply ignored?

                        thx

                        Comment


                        • #13
                          Web Personality Module: no more web.xml?

                          Hi Michael,

                          > what if i define them in web.xml ...do they get overridden..
                          > or are they simply ignored?

                          If you are creating a web module, any existing web.xml will currently be overwritten. Thus, for beta1 and beta2, the only option for configuring web.xml is via the Web-* manifest headers.

                          Note, however, that we are looking into providing support for web.xml "fragments" which would allow you to provide a partially complete web.xml. Such a fragment would then be augmented with elements that are auto-generated from the Web-* manifest headers.

                          We hope to make the fragment support available in the coming weeks. So be on the lookout!

                          - Sam

                          p.s. As an aside, if you consult the newly released Form Tags sample application, you'll see that the Platform also provides support for Standard, Shared Libraries, and Shared Services WAR deployments. Thus you might find one of those a viable interim solution for configuring ServletContextListeners.

                          Comment


                          • #14
                            Web Personality Module: no more web.xml?

                            thank you,

                            as an interim solution i will try to configure the listeners via an 'internal' tld which gets picked up.

                            thx
                            m

                            Comment


                            • #15
                              Web Personality Module: no more web.xml?

                              Update: in case you missed it, beginning with beta4 the S2AP supports a Web-ServletContextListeners manifest header which, as the name implies, allows you to configure ServletContextListeners in a web module's manifest.

                              - Sam

                              Comment

                              Working...
                              X