hi, >I see the following options: > >a) Application gets packaged as is, in a single ear containing a single war >and jar. >pros - simple build, current architecture >cons - monolithic, not component based, not modular >b) individual war file for each new service >pros - modular, possibly more understandable >cons - will get into dependancies between the modules anyway; may have >issues sharing session objects between wars > >there are probably other options. > >I'd really love some advice from people who have had these problems in the >past. They must be out there! > >thanks very much indeed, >Brian
Assume you have multiple wars. Lets think about the ways we can deploy. 1. As Multiple wars in 1 host. That also means more than 1 context. -- One war might be accessing model casses from other war. Then you decide about plugging all the model classes into 1 big common jar file. Now, that jar should be available to all of your wars. So you will deploy that common.jar to <tomcat>/common/lib OR <tomcat>/endorsed/lib or whatever your container requirements are. In the end what your war files will contain? actions/views? -- How would you forward from one war to another war? Redirects have their own limitations. 2. As 1 war per host. Say A.war under a.dom.com and B.war under b.dom.com. Think about passing control. Struts allows the module functionality so as to help with the development process so that teams/people can divide the modules among themeselves and do parallel development. Generating WARs is the deployment issue. >From my experience, 1 WAR should be generated for 1 business application. Generating wars for each of modules within a business application is not a good idea. my 2 cents <navjot/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
