Don't know how 'definitive' this is, but here are my experiences. Its a bug/feature of jspc, depending on how you look at it. As it loads all relevant jsp files into memory to compile, it only used the file name, not the full path, making the compiler see all your index.jsps as the same, which causes the error. I believe there is a fix for this out there somewhere. I found a pointer to the fix on an Ant message board. I also added functionality to Ant that compiles each jsp in its own memory space, thus working around the bug. Let me know if you can't find the fix (it might already be part of the next Tomcat build) and want to dork around with my effort. The work I did on it was back about 3 months ago, so I don't know what has been done recently.
Chris On Tue, 2003-02-04 at 23:15, Brett Porter wrote: > Hi, > > I'm looking for a definitive answer about JSPC in Tomcat 4.1 and > precompilation. Searching the archives hasn't yielded answers to the > questions I've been curious about. It'd be great to get definitive > answers for the archive, and perhaps a FAQ as it is not covered in > either tomcat-user, the doco, or JGuru. > > Background: In TC3.2.4 I currently precompile all JSPs using the ant > jspc task and the TC3.2 jasper/webserver jars. I then munged the > generated java files into the format required by TC3.2.4 and compiled > them, then renamed them again to match. A little weird, but it worked > since it used a flat directory structure, formatting the filenames > with_002f etc. I dropped this into /WEB-INF/classes/precompiled_jsp and > symlinked it from work/localhost_8080%2Fapps. > > The reason this was necessary was that the server choked under the load > trying to compile the JSPs. There seemed to be no deadlocking so it > would spawn numerous javacs and start swapping, and you get the picture :) > > With TC4.1 I can't take this approach because of the (albeit nicer) > directory approach. However, because of duplicate names and the same > package being used, I will need to compile each java file individually, > complicating the build process considerably. > > BTW, I'm aware of ?jsp_precompile=1 and it's not suitable. > > Here are my questions regarding jspc from ant/cmd line: > 1) is the definitive way to do it supposed to be the web.xml include > method? If so, shouldn't JSP take a web.xml input and output a processed > one? Regardless, doesn't this have negative side effects, like not then > being able to edit the JSPs to make changes? (note that while we > precompile, we may need to change some, and filtering them out would be > a fair nuisance). > 2) is there a way to do what I am looking for above, generating classes > for all JSPs that are not fragments (for static include) which can be > placed in the work dir? Does it have to have the same layout as the > server to work? > 3) what is the reason for the current layout and differences between cmd > line and server compilation? ie. different dirs but same package. > > My desired requirements for JSPC to work would be: > 1) both JSPC and server generate the same java files to the same locations. > 2) javac can be executed on the base directory on **/*.java, and the > resulting classes dropped into the work directory. They would be used as > long as their timestamps were newer than the jsp in question. > > To achieve this, I'd suggest this: > 1) package name is org.apache.jsp.PATH.TO.FILE (substituting/eliminating > special characters - eg WEB-INF -> WEBINF) > 2) class remains myJsp_jsp.java > 3) have TC not only look under work but /WEB-INF/classes to avoid the > symlink (ie if I specified my package as precompiled_jsp I'd get the > result as I have for 3.2.4). > > And a final question: how likely am I to encounter the problems had with > 3.2.4 if I upgrade to 4.1? I believe the jasper2 compiler is designed to > be much more effecient - will it avoid generating the java files more > than once and hence compiling them more than once, instead synchronizing > on the operation? (this is effectively enough, although precompilation > would still be even faster). > > I'd appreciate any responses regarding this, and apologise for the > verbosity level of the email! :) > > Thanks, > Brett > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
