11 Replies Latest reply on Mar 14, 2004 10:09 PM by sgwood

    Understanding JSP module changes


      Julien,

      I would like to understand and document on the Wiki the effect of the changes you made to the JSP module. From your CVS checkin:

      Added support for JSP outside of Nukes, basically the WebApplicationEnhancer MBean listen for war deployments and when it finds one with WEB-INF/nukes-web.xml, it modifies the standard context to add the capability to decorate the servlet/jsp with Nukes. But the sessions are not shared because the context does not share same sessions, this only works for web-app declared within the same .war than nukes.


      I looked at the code to try and get a feel for how you need to package and deploy things.

      So a module EAR which uses this approach needs to have a WAR in it.

      Q1. What should the context-root for the WAR in the module EAR be? "/nukes"? "/ModuleName"? "/nukes/ModuleName"?

      Q2. What are valid URLs for the module JSPs? Is the JSP naming space for nukes core and modules flat? ie. if you have a test/test.jsp in a module, and someone puts in http://localhost:8080/nukes/test/test.jsp, what gets hit? The JSP in nukes core or the one in the module? Or is it effected by the module WAR context-root? I would think that is was.


      The WAR needs a nukes-web.xml in the WEB-INF. ie.

      <?xml version="1.0"?>
      <!DOCTYPE nukes-web PUBLIC "-//JBoss//DTD Nukes Web 1.0//EN" "http://www.jboss.org/nukes/nukes-web_1_0.dtd">
      <nukes-web>
       <nukes-mapping>
       <url-pattern>*.jsp</url-pattern>
       <servlet-name>/ModuleServlet</url-pattern>
       </nukes-mapping>
      </nukes-web>
      


      You can have multiple "url-pattern" and "servlet-name" entries. These entries are optional. "/modules/*" and "/themes/*" are automatically mapped.


      You talked about the user session not being shared between different WARs. So in a module JSP, "request.getSession().getAttribute("USER")" will not work, right? Will getApi() still work?

      Thanks for this,


      Sherman

        • 1. Re: Understanding JSP module changes

          here is what I did :

          It is possible now to embed a nukes-web.xml in a war. The goal is to intercept calls made to the war and decorated it with Nukes.

          If a war is deployed, this must be done after nukes.ear is deployed, so it is a good idea to put it in the nukes directory. This is because war are deployed before ear. In the future we will switch nukes.ear to nukes.sar and it will work in the deploy directory.

          It is possible to intercept whatever you want, you have to use the syntax :

          <?xml version="1.0"?>
          <!DOCTYPE nukes-web PUBLIC "-//JBoss//DTD Nukes Web 1.0//EN" "http://www.jboss.org/nukes/nukes-web_1_0.dtd">
          <nukes-web>
           <nukes-mapping>
           <url-pattern>*.jsp</url-pattern>
           <servlet-name>MyServlet</servler-name>
           </nukes-mapping>
          </nukes-web>
          


          The problem is that the sessions are not shared, unless you put that in the same war the Nukes servlet are. This is how JSPWiki is integrated in Nukes.

          In the future, we will use war to have Nukes components with a nukes.xml that will be located in the war. This will allow :


          • a clean separation between resources (pictures, etc...) and code (class files)
          • the possibility to dispatch view to JSP with a request dispatcher, it could be the same for nukes templates, something like :
            page.getRequestDispatcher("/module.tpl/details").include(page);
            



            I am ready to make the changes but I would need some help to morph the existing packages. Of course that would require a good amount of changes in the codebase (deployment stuff mostly).

            Do you think I should add that feature soon and modify all existing stuff, or should we wait until 1.x are done ? Jae, Sherman, I need your position on that.


          • 2. Re: Understanding JSP module changes

            I want to be clear about the extent of the change you are proposing. There are several points where you talk about "in the future", and I am not sure whether that means "now".


            Change the nukes.ear to a nukes.sar

            (Module?) war to have Nukes components with a nukes.xml that will be located in the war


            Having the clean separation of resources and code + being able to dispatch to a JSP "view" are good things.

            In terms of doing the changes now versus waiting until after 1.1 (fixing existing modules) - you have some set of changes in core right now, and they do not effect the existing modules. So my questions are:


            Are there any other changes to the core that need to happen in order to implement the "new" way?

            If there are core changes needed, do those core changes break the existing modules if those modules are not changed as well?

            Is it possible to change a module to the "new" way without requiring them all to change at once?

            Are the changes to a module mechanical (just editing build scripts and config files), or will we really need to change a lot of code and retest?


            If we can do the change incrementally and in a short time period (a week?), then I say let's split the work up and do it against HEAD. Otherwise, we can branch CVS and merge it in later.

            Thoughts?


            Sherman

            • 3. Re: Understanding JSP module changes
              jae77

              before i weigh in on this, what is the overall vision of how themeing and templating?

              ppl can create new themes right now, but there doesn't seem to be an easy way for them to create new .tpl files (if they want to change the overall look and feel and not just colors, etc) to use instead of the "default" set that comes w/ the template.

              are we going to forever support both, or are we eventually going to move to all jsp support and no .tpl files?


              • 4. Re: Understanding JSP module changes
                jae77

                p.s. the new wiki integration rocks!

                • 5. Re: Understanding JSP module changes

                   


                  Change the nukes.ear to a nukes.sar
                  (Module?) war to have Nukes components with a nukes.xml that will be located in the war


                  nukes.ear -> ejbs + sar would become : nukes.sar which contains services (MainMBean, Nukes war enhancer mainly) + ejbs + wars


                  Are there any other changes to the core that need to happen in order to implement the "new" way?

                  If there are core changes needed, do those core changes break the existing modules if those modules are not changed as well?


                  I am not sure of that. On the processing itself I think that would not touch that. The main difference would come from how things are deployed. When a war is loaded, it is examined if it contains a nukes.xml file, when that file is found it loads and creates the components. Of course it is still possible to keep the way we have today in jboss-service.xml.

                  The Page would be transformed in something like request/response to have something similar to servlets and introduce the request dispatcher here.

                  All the unchanged modules would stay how they are. The new ones would have to comply to that. Each component has a generic process method on it and then dispatch to Page page now. So that would not touch the component interface but rather how the component dispatch the call internally. It would be even possible to have both : when an operation is dispatched it looks wether it requires a page or a req/resp and create the adapter accordingly.


                  Is it possible to change a module to the "new" way without requiring them all to change at once?


                  yes it would be a better deployer.


                  Are the changes to a module mechanical (just editing build scripts and config files), or will we really need to change a lot of code and retest?


                  mostly I think


                  If we can do the change incrementally and in a short time period (a week?), then I say let's split the work up and do it against HEAD. Otherwise, we can branch CVS and merge it in later.


                  we can do it for 1.1 I think

                  • 6. Re: Understanding JSP module changes

                     


                    ppl can create new themes right now, but there doesn't seem to be an easy way for them to create new .tpl files (if they want to change the overall look and feel and not just colors, etc) to use instead of the "default" set that comes w/ the template.
                    are we going to forever support both, or are we eventually going to move to all jsp support and no .tpl files?


                    yes we will continue to support .tpl, it would be possible to dispatch to tpl or jsp.

                    we could have a mechanism to override .tpl by storing them in a repository (database) and have the user modify them, or with the exploded war format have the user modify them directly on the disk.

                    by the way with the tpl in wars it would be a good thing to have a thread watching for reloading as it is in jsps.


                    • 7. Re: Understanding JSP module changes
                      jae77

                      i'm all for trying to do this now. adding in easy use of jsps would give some more flexibility to ppl who want to move to templating, instead of having the html embedded in the code. (i know i would rather try to do the news templates as jsps).

                      could we support jsps out of the database in the same way that we would the .tpl files? '

                      my biggest concern out of all of this is ensuring that there is a way for html experts to create new themes and change "look and feel" w/o needing to worry about nukes internals and/or creating a set of .tpls for one module, and a set of jsps for the other.

                      • 8. Re: Understanding JSP module changes


                        Hmmm... jsps in the DB... difficult to work with the recompilation aspect... unless we did something that "checked out" the jsp change in the DB out to the file system to get the recompilation. We could then treat tpls and jsps in the same way - change in the DB forces a check out to the app server deploy area (somewhere) and the thread watching for reloading would do it's thing. Start up of the app server would force a check out of jsps and tpls.

                        • 9. Re: Understanding JSP module changes


                          OK, it looks like a go for 1.1.

                          Julien, could you convert one module over to the new way of doing JSPs, even a test one, so that jae and I can use the same pattern for the rest of the modules?

                          Could this be the start of a test module that exercises all of the core facilities of nukes? We could hit it with httpunit or Jython to drive the traffic through the web server.


                          Sherman

                          • 10. Re: Understanding JSP module changes

                            I did put JSP in DB in the script module. It was very tricky to achieve, mainly because the JSPC programmatic interface is very poor. The files were put in temp and were compiled.

                            It could be possible to compile JSP in memory though (look at http://www.janino.net. This can compile in memory and use a ClassLoader as classpath.

                            For the nukes.xml I will give a try soon in my working copy and if it does not require so much change I will checkin.

                            Stay tuned

                            • 11. Re: Understanding JSP module changes


                              Now that I have got the installer moving inthe right direction, I really want to get the JSP issue sorted out, so that I am pointing my team in the right direction.

                              I have been trying to get a module of ours up and running with JSPs in a WAR in the module EAR. It sort of works, but the context change makes it unusable - you have to log in twice as you go back and forth between the standard modules and the WAR in EAR module. Is there anything we can do to avoid this? Changes in the WebApplicationEnhancer? If we can't, I believe we should have a standard deployment technique for module where their JSPs are installed in the exploded nukes.ear.

                              I am also unclear about the best configuration of the web.xml and the nukes-web.xml, so back to some of my original questions:

                              Q1. What should the context-root for the WAR in the module EAR be? "/nukes"? "/ModuleName"? "/nukes/ModuleName"?

                              Q2. What are valid URLs for the module JSPs? Is the JSP naming space for nukes core and modules flat? ie. if you have a test/test.jsp in a module, and someone puts in http://localhost:8080/nukes/test/test.jsp, what gets hit? The JSP in nukes core or the one in the module? Or is it effected by the module WAR context-root? I would think that is was.


                              Also, in the nukes-web.xml, when would you use anything else apart from:

                              <url-pattern>*.jsp</url-pattern>


                              Any thoughts?


                              Sherman