Multiple war files for a single webapp or context

Get Started
1

I have an application that has the following structure


    $TOMCAT_HOME/webapps/myapp
    			|-css
    				|-myapp.css
    			|-js
    				|-myapp.js
    			|-forum
    				|-index.jsp
    				|-list.jsp
    				|-users.jsp
    			|-Articles
    				|-index.jsp
    				|-ListArticles.jsp
    			|-Guestbook
    				|-viewGuestBook.jsp
    				|-AddnewEntry.jsp
    			|-WEB-INF
    				|-classes
    					com
    					 |-myapp
    						|-forum
    							|-DisplayForum.class
    							|-ListUsers.class
    						|-article
    							|-ArticleList.class
    							|-AddArticle.class
    						|-guestbk
    							|-LoadGuestBook.class
    							|-ProcessGuestBook.class

The application is delivered as a war file (i.e. myapp.war) and is deployed into the $TOMCAT_HOME/webapps folder. If any of the files change (either the jsp, css, js or java files) i have to always rebuild the whole war file. This means i deploy every single file on every release.

I am wondering if there is a way to deploy specific areas of the application. I am particularly interested if it is possible to separate the application into multiple war files. i.e. myapp.war, articles.war and forum.war. I would like to still access the application via the same context i.e. http://0.0.0.0/myapp even though multiple war files are used.

Using this approach, i will be able to deliver just the module that was affected by the change. Is this at all possible?

I dont mind having to restart the container after each war file is deployed.

I know that i can deploy the application as individual folder but would prefer to archive each individual module. If it is not possible with War files, is there any other archiving mechanism that would allow me to do the above.

Thanks in advance

2

To answer your question: yes, you can deploy any one (or more) of those files individually, restart the context and see the new content - assuming you have Tomcat setup to explode the war; however, splitting up the different areas into war based modules isn’t going to work because of the way Tomcat handles deploying wars. (step one: delete existing context)

Here’s the thing, you’re obviously not using ANT, which is why you’re noticing that repeatedly compiling, warring, deploying and restarting is a pain.

With a decent ANT project, you can compile, and/or war and/or deploy and/or restart the context and/or restart the server.

While developing I’ll have a little ANT script that simply copies the new and changed files to the server and restarts the context - sure, I could do it myself, but that gets old really quick (as you know).

If you think a non-ANT based approach to this stinks now, imagine doing it with an app comprised of hundreds or thousands of files.

3

Hi rushiku.

Thanks for your response. We are indeed using ANT to build the war file so building it is not the biggest problem i am experiencing. The problem i am having is that there are two teams working on the application. This means that if one team is working in one area of the application and it takes a week to complete the testing, the other team will have to wait for the other to finish before they can release a change related to a different area of the application.

Even though the application source code is managed within CVS, we are still finding it difficult because there is no easy way out. As an example, if Team A is working on a change on the Articles section, Team B who is working on the “Forums” section will have to wait for Team A to make their release before they can make their release.

We did consider branching but found that it also doesnt always work and we end up in the same situation especially if there is a dependency in the modules. I thought that if i could separate the war files, the different teams would in effect be working on different applications.

Thanks

4

I would suggest to have mockups for all dependencies.

continuing your same example.

Team-B who is working on the Forums section can mock up the inputs expected from the Articles (on which Team-1 is working).
By this way at-least Team-B can finish up their coding and take up the next tasks.

Once Team-A and Team-B both finishes their code than they can proceed towards the integration where the mockups are replaced by actual classes, which are already developed by team-B or we can also put up this responsibility to Team-B where they replace the mock-ups with actual classes and test the integrated functionality.

But if by “release” you mean release to production than definitely you will not go to prod with half cooked solutions.

5

Yeah it seems to me this is not a deployment issue it is a programming environment issue. Team A and Team B need to sit down and talk about a reasonable Fixture Jars for each ‘project’ that can make faux object that have reasonable data. Then maybe have that sit outside your project (so it doesn’t need to be rebuilt too). Then when you want to use the local Objects you just import the local package instead?

Food for thought.