JAVA_OPTS

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Start up tomcat using target\tomcat\bin\tomcat.bat start
2. Web application consumes more than the default max heap space.
3. Get OutOfMemoryError
4. Try to increase heap space by setting environment variable
JAVA_OPTS=-Xmx512m
5. Retry, still get the OutOfMemoryError. The tomcat.bat has the clobbered
JAVA_OPTS environment variable on line 43:
set JAVA_OPTS="-Drundir=%WEBAPP_ROOT%"

The way to set this variable (without clobbering user settings) is:
set JAVA_OPTS="-Drundir=%WEBAPP_ROOT% %JAVA_OPTS%"

Furthermore, the user has no way to make corrections to tomcat.bat; this
file gets overwritten (from some unknown location) during each clean build.

User is forced to edit their catalina.bat by hand...

Original issue reported on code.google.com by pokneet...@gmail.com on 7 Apr 2008 at 9:58

[GoogleCodeExporter]

Definitely an issue. I don't like setting global env vars for this stuff. We 
need a
solution that allows modifications to the Tomcat configuration per application. 
Any
ideas?

I was thinking of a tomcat.properties file inside deploy/tomcat/main perhaps...

Original comment by bpontare...@gmail.com on 7 Apr 2008 at 10:19

[GoogleCodeExporter]

We could add a tomcat.properties but it might be a little 'over-engineering' 
it. 
Reason I say that is because it's just for development only.  I'm game for more
discussion around other possible solutions.

Original comment by leafkn...@gmail.com on 9 Apr 2008 at 4:26

[GoogleCodeExporter]

I think jCatapult should get out of the business of starting up the servlet
container. We shouldn't have a startup script at all... it only introduces bugs,
limits the possible runtime environments, and makes it more difficult to support
additional platforms.

Another limitation is that this startup script assumes that you're only be 
running a
single webapp, at http://localhost:8080, with no context path.

My recommendation is this: during the build, fill out the "-Drundir" with an 
absolute
path, and write that into the context.xml. Do not define it using tomcat.bat, 
and get
rid of tomcat.bat, or minimize it to do just one  thing: set CATALINA_BASE.

If they wish to support multiple context paths, developers can write post-deploy
macrodefs to rename the context.xml to say izze.xml, and copy other files in 
there.
Then they can support multiple webapps running.

Another possible post-deploy macrodef could copy the context.xml into an 
external
Tomcat conf directory (perhaps the user wants full control of the Tomcat 
config).

I think it is important to avoid changing standard environment variables like
JAVA_HOME, ANT_HOME, CATALINA_HOME, JAVA_OPTS, CATALINA_OPTS, because developers
expect these to behave in the usual way.

Original comment by pokneet...@gmail.com on 9 Apr 2008 at 5:45

[GoogleCodeExporter]

+0 on possible over-engineering
-1 on not support Tomcat and scripts

@leafknode - If we don't make it project specific it becomes global, which 
could be
painful. But I'm not sure the best way to make it project specific. If you can 
think
of something, let's discuss.

@Pokneetail - There is nothing stopping you from running a JCatapult application
inside your own Tomcat installation with your own configuration. This is how it 
is
deployed to production. Therefore it doesn't make sense to stop providing an
extremely simple mechanism for developers to run the webapp. We will continue to
support Tomcat in the same fashion but need to solve some of these outstanding
issues. The outstanding issues I see are:

- Database ports (maybe)
- Tomcat ports (maybe)
- Memory size 
- Other Java parameters

Original comment by bpontare...@gmail.com on 9 Apr 2008 at 7:30

[GoogleCodeExporter]

Original comment by bpontare...@gmail.com on 9 Apr 2008 at 7:31

• Added labels: Component-Ant, Milestone-1.1, OpSys-All