It also sounds like that there are CVS version control files in the deployment. While I cannot think of any security issues with this on a servlet container, there are known problems with this model when doing straight web development.
I can think of two variations to your development process that would address the issue. 1. Do a CVS export of the project you are working on when you're ready to test in a servlet container. This means that you will have to check in potentially buggy code to the CVS server. In a multi-developer environment this may or may not be acceptable. 2. Use a private branch for your changes, then work on that branch (checking in, and exporting). Using branches will keep you from adding potentially broken code to the main line. It's also a great way to try out and abandon new ideas without foregoing the advantages of SCM. I also find that I don't need to run a web application in a servlet container as often if I make use of JUnit, EasyMock (or another mock solution), and the Spring test jars (if I'm working with Spring). The only times I run things in a servlet container are for integration testing and JSP - heavy applications. This is a bit far from the Tomcat core subject, but I agree with Chuck. Set up the correct environment when doing development and testing. This makes software release management and deployment much easier, and you're much less likely to break production environments. just my two cents . . . /mde/ --- On Wed, 5/5/10, Caldarale, Charles R <chuck.caldar...@unisys.com> wrote: > From: Caldarale, Charles R <chuck.caldar...@unisys.com> > Subject: RE: Tomcat 6 error compiling JSPs with nested @include directives > To: "Tomcat Users List" <users@tomcat.apache.org> > Date: Wednesday, May 5, 2010, 6:35 AM > > From: Nuno Faria [mailto:nuno.m.fa...@gmail.com] > > Subject: Re: Tomcat 6 error compiling JSPs with nested > @include > > directives > > > > That would be a pain because I develop and maintain > over 20 apps in a > > CVS system and would force major changes on the dir > estructure for our > > development environments. > > Getting it wrong in your initial setup is not an excuse for > not correcting the problem. Do you want reliable > operation, or just continue to hope that invalid > environments happen not to cause too many problems? > > > I got to this working config > > "Working" would be a relative term here... > > > Would apreciate your comments. > > See the response to your message in the log4j thread. > > - Chuck --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
