Re: practical scenarios

2013-04-17 Thread Mark H. Wood
On Tue, Apr 16, 2013 at 08:25:06PM +0200, Jakub 1983 wrote:
 When is it useful to define context.xml in some other place than at
 /META-INF/context.xml inside the application files ?
 
 When do you usually do it ?
 Is it frequently used ?
 I am not asking about theoretical possibilities, but how are they used in
 practical scenarios.

I almost *always* write a context descriptor to place in
$CATALINA_BASE/conf/Catalina/$HOSTNAME/$CONTEXTNAME.xml, after placing
the app. itself somewhere far from the appBase directory so that the
descriptor won't be munged by Tomcat during deployment.  I am actually
a bit puzzled that it's even *possible* to place the context
descriptor inside the app.

I gather that I am in the minority, in this.  But I feel that the
app., whether packed or unpacked, should be treated as an opaque
object, with deployment configuration data applied from the outside.
I think that muddling the concerns of developers and installers is
asking for trouble.

(I also feel that an app. should be able to function without any
configuration at all, at least to the point of telling me what I
forgot to configure.)

-- 
Mark H. Wood, Lead System Programmer   mw...@iupui.edu
Machines should not be friendly.  Machines should be obedient.


signature.asc
Description: Digital signature


practical scenarios

2013-04-16 Thread Jakub 1983
When is it useful to define context.xml in some other place than at
/META-INF/context.xml inside the application files ?

When do you usually do it ?
Is it frequently used ?
I am not asking about theoretical possibilities, but how are they used in
practical scenarios.

Most common case I encounter is in /META-INF/context.xml inside the
application files.

Similary, do you ofter set explicitly CATALINA_BASE outside of
CATALINA_HOME ?
Most common scenario I see is deploying into
TomcatInstallDir(CATALINA_HOME)/webapps.

When should CATALINA_BASE be defined ?

Is running  each webapp on separate tomcat/jboss instead of running all in
the same tomcat / jboss an antipattern ?

In students handbooks and lectures it was said, that jars, memory,
resources are shared in one tomcat/jboss which is so good.
In practice we have memory leaks and need of restarts, conflicts between
versions of jars and classloaders.
And what are more problems running everything in one tomcat/jboss?
What do you see more ofte, all webapps in one server or each in separate ?

Regards
Jakub

piece of doc concerning context topic

http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Defining_a_context

*Defining a context*

*It is NOT recommended to place Context elements directly in the
server.xml file.* This is because it makes modifying the
*Context*configuration more invasive since the main
conf/server.xml file cannot be reloaded without restarting Tomcat.

Individual *Context* elements may be explicitly defined:

   - In an individual file at /META-INF/context.xml inside the application
   files. Optionally (based on the Host's copyXML attribute) this may be
   copied to $CATALINA_BASE/conf/[enginename]/[hostname]/ and renamed to
   application's base file name plus a .xml extension.
   - In individual files (with a .xml extension) in the
   $CATALINA_BASE/conf/[enginename]/[hostname]/ directory. The context path
   and version will be derived from the base name of the file (the file name
   less the .xml extension). This file will always take precedence over any
   context.xml file packaged in the web application's META-INF directory.
   - Inside a 
Hosthttp://tomcat.apache.org/tomcat-7.0-doc/config/host.htmlelement
in the main
   conf/server.xml.

Default *Context* elements may be defined that apply to multiple web
applications. Configuration for an individual web application will override
anything configured in one of these defaults. Any nested elements, e.g.
Resource elements, that are defined in a default *Context* will be
created once for each *Context* to which the default applies. They will *not
* be shared between *Context* elements.


Re: practical scenarios

2013-04-16 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jakub,

On 4/16/13 2:25 PM, Jakub 1983 wrote:
 When is it useful to define context.xml in some other place than
 at /META-INF/context.xml inside the application files ?
 
 When do you usually do it ? Is it frequently used ? I am not asking
 about theoretical possibilities, but how are they used in practical
 scenarios.

Two reasonably practical scenarios I can think of are:

1. When webapps are untrusted or only partially-trusted.

2. Ops team needs lots of configuration in production that the dev
team doesn't need to worry about.

 Most common case I encounter is in /META-INF/context.xml inside
 the application files.
 
 Similary, do you ofter set explicitly CATALINA_BASE outside of 
 CATALINA_HOME ?

I *always* set it to something different. It makes upgrades (and
rollbacks, if necessary) trivial.

 Most common scenario I see is deploying into 
 TomcatInstallDir(CATALINA_HOME)/webapps.
 
 When should CATALINA_BASE be defined ?

When you want a shared Tomcat install (e.g. multiple JVM setup) or you
want to have the ability to upgrade and downgrade with little
difficulty... just change CATALINA_BASE and re-launch.

 Is running  each webapp on separate tomcat/jboss instead of running
 all in the same tomcat / jboss an antipattern ?

I wouldn't say that, but it depends upon your environment. In
production, we run all apps in separate JVMs because it gives us a
high degree of flexibility (and offers some measure of reliability,
since webapps can't interfere with each other, but we have very stable
webapps so that wouldn't likely be a problem for us in general).

 In students handbooks and lectures it was said, that jars, memory, 
 resources are shared in one tomcat/jboss which is so good.

Disk space is dirt cheap. Memory is fairly cheap (compared to ops and
dev time). You can configure ClassLoaders to load from anywhere.

 In practice we have memory leaks and need of restarts, conflicts
 between versions of jars and classloaders.

Time to fix!

 And what are more problems running everything in one tomcat/jboss?

That's mainly the problem above: memory usage and general stability.
Another consideration is whether all of your webapps have been
fully-tested under certain configurations. We run some webapps on
Tomcat 7 and others on Tomcat 6. We even run under different JVM
configurations (1.5, 1.6, and 1.7).

 What do you see more ofte, all webapps in one server or each in
 separate ?

It always depends upon the environment.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRbZ9nAAoJEBzwKT+lPKRY5NsP/1DWvea3ueiLH623Zr0rVmB+
/7dPqg8B0dRzp5kD2hf3C8AujENfm8Bft+9TLVrTj3FjZ5TQC3v4VPJD8EB1DELl
WTeIWrFu7t9+ZzjGzSjvFTV5jziwW4dUgjH2O8nVitTmbnYqv/QtK4beaN27F0CA
2tExAi+Z1VFTZR9PhYaCUt7ixmm5Tw3ahQl793YpjeBqCucFFNvt2tEpZg9rftpb
GObKiDO63HCobqAn6ECQ2YDmEIJJuLz5cMYuG023E+77vPdkvgnf2MTMQwX2A8rc
WT42jpIoawrJHK5QEGlgsVEm5uKJenX2WZNn0wjeGq/JfN3pzhqPN7iihGuRXLL9
ipJfJbMWVFh4j88g2bXv3/Fu3CieMi6d9PULn9/eZ2y7/fMcl4gdQKz767Bed1LH
lenHmoE/gkYnI2KJOB3qG59e3bPtte83DSlqTgttQnq29zeKVScfVgIi681c0cbH
q/x3WFOs2vjY27+Y+gKg2tZ9ZgtVEn0CX/WlGB5at/SV8M2LKKgVOnHFCipvSK7B
xZGSfGkxZ8FiGB0pSWU2gGtsnN5z2KWM2xl4GX99/tTvkTgzGD6csESLxjCL6wfC
1sSvOx7W8s1MzYIoUSfpZ9h5g8XE3xjKtj+d8GDaFg+gZAoyyMIXz4zi02oRMnz1
qYltop1M8J8PREdJFubS
=UxtZ
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org