maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Ewins <Brian.Ew...@btinternet.com>
Subject Re: Newbie question: Current best practice for web apps
Date Thu, 12 Dec 2002 11:52:12 GMT
Age Mooy wrote:
> 
> You can point tomcat at ${maven.build.dir}/${pom.id} in its server.xml
> file and run your webapp from there.
> 
> The only (tiny) problem is that now you have to run war:webapp to deploy
> any changes, even for changed templates, images, etc. I use the maven
> console so running war:webapp takes about 1 second.

I suppose I should mention my tomcat plugin[1] here, posted on this list 
last week. This gives you two more options for getting your webapp onto 
tomcat, using its management interface: 'install' and 'deploy'.

The tomcat:deploy goal uploads the war file to tomcat using a PUT 
request. The war file is then unpacked, and started. This can obviously 
take time on big webapps. You can mitigate this by designing your webapp 
so it doesn't include static content[2].

The other option is tomcat:install. This tells tomcat where to find the 
war file. Tomcat will then run your webapp directly out of the war file 
without moving it or unpacking it (it sets the document base to point at 
your .war file). This is obviously faster than deploying it, but means 
you can't have writable directories in your webapp (I notice Age had a 
'logs' dir in his) - this is a good practice as it means you can safely 
replace the application without losing its data[3].

The main advantage of tomcat:install though is that it is supposed to be 
able to insert extra info in the <Context> for your webapp in 
server.xml. This doesnt matter for lone developers, but in a team 
situation, it means everyone gets the changes from CVS. Unfortunately 
this feature seems a bit flaky to me :)

<opinion>
If you're developing JSPs, Age's solution is far better - both of the 
tomcat goals I've described above will cause all your JSPs to need 
recompilation. If you're mainly developing servlets/filters, or 
otherwise messing with your web.xml, then the tomcat:install is a useful 
alternative[4]. If for some reason you need to work with a remote 
server, then tomcat:deploy is best.
</opinion>

Cheers,
-Baz

[1] There were a couple bugs in the plugin, I've found since. The 'stop' 
goal calls 'start' - doh! Also 'remove' depends on 'war:war', this is 
unnecessary.
[2] This also allows static content to be deployed without bottlenecking 
at the java developers. Recently we made this change to one of our 
webapps, dropping its size from 18Mb to 4Mb (the 4Mb is mainly jars we 
depend on, the other 16Mb came from PDFs, images, etc that were part of 
the site).
[3] NB you can't do an 'install' twice - in emacs I have M-x compile set 
up to do 'maven -Ef project.xml tomcat:remove tomcat:install' to do a 
'reinstall'.
[4] I'm not sure if tomcat:install is better here. Age's solution makes 
each context reloadable to pick up servlet changes. We have many webapps 
we work on for different customers, and going in to server.xml to set 
'reloadable="true"' for each one gets old fast. However I think you can 
make the default context reloadable, in which case only the <Context> 
trick is an improvement over Age's solution; also IIRC with reload=true 
tomcat will still not detect changes to 'web.xml'.


Mime
View raw message