subject:"CATALINA

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Neven,

On 11/3/14 6:42 PM, Neven Cvetkovic wrote:
 Vince, the current configuration works great:
 
 1) If you are a newbie administrator you are going to use 
 easy-to-use-newbie-friendly configuration. It will get you
 started, it will get your application working, etc... Great
 starting point.
 
 2) If you are developer (newbie or expert) and using IDE (Eclipse, 
 Netbeans, IntelliJ) - you are going to use out-of-box tomcat
 configuration. Single Tomcat instance, no-split configuration.
 
 3) If you are administrator that is upgrading Tomcat, you will just
 create a process to configure your instance with new Tomcat
 binaries and copy over the configuration file (most of the stuff is
 backwards compatible in server.xml within the point-version) + add
 any shared libraries to new tomcat/lib folder (JDBC drivers,
 etc...). Again, single-tomcat instance, no-split configuration
 necessary. Although, may people do like to split for easier
 upgrades and separation of concerns.
 
 4) If you are administrator that is managing multi-instance
 environment, you can still get away with copying standard
 out-of-box Tomcat directory over and over again, for each instance
 separately. The hassle would be to do the upgrades on many
 instances. That's why we have CATALINA_HOME for shared stuff
 (binaries+libraries) and CATALINA_BASE for instance-specific 
 configuration. And in this case you would know about the split
 directory setup option and would research how to do that
 effectively.
 
 My question is - why do you use CATALINA_BASE if you are using IDE 
 (Netbeans)? If you are developer, there is no need to use split 
 configuration.
 
 
 SLIGHTLY-OFFTOPIC:
 
 Although, I would love to see out-of-box setup for additional
 shared-lib folder, something other than TOMCAT/lib with Tomcat
 default libraries. Essentially, I would love to separate my
 customer shared libraries from Tomcat default libraries. I guess -
 question would be where are CATALINA_HOME/lib JAR files being
 loaded from? Can we add another directory to scan for libraries to
 be loaded? Is that configurable?

I'm not sure about that, but if the Windows installer could ask the
user if they want a unified versus split configuration, that might
be nice. The installer could then ask for the location of
CATALINA_BASE and offer to create it if necessary. That way, users
performing upgrades could specify their existing CATALINA_BASE
during installation and not have to go back and re-configure the
Windows Service. It would also allow newbies to know that there is an
advanced configuration and perhaps go learn about it.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUWPLHAAoJEBzwKT+lPKRYNmsP/3RR7xpKGttbs7iDwAzf29qu
EwmQTJd063qcKiDABAkyFfwMy1IQL2/HMM30SL8XFGKhC0kFJZsr/r6kd/Y60cyN
Q7+7uDNmvTtDvI4/3j2lTZ4e6gXo7UwTECxYcXinbM+eFnwZFH3xy/u1uC7vv4jV
gcJ6TFZInqbArwJGDiCuKsaoPGZe1uqEGhCLJjSAz0Yx3gMZBkhi3wQHIGsZkknA
Y9gVw0XAr3oAZHVZMf0bwP+ASH1RwwmRfn5dTgyxnQlAHiJCuA5AKdPtS0L/mkKj
m0qk4MLx5+yWJw+Zll0qNkjgCVbZZ44qaDPwQiG2IFQjSj2dRU7a8PTtDjkPtklw
SUZN1gqEdozuQPqivePN/QEZWqsnSGUtwRQvfr1cmpi4zcucgS7nyK+HE9ySX9/W
H8y61BsTWRV/HHd/d+72/ZxQWH6qR0RKkRQDdwi116bdYb+gRp5B94l0EQ3MHMvB
UemvCqvG6sxlB4gKdLjBbFYkn8YUjwRTSrQFbOmpGykW3hAbSnC1qHuwUPQ/ZM2T
dqv1cnUn/BCGRUD+0xmiU/8UXim3DAxqaRknwfsWj5Lc5bOkdzWJKvg36fKHI/WD
SB7Pcg9vyaV2NFFZh5kJU1xU4DhJ+ZWHqAOW+zzmB0wXqo+mlafkn3YidtMWRTYJ
CKZvkdKcmf/6rIiIwRMJ
=w+SD
-END PGP SIGNATURE-

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

Re: Separation of CATALINA_HOME and CATALINA_BASE

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Neven,

On 11/3/14 6:58 PM, Neven Cvetkovic wrote:
On Mon, Nov 3, 2014 at 6:42 PM, Neven Cvetkovic
neven.cvetko...@gmail.com wrote:

SLIGHTLY-OFFTOPIC:

Although, I would love to see out-of-box setup for additional
shared-lib folder, something other than TOMCAT/lib with Tomcat
default libraries. Essentially, I would love to separate my
customer shared libraries from Tomcat default libraries. I guess
- question would be where are CATALINA_HOME/lib JAR files being
loaded from? Can we add another directory to scan for libraries
to be loaded? Is that configurable?

I guess, it's easy to add new directories to
TOMCAT/conf/catalina.properties file:

common.loader=
${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar

to now read:

common.loader=
${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar,${catalina.base}/shared,${catalina.base}/shared/*.jar,${catalina.home}/shared,${catalina.home}/shared/*.jar

just use shared.loader, which is I think what you're asking for.
It's blank in a default configuration.

What are you thoughts? Would it make sense to keep a separate
directory for shared libraries? Should we make it default - to
encourage others to create a directory if they want to.

- -1

This is confusing and would be surprising if you hadn't intended to
use this. The shared loader was disabled by default because nobody
could figure out what the heck it was for and basically continually
broke their own configurations using it. So, now, everything goes into
either lib/ or the web application's WEB-INF/lib and everyone seems to
be happy. One can always re-enable the shared loader if you know it
exists, in which case you probably know what it's for and why you'd
use it. (Hint: use of the shared loader almost never makes any sense).

Default behaviour for
org.apache.catalina.startup.ClassLoaderFactory is to validate if
the file exists/isDirectory/isReadable? That might confuse
beginners with a Warning ...

I guess Tomcat philosophy is to keep it simple, and extensible - so
experts that need to customize things they can, and it is simple
and not confusing for beginners.

What are your thoughts?

I like the current default configuration but I'm willing to entertain
other ideas. I just don't like this one in particular (default to
split configuration).

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUWPO/AAoJEBzwKT+lPKRYhzwP/21gMhPUd7yVXzk/ImpkZMjr
chWiBFFXl8NA76onaHSvFEIAbwSYbpTjboCd2QdDu0qIFi/O4cyirnYhHRfPISGb
P+mHu0vg+9Ppze+uk5liQiULutEXdeqt97Sfom/I0j+GJZ2UxqvTGVIrwAa+63Op
7f8yg+wTXWQquz7vTkNwp/fGRBB5EB6ZJetffc0gPrsCG4L8muOobVhgd7wK9Yxf
wkWBSXVYTwgOIzlgdYBV2F92EiDMfPihOHQ+jgDHnxebOFc9jCppYcKa96c1LL36
7bTgdSvWNbxJXODCEBVUkoe2rbAr2u7/ZsRWiSOJlfPEBal9Rno/n3C/O6PAhA8J
xGB9ixtFyry9Z9V5XY+aUgI0+DKgSoddo2REtcuK0/X+mpyfUXB5A2GqNRaWxXSo
3+hHxfuJw8kLBjaWGswqgMhF0XBS07pNr87QDxldaROeg4Ty0apr6NRdkdSJ8eGE
+lvWIC+2dN7ufPo7tt3S0+cCDngvtpPMBdHtp7L1PplN9ilTBmxSYRcl/ZOMaE7J
hwSSsYFWRz/40EcTvkO6FCtiuWFW8490pqUuTvfz+ImO+rzSlAlJ2T0vq63Bbfjp
EwkVMlV1V421cDUI7JhyVsg1qw6lcsrY3wxPxXUpyGWMAUoQaScCcxGc1mN35D2/
5ufXCKK6w1sv89jfm5jg
=LSsh
-END PGP SIGNATURE-

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

Re: Separation of CATALINA_HOME and CATALINA_BASE

2014-11-04 Thread Leo Donahue

On Tue, Nov 4, 2014 at 9:37 AM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Neven,

 On 11/3/14 6:42 PM, Neven Cvetkovic wrote:
  Vince, the current configuration works great:
 
  SLIGHTLY-OFFTOPIC:
 
  Although, I would love to see out-of-box setup for additional
  shared-lib folder, something other than TOMCAT/lib with Tomcat
  default libraries. Essentially, I would love to separate my
  customer shared libraries from Tomcat default libraries. I guess -
  question would be where are CATALINA_HOME/lib JAR files being
  loaded from? Can we add another directory to scan for libraries to
  be loaded? Is that configurable?

 I'm not sure about that, but if the Windows installer could ask the
 user if they want a unified versus split configuration, that might
 be nice. The installer could then ask for the location of
 CATALINA_BASE and offer to create it if necessary. That way, users
 performing upgrades could specify their existing CATALINA_BASE
 during installation and not have to go back and re-configure the
 Windows Service. It would also allow newbies to know that there is an
 advanced configuration and perhaps go learn about it.

 - -chris


The Tomcat zip file distribution could easily do this now. Add a
CATALINA_BASE directory pre-configured with a read-me file that explains to
users they can move this directory elsewhere, and update a property that
points back to the CATALINA_HOME directory wherever they unzipped that.
This would be an easy optional configuration to include for a split
configuration.

Re: Separation of CATALINA_HOME and CATALINA_BASE

2014-11-04 Thread Mark Eggers

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chris,

On 11/3/2014 3:08 PM, Christopher Schultz wrote:
 Mark,
 
 On 11/3/14 5:46 PM, Mark Eggers wrote:
 One of the issues I did run into when using tcnative-1.dll is
 that I got the following error message:
 
 12.0.0.1 is not a recognized command, and Tomcat failed to
 start.
 
 Moving tcnative-1.dll out of the bin directory fixed the
 problem. When I specified JRE_HOME in setenv.bat, that also fixed
 the problem and allowed me to use tcnative-1.dll.
 
 I suspect some brokenness in the way NetBeans is handling the 
 JRE_HOME environment variable, since I do have that set 
 system-wide.
 
 That's weird. It looks like someone a) mistyped 127.0.0.1 for 
 localhost and b) a script isn't working properly.

That should have been 127.0.0.1

 
 Is this Netbeans-only, or does it happen with a stock Tomcat?

It is NetBeans-only. Stock 8.0.14 starts fine using startup.bat from
Windows Explorer.

 
 It's also odd that it has something to do with using tcnative at
 the same time.
 

That was my quick and dirty thought since I did a grep (cygwin) on all
of the files in CATALINA_HOME/bin, and that's the only file that
mentioned 127.0.0.1.

I moved tcnative-1.dll out of the bin directory and Tomcat started
from within NetBeans.

I then added a setenv.bat file to the directory which explicitly sets
JRE_HOME (even though it's set as a global environment variable).
NetBeans was then able to launch Tomcat even with tcnative-1.dll in
the bin directory.

I'll poke around if I have some time. I'll also see if this occurs on
a Linux platform.

 -chris

. . . . just my two cents
/mde/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBAgAGBQJUWPqxAAoJEEFGbsYNeTwtPooH/jpXYxwe5h97IsuI3kZ8Uprw
OC2pTuJI8R95q1nATELEH44uMdWyu9YV6zyT0idkbZmdjU/VeFw7+QrtTop7or4J
4SH3ZTAFcvW4VqaQP3Z24kG1+8T9vpug1RsWnWabh8ioHz6qYKPEgvKhxa+fOopL
gCbzEVObywOS/bRexilbZeJYUmQQOncEeVuqAQMpVqCW2yOf4DLJ+jtb7NVAalj+
H+YhVW8Adtip4DR8Kd/C0hIl5R/Gf8uEQjqlVh0SEPS8GwZFo9QJFhS6XD5Q44XK
0cMx/OHD8I6T/OVBAqND+Wf1KXUTfBnjQF9XeJvgs6MVCgMN2LKeutWxKXs5OpY=
=Qhdj
-END PGP SIGNATURE-

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: Separation of CATALINA_HOME and CATALINA_BASE

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Leo,

On 11/4/14 10:46 AM, Leo Donahue wrote:
 On Tue, Nov 4, 2014 at 9:37 AM, Christopher Schultz  
 ch...@christopherschultz.net wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
 Neven,
 
 On 11/3/14 6:42 PM, Neven Cvetkovic wrote:
 Vince, the current configuration works great:
 
 SLIGHTLY-OFFTOPIC:
 
 Although, I would love to see out-of-box setup for additional 
 shared-lib folder, something other than TOMCAT/lib with Tomcat
  default libraries. Essentially, I would love to separate my 
 customer shared libraries from Tomcat default libraries. I 
 guess - question would be where are CATALINA_HOME/lib JAR
 files being loaded from? Can we add another directory to scan
 for libraries to be loaded? Is that configurable?
 
 I'm not sure about that, but if the Windows installer could ask 
 the user if they want a unified versus split configuration, 
 that might be nice. The installer could then ask for the
 location of CATALINA_BASE and offer to create it if necessary.
 That way, users performing upgrades could specify their
 existing CATALINA_BASE during installation and not have to go
 back and re-configure the Windows Service. It would also allow
 newbies to know that there is an advanced configuration and
 perhaps go learn about it.
 
 - -chris
 
 
 The Tomcat zip file distribution could easily do this now. Add a 
 CATALINA_BASE directory pre-configured with a read-me file that 
 explains to users they can move this directory elsewhere, and 
 update a property that points back to the CATALINA_HOME directory 
 wherever they unzipped that. This would be an easy optional 
 configuration to include for a split configuration.

It already does that, now:

The CATALINA_BASE directory is preconfigured to be set to
CATALINA_HOME, which is auto-detected by catalina.sh (.bat).
CATALINA_BASE contains a readme file (RUNNING.txt) that explains how
to change that default.

I say that with all due snark, but it's really true: what you are
talking about basically exists exactly as you describe.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUWQB0AAoJEBzwKT+lPKRYm5oP/i1vfUFBWIsUmdOxFWIt44fZ
ZL2Rco0+WFoUblC5JVjG+vfkv/ZFwUtJnbWVokm5ZZVtnD9LSwHvimeKMaq/wNSr
5yh+M/7cQXGmLEJV6tFf7eLLgHtEmH4WRgoWs/IJ827crxAjr2ae6w5HegWt8Yo1
r99g0x5ZFhlHBy8F1/xjykcTKZVYN3y7i47bcjgb0PDEC7rHB9RhLgveqwKPUU+x
wDqKCHj6vLomgLL3adbU/kg5CV6UIgRwuD2Y3xuxHG3a4x3MoPfRhgmAzeetvm4i
9JXZGRbJhqs2mVNTBS3Bzwdj2rAF6LIROGwV/V7wqYDqgEIijssHUnY4GLaYbYOa
kw+rpj7ZHfXfvmEFD5bo+7jc7v4Jp4SNQnES1bQJmhCytX/o/a0LjRuJ8H5WkTvA
2SobU1v9TMEtyu1esGjkcsibrCMqxfEmR3K8feKaRks1lCo2nlDKC5LsGrNykfW2
rI74FJyGCFP6sXOqckD6SGlyFXBrY4v6CI4sQc8iAsjPf8uWCyshfu7pWATC5C5g
gr3ibDAQEICZWWlz3dlQuQtuf4sSU+XoLTWwyMls3fPMy/9+4BcvSPdcCmSKbGG2
+F9imb8uhrUOpLEhGo5pFBPx3JpjP0eBm1lU3WM3cWwFFBjBqt4GVBO9wFN9fjDg
G+QWyQxZO/HdUUywyU6Z
=zAEu
-END PGP SIGNATURE-

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

Re: Separation of CATALINA_HOME and CATALINA_BASE

2014-11-04 Thread Leo Donahue

On Tue, Nov 4, 2014 at 10:36 AM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Leo,

 On 11/4/14 10:46 AM, Leo Donahue wrote:
  On Tue, Nov 4, 2014 at 9:37 AM, Christopher Schultz 
  ch...@christopherschultz.net wrote:
 
  -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
  Neven,
 
  On 11/3/14 6:42 PM, Neven Cvetkovic wrote:
  Vince, the current configuration works great:
 
  SLIGHTLY-OFFTOPIC:
 
  Although, I would love to see out-of-box setup for additional
  shared-lib folder, something other than TOMCAT/lib with Tomcat
   default libraries. Essentially, I would love to separate my
  customer shared libraries from Tomcat default libraries. I
  guess - question would be where are CATALINA_HOME/lib JAR
  files being loaded from? Can we add another directory to scan
  for libraries to be loaded? Is that configurable?
 
  I'm not sure about that, but if the Windows installer could ask
  the user if they want a unified versus split configuration,
  that might be nice. The installer could then ask for the
  location of CATALINA_BASE and offer to create it if necessary.
  That way, users performing upgrades could specify their
  existing CATALINA_BASE during installation and not have to go
  back and re-configure the Windows Service. It would also allow
  newbies to know that there is an advanced configuration and
  perhaps go learn about it.
 
  - -chris
 
 
  The Tomcat zip file distribution could easily do this now. Add a
  CATALINA_BASE directory pre-configured with a read-me file that
  explains to users they can move this directory elsewhere, and
  update a property that points back to the CATALINA_HOME directory
  wherever they unzipped that. This would be an easy optional
  configuration to include for a split configuration.

 It already does that, now:

 The CATALINA_BASE directory is preconfigured to be set to
 CATALINA_HOME, which is auto-detected by catalina.sh (.bat).
 CATALINA_BASE contains a readme file (RUNNING.txt) that explains how
 to change that default.

 I say that with all due snark, but it's really true: what you are
 talking about basically exists exactly as you describe.

 - -chris


You are correct (something muffled).

If the Tomcat community wants to promote the concept of running multiple
instances, then what about:

A.  A description of that functionality kind of starts on line 68 in
RUNNING.txt ((3) Configure Environment Variables).  In other words, it's
buried.
B.  That description is aimed at using SCRIPTS not SERVICES to get it
working.
C.  Under Advanced Configuration in RUNNING.txt all newbies really need to
know is the In CATALINA_BASE part, because they will read the In
CATALINA_HOME part and get confused.
D.  Are newbies after this kind of configuration for the thrill of being
able to run multiple instances or for easier upgrades?

My guess is most Tomcat users on Windows don't start their Tomcats with the
scripts, a few do and those few are the ones who benefit from this ability,
in their web app development.  I haven't seen or heard of anyone who has a
shared CATALINA_HOME sitting on a Windows file share where developers are
free to create their own CATALINA_BASE, but I have only worked a few places
in my life.  And, I would wonder how coordinating the conflicting ports
would be resolved as a group.

leo

Re: Separation of CATALINA_HOME and CATALINA_BASE

2014-11-04 Thread Neven Cvetkovic

Thanks Chris!

On Tue, Nov 4, 2014 at 10:41 AM, Christopher Schultz 
ch...@christopherschultz.net wrote:

  I guess, it's easy to add new directories to
  TOMCAT/conf/catalina.properties file:
 
  common.loader=
 
 ${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar
 
 
 
  to now read:
 
  common.loader=
 
 ${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar,${catalina.base}/shared,${catalina.base}/shared/*.jar,${catalina.home}/shared,${catalina.home}/shared/*.jar

 just use shared.loader, which is I think what you're asking for.
 It's blank in a default configuration.


Yes, I missed that one :) that's what I had in mind.


  What are you thoughts? Would it make sense to keep a separate
  directory for shared libraries? Should we make it default - to
  encourage others to create a directory if they want to.

 - -1

This is confusing and would be surprising if you hadn't intended to
 use this. The shared loader was disabled by default because nobody
 could figure out what the heck it was for and basically continually
 broke their own configurations using it. So, now, everything goes into
 either lib/ or the web application's WEB-INF/lib and everyone seems to
 be happy. One can always re-enable the shared loader if you know it
 exists, in which case you probably know what it's for and why you'd
 use it. (Hint: use of the shared loader almost never makes any sense).


Agreed, it might confusing. It's probably better idea to pack up your
libraries with your apps in WEB-INF/lib.

Why do shared loaders almost never make any sense? What kind of problems
did you have with shared.loader?

However, here's an (rare) example where that might be useful:
  - one box with limited memory
  - one tomcat instance hosting X (e.g. 10) applications
  - all applications are using the same large shared libraries - e.g. 200MB
  - you don't want to have a separate libraries for each application (your
PermGen space will grow significantly otherwise)
  - it might make sense to move the shared libraries into shared folder (or
tomcat/lib)

Now, this architecture is probably not the greatest idea. I always strive
for the application/process isolation, i.e.
one-application-per-tomcat-instance - so I can have independent lifecycles
for my apps, but that requires more resources (memory,cpu) or even more
hardware.


 I like the current default configuration but I'm willing to entertain
 other ideas. I just don't like this one in particular (default to
 split configuration).


So, I do agree - keeping it how it is - is probably the best idea. There is
always an option for people that would like to configure that further.

Thanks!
Neven

PS. Apologies for the off-topic diversion :)

Re: Separation of CATALINA_HOME and CATALINA_BASE

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Neven,

On 11/4/14 1:05 PM, Neven Cvetkovic wrote:
Thanks Chris!

On Tue, Nov 4, 2014 at 10:41 AM, Christopher Schultz
ch...@christopherschultz.net wrote:

I guess, it's easy to add new directories to
TOMCAT/conf/catalina.properties file:

common.loader=

${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar

to now read:

common.loader=

${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar,${catalina.base}/shared,${catalina.base}/shared/*.jar,${catalina.home}/shared,${catalina.home}/shared/*.jar

just use shared.loader, which is I think what you're asking for.
It's blank in a default configuration.

Yes, I missed that one :) that's what I had in mind.

What are you thoughts? Would it make sense to keep a separate
directory for shared libraries? Should we make it default - to
encourage others to create a directory if they want to.

- -1

This is confusing and would be surprising if you hadn't intended
to
use this. The shared loader was disabled by default because
nobody could figure out what the heck it was for and basically
continually broke their own configurations using it. So, now,
everything goes into either lib/ or the web application's
WEB-INF/lib and everyone seems to be happy. One can always
re-enable the shared loader if you know it exists, in which case
you probably know what it's for and why you'd use it. (Hint: use
of the shared loader almost never makes any sense).

Agreed, it might confusing. It's probably better idea to pack up
your libraries with your apps in WEB-INF/lib.

Why do shared loaders almost never make any sense? What kind of
problems did you have with shared.loader?

The only use case I've seen in the past for using a shared loader is
when people get paranoid about disk space and want to put all their
libraries under shared so they don't have extra copies of e.g.
Struts, Spring, etc. when all of their web applications depend on the
same set of prerequisites.

Of course, then we get endless questions about why their app A doesn't
work anymore because they have Spring 3.5 installed in their shared
loaded and Spring 4.0 installed in their web application and
everything goes all to hell. Basically, they outsmarted themselves and
the code is punishing them for it.

Tomcat then gets blamed for an inflexible configuration system when
Tomcat's flexibility is what allowed them to set up this foolish
configuration in the first place.

I think most of us are better off without the shared loader.

However, here's an (rare) example where that might be useful: - one
box with limited memory - one tomcat instance hosting X (e.g. 10)
applications - all applications are using the same large shared
libraries - e.g. 200MB - you don't want to have a separate
libraries for each application (your PermGen space will grow
significantly otherwise) - it might make sense to move the shared
libraries into shared folder (or tomcat/lib)

Agreed, but with the caveats indicated above.

Now, this architecture is probably not the greatest idea. I always
strive for the application/process isolation, i.e.
one-application-per-tomcat-instance - so I can have independent
lifecycles for my apps, but that requires more resources
(memory,cpu) or even more hardware.

Exactly: packaging your application as a self-contained unit means
fewer surprises all around.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUWRumAAoJEBzwKT+lPKRY/GYP+wc5EaHui1jmx1JoAtps9Z8W
F51OL86n43SpQYN6kpkr2nsew8vpApPX6MXrC8C2XY7AIGzXdclxTmt6Wcf+Rllj
bVrGFDe+tO7NKS44M4z4ZRRAlg7xVc0i/E9rHMdkxSPatDbsBM6t08R8x5se/l8/
C/iscgqVGXTmvA52c2xBLJmXiwXCDSb24HDji2kUzNo7irlaX4QxpvAWNUoCF566
4/tv4xvOrfDbo4INfQ+QtJbEMdFJNlJ2GtPYBF9jmsO9DGMUJ5PIkd7E7vbDr0Ac
fuKGFEiYpOIKNd9PZ99z/bV+Wo8DIpw5kzAUQArQzXqxq0BvNcErVnY5JM4mAyaE
rt4m8TRPCxgwQIuNk9dO7jG25PhDbzw/RWnoiGbbWrV+uBLwpUMU3htMgXuhuAO1
lHa8GaiRFRFBCBeI1yG8PzZEks9DoB5MCXS1tzBIN855bSL4rgYwAMSeTKTfaxzK
DCUJHcKQ71Bcq1neMVsVv3SAPCo4gsi4JPquhiJLo3WIqSV/MVX9rshRQ83VnrAO
nxobgJFsnXXe8VouPLlR6NyR8w9H6EwoTUM6ARayAUtfSqBaKBym/6Cylc71QnrG
HCCxuey8GP7dt8nnSqTkfthmojgfPZl6cAQ1RV2FRcnHcLMtJgPjGfTxuiXBtg1m
FCGaUtFhBsdmsQpdYLN4
=dNsl
-END PGP SIGNATURE-

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

RE: Separation of CATALINA_HOME and CATALINA_BASE

2014-11-03 Thread vince.webb

On the subject of Newbie-friendly, I think Tomcat would be a whole lot more 
friendly if CATALINA_HOME and CATALINA_BASE were always totally separate with a 
minimum of overlap.

Although I used Tomcat quite a lot years ago I still consider myself a Tomcat 
Newbie, mostly because configuration always took days or weeks longer than is 
reasonable. Now I'm back to Tomcat after years of having it easy using 
GlassFish. The files might be different now but the grief with configuration is 
still the same. 

I've been through numerous configurations with various versions of Tomcat 7 and 
8 the furthest I've got is getting a database connection to work. Now having 
created a minimal CATALINA_BASE I've jumped a few steps back and it won't start.

I am sure many of the problems would evaporate if only there were built in and 
permanent clarity over the separation between CATALINA_HOME and CATALINA_BASE. 

Yes, I've read RUNNING.TXT and I'm left wondering why do I have a catalina 
class not found if all the tomcat jar files are in CATALINA_HOME/lib

Using CATALINA_BASE:   C:\tomcat8catalina_base
Using CATALINA_HOME:   C:\tomcat809
Using CATALINA_TMPDIR: C:\tomcat8catalina_base\temp
Using JRE_HOME:C:\jdk1.7.0_55
Using CLASSPATH:   
C:\tomcat809\bin\bootstrap.jar;C:\tomcat8catalina_base\bin\tomcat-juli.jar
Listening for transport dt_shmem at address: tomcat_shared_memory_id
03-Nov-2014 17:45:50.410 SEVERE [main] 
org.apache.tomcat.util.digester.Digester.startElement Begin event threw 
exception
 java.lang.ClassNotFoundException: 
org.apache.catalina.startup.VersionLoggerListener


All these experiments are done running Tomcat under NetBeans so perhaps part of 
my issue is with NetBeans. The CLASSPATH shown above is a bit on the short 
side, is it meant to be so short ?

Vince


-Original Message-
From: Webb, Vince (TR Technology) 
Sent: 17 October 2014 10:17
To: 'Tomcat Users List'
Subject: RE: Separation of CATALINA_HOME and CATALINA_BASE

I don’t see their separation as being incompatible with running from a default 
shell or batch file.

It already figures out where to use for CATALINA_HOME, the default place for 
CATALINA_BASE could be a standard difference from CATALINA_HOME, for example:
CATALINA_BASE=$CATALINA_HOME/../catalina_base

I imagine this could work OK directly from an extracted tar distribution as it 
does now. 

I don't know how much difficulty this would cause for IDE plugin's, they might 
end up needing less code rather than more.

Vince

-Original Message-
From: Mark Eggers [mailto:its_toas...@yahoo.com.INVALID]
Sent: 16 October 2014 20:07
To: Tomcat Users List
Subject: Re: Separation of CATALINA_HOME and CATALINA_BASE

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Konstantin,

On 10/16/2014 11:52 AM, Konstantin Kolinko wrote:
 2014-10-16 22:11 GMT+04:00  vince.w...@thomsonreuters.com:
 Hello I'm coming back to Tomcat after years using GlassFish. The 
 little that I ever understood of Tomcat 3, 4 and 5 is now decidedly 
 rusty so I've been reading Tomcat 7's RUNNING.txt with interest.
 
 The section under the heading: Advanced Configuration - Multiple 
 Tomcat Instances Looks interesting to me even though I have no desire 
 to run multiple instances.
 
 Configuring CATALINA_HOME and CATALINA_BASE to be separate 
 directories looks to me like such a winning idea that I'm left 
 wondering, why the default TOMCAT installation puts all that stuff in 
 one directory ?
 
 I have not looked to see if Tomcat 8 separates them.
 
 1) The default distributive is friendly to newbies. If you just run 
 startup.sh (startup.bat) it assumes that CATALINA_HOME == 
 CATALINA_BASE == its parent directory and starts successfully.
 
 If you separate home and base you have to pass them as environment 
 variables to the scripts. That requires a bit more of configuration 
 from the users.
 
 2) On productive systems you usually configure CATALINA_BASE once 
 (your site) and install a new CATALINA_HOME with each point release.
 
 Even if some files such as webapps are not used in the home 
 directory in this configuration, it may be useful to have them for 
 reference.
 
 http://tomcat.apache.org/migration.html#Before_upgrading_or_migrating

 
http://tomcat.apache.org/migration-8.html#Upgrading_8.0.x
 
 3) Many 3rd parties (Linux vendors) redistribute Tomcat with separate 
 home and base directories.
 
 Best regards, Konstantin Kolinko

I think that the combined approach is useful in a number of scenarios.

1. Newbie-friendly

Just unzip (untar, install) and go. With the installer I suppose you could have 
it query where CATALINA_BASE and CATALINA_HOME are to be placed, so the 
environment variables are constructed and placed in setenv.(bat/sh).

If you use the archive rather than the installer, it's up to the user to figure 
this out.

2. IDE-friendly

NetBeans works well with the combined approach. It even uses the standard 
manager-script role for deployment.

Eclipse is not quite as nice

Re: Separation of CATALINA_HOME and CATALINA_BASE

2014-11-03 Thread Neven Cvetkovic

Vince,

On Mon, Nov 3, 2014 at 2:38 PM, vince.w...@thomsonreuters.com wrote:

 On the subject of Newbie-friendly, I think Tomcat would be a whole lot
 more friendly if CATALINA_HOME and CATALINA_BASE were always totally
 separate with a minimum of overlap.


Why is that?

I would argue current setup is very simple and newbie-friendly. Most
newbies are going to have a single-instance tomcat running, even developers
in their IDEs (Eclipse, NetBeans, IntelliJ, etc...) would probably start
with a single Tomcat instance.

You want your CATALINA_HOME = CATALINA_BASE in the newbie situation.
Actually you don't even want to advertise the difference to the newbies.
You probably shouldn't even configure CATALINA_HOME/CATALINA_BASE
environment variables, but let the scripts infer from where you are running
them.

Now, once one graduates pass the newbie-friendly - one can start looking
when CATALINA_HOME != CATALINA_BASE is useful. Here are some ideas, why you
would maybe want to separate out CATALINA_HOME and CATALINA_BASE:

a) when you want to make your Tomcat upgrades easier over time, so you just
upgrade your CATALINA_HOME each time and you keep your existing
CATALINA_BASE (instance configuration) directory.

b) multi-instance environment, when you have multiple Tomcat instances
running on the same machine, and you are sick-and-tired of copying entire
tomcat directory for each instance and do the upgrades for each instance
individually

Other than that, I don't see another reason to have CATALINA_HOME and
CATALINA_BASE be any different.



 Although I used Tomcat quite a lot years ago I still consider myself a
 Tomcat Newbie, mostly because configuration always took days or weeks
 longer than is reasonable. Now I'm back to Tomcat after years of having it
 easy using GlassFish. The files might be different now but the grief with
 configuration is still the same.

 I've been through numerous configurations with various versions of Tomcat
 7 and 8 the furthest I've got is getting a database connection to work. Now
 having created a minimal CATALINA_BASE I've jumped a few steps back and it
 won't start.


Exactly my point earlier Vince. You ignore setting up
CATALINA_HOME/CATALINA_BASE, you let the scripts infer that from where it
is being started. And then you just configure your datasource either at the
GlobalNamingResources level (e.g at conf/server.xml) or at the Context
level (e.g. at conf/Catalina/localhost/myapp.xml).


 I am sure many of the problems would evaporate if only there were built in
 and permanent clarity over the separation between CATALINA_HOME and
 CATALINA_BASE.

 Yes, I've read RUNNING.TXT and I'm left wondering why do I have a catalina
 class not found if all the tomcat jar files are in CATALINA_HOME/lib

 Using CATALINA_BASE:   C:\tomcat8catalina_base
 Using CATALINA_HOME:   C:\tomcat809
 Using CATALINA_TMPDIR: C:\tomcat8catalina_base\temp
 Using JRE_HOME:C:\jdk1.7.0_55
 Using CLASSPATH:
  C:\tomcat809\bin\bootstrap.jar;C:\tomcat8catalina_base\bin\tomcat-juli.jar
 Listening for transport dt_shmem at address: tomcat_shared_memory_id
 03-Nov-2014 17:45:50.410 SEVERE [main]
 org.apache.tomcat.util.digester.Digester.startElement Begin event threw
 exception
  java.lang.ClassNotFoundException:
 org.apache.catalina.startup.VersionLoggerListener


 All these experiments are done running Tomcat under NetBeans so perhaps
 part of my issue is with NetBeans. The CLASSPATH shown above is a bit on
 the short side, is it meant to be so short ?


If you are running Tomcat instance in IDE, why do you bother separating out
CATALINA_BASE and CATALINA_HOME? Default unzip and play setup work nicely
in Eclipse and IntelliJ. I have not played with NetBeans as much, but I am
sure it is easy out-of-box setup.

Hope that helps!

Cheers!
Neven

Re: Separation of CATALINA_HOME and CATALINA_BASE

2014-11-03 Thread Mark Thomas

On 03/11/2014 19:38, vince.w...@thomsonreuters.com wrote:

snip/

 Yes, I've read RUNNING.TXT and I'm left wondering why do I have a
 catalina class not found if all the tomcat jar files are in
 CATALINA_HOME/lib

Because you are trying to configure a listener that doesn't exist in the
version of Tomcat you are trying to use. You can't take a config from
one version of Tomcat, apply it to an earlier version and expect it to work.

 Using CATALINA_BASE:   C:\tomcat8catalina_base Using CATALINA_HOME:
 C:\tomcat809 Using CATALINA_TMPDIR: C:\tomcat8catalina_base\temp 
 Using JRE_HOME:C:\jdk1.7.0_55 Using CLASSPATH:
 C:\tomcat809\bin\bootstrap.jar;C:\tomcat8catalina_base\bin\tomcat-juli.jar

 Listening for transport dt_shmem at address: tomcat_shared_memory_id
 03-Nov-2014 17:45:50.410 SEVERE [main]
 org.apache.tomcat.util.digester.Digester.startElement Begin event
 threw exception java.lang.ClassNotFoundException:
 org.apache.catalina.startup.VersionLoggerListener
 
 
 All these experiments are done running Tomcat under NetBeans so
 perhaps part of my issue is with NetBeans. The CLASSPATH shown above
 is a bit on the short side, is it meant to be so short ?

Yes.

Mark

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

Re: Separation of CATALINA_HOME and CATALINA_BASE

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Vince,

On 11/3/14 2:38 PM, vince.w...@thomsonreuters.com wrote:
 On the subject of Newbie-friendly, I think Tomcat would be a 
 whole lot more friendly if CATALINA_HOME and CATALINA_BASE were 
 always totally separate with a minimum of overlap.
 
 Although I used Tomcat quite a lot years ago I still consider 
 myself a Tomcat Newbie, mostly because configuration always took 
 days or weeks longer than is reasonable. Now I'm back to Tomcat 
 after years of having it easy using GlassFish. The files might be 
 different now but the grief with configuration is still the same.
 
 I've been through numerous configurations with various versions of
  Tomcat 7 and 8 the furthest I've got is getting a database 
 connection to work. Now having created a minimal CATALINA_BASE
 I've jumped a few steps back and it won't start.
 
 I am sure many of the problems would evaporate if only there were 
 built in and permanent clarity over the separation between 
 CATALINA_HOME and CATALINA_BASE.

Here's my (simplified) prepare-local-tomcat target from our ant build
scripts. It takes a CATALINA_HOME and builds a CATALINA_BASE from it
and our other revision-controlled configuration files.

app.tomcat-home is CATALINA_HOME
app.home.dir is CATALINA_BASE
app.foo.dir should be obvious from the name/usage
conf.dir is our revision-controlled stuff

  target name=prepare-local-tomcat
mkdir dir=${app.home.dir} /
mkdir dir=${app.conf.dir} /
mkdir dir=${app.webapps.dir} /
mkdir dir=${app.log.dir} /
mkdir dir=${app.temp.dir} /

!-- Prepare and install Tomcat configuration files for the
application --

!-- Copy the stock web.xml from the tomcat installation --
copy
file=${app.tomcat-home}/conf/web.xml
tofile=${app.conf.dir}/web.xml
/

!--
Copy tomcat-server.xml to server.xml in the local Tomcat conf dir.
Use filters to substitute-in the values for the connector and
shutdown
ports.
--
copy

file=${conf.dir}/${app.release-type}/tomcat-server-${app.tomcat-version}.xml
  tofile=${app.conf.dir}/server.xml
  filtering=yes
/
  /target


Basically, all a CATALINA_BASE needs is conf/server.xml, conf/web.xml,
a log directory, and a work directory. I haven't bothered checking,
but you might not even need conf/web.xml... Tomcat might automatically
use the CATALINA_HOME/conf/web.xml if there isn't one in
CATALINA_BASE/conf/web.xml.

We still use webapps though we could deploy anywhere we wanted to.

 Yes, I've read RUNNING.TXT and I'm left wondering why do I have a 
 catalina class not found if all the tomcat jar files are in 
 CATALINA_HOME/lib
 
 Using CATALINA_BASE:   C:\tomcat8catalina_base Using 
 CATALINA_HOME:   C:\tomcat809 Using CATALINA_TMPDIR: 
 C:\tomcat8catalina_base\temp Using JRE_HOME: C:\jdk1.7.0_55
 Using CLASSPATH: 
 C:\tomcat809\bin\bootstrap.jar;C:\tomcat8catalina_base\bin\tomcat-juli.jar


 
Listening for transport dt_shmem at address: tomcat_shared_memory_id
 03-Nov-2014 17:45:50.410 SEVERE [main] 
 org.apache.tomcat.util.digester.Digester.startElement Begin event 
 threw exception java.lang.ClassNotFoundException: 
 org.apache.catalina.startup.VersionLoggerListener

It looks like you are trying to use the server.xml file from Tomcat
8.0.14 on Tomcat 8.0.9. The VersionLoggerListener class was introduced
relatively recently.

If you want to adapt server.xml from one version of Tomcat to another,
you should be careful. You have inadvertently downgraded your Tomcat
instance and lost functionality.

So, basically, you have damaged your Tomcat installation and want to
know why it doesn't work. Well, you broke it, so it doesn't work.

 All these experiments are done running Tomcat under NetBeans so 
 perhaps part of my issue is with NetBeans. The CLASSPATH shown 
 above is a bit on the short side, is it meant to be so short ?

Yes. Tomcat's CLASSPATH includes only things within CATALINA_HOME/bin
and CATALINA_BASE/bin (in that order). Everything else (like the stuff
in CATALINA_HOME/lib and CATALINA_BASE/lib) gets added to a
ClassLoader that is used after the server bootstraps itself.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUV+6wAAoJEBzwKT+lPKRYFrkP/iLMieBMpVuAW2FQohnJ+slQ
wgCN3kjuK3JCip1zVHZzUWvS2x0hDs+XWrNDLGtk36NDH9++k5z94GQjVukn5vFa
yaRKADjmNuLSzEj4dPbj7mFz3Vj0lmkxLLvuslyMQZe9WKqE7qeo8q0aw5v2M1uc
h5jZuCS54HdTbioXx2++YeQEaT1jqw6Iuk4acWkaKWS+8B/epXqMHh0yNBkI50un
EY+YwOJ1MQ5WbDEFw/nRUkbVMMQHpY6uWPxkqu5Te+JaUPRlnHD6qzhQCCjDJ92y
zGnGLkE5koo+cVCpVKosznJCw/ZCnf4Pub7NqtPysXe7smVBrCzMvQ1+IjDw4rUi
KK/e+9DtCLhq3HVcY4Nc03xycqADGMVeyASJgdf+ONRS7QhGFh7JJgSw+Xwfk9tM
Wu0VB3W2iC87F8Iag6prowFav7AYt4MmYuY224emaOVhmnOgHHGYi+DDAABw6dK9
KCPnFg6IOJaOUuNpCY6UHebVyVibglCsNZTrqRWX0o7vKYnDinEtL8YqwYrgfHZc
9E5RUJJ3kvz+Ptx2mkopS+JLx9Yll1bkOjPjC2k0kesc2gVknlRXzkjYO2I+VxGR
b64UnEklwLMkDOBpF2kz/K57sYbPxxR5oJfi3CAGs0ixENyamLWXv3i9d8CXcf+Z
0

RE: Separation of CATALINA_HOME and CATALINA_BASE

2014-11-03 Thread vince.webb

Neven
Even Tomcat newbies have to do real work that will find its way to a real 
server. 

Either of the benefits you described as a) and b) mean CATALINA_HOME and 
CATALINA_BASE need to be separate on a real server.

I would rather get it straight from the outset rather than mess about with a 
configuration that is going nowhere.

NetBeans separates out CATALINA_HOME and CATALINA_BASE, either automatically 
making its own decisions about the content of CATALINA_BASE or manually by 
allowing you to specify your own hand crafted directory.

I just made the switch from letting NetBeans populate CATALINA_BASE, to doing 
it myself. Naturally I want to avoid having the same files appear in both 
directories so I went for minimal content.

How much easier it would be if the Tomcat distribution had the correct 
separation build in.

Vince


-Original Message-
From: Neven Cvetkovic [mailto:neven.cvetko...@gmail.com] 
Sent: 03 November 2014 20:22
To: Tomcat Users List
Subject: Re: Separation of CATALINA_HOME and CATALINA_BASE

Vince,

On Mon, Nov 3, 2014 at 2:38 PM, vince.w...@thomsonreuters.com wrote:

 On the subject of Newbie-friendly, I think Tomcat would be a whole 
 lot more friendly if CATALINA_HOME and CATALINA_BASE were always 
 totally separate with a minimum of overlap.


Why is that?

I would argue current setup is very simple and newbie-friendly. Most newbies 
are going to have a single-instance tomcat running, even developers in their 
IDEs (Eclipse, NetBeans, IntelliJ, etc...) would probably start with a single 
Tomcat instance.

You want your CATALINA_HOME = CATALINA_BASE in the newbie situation.
Actually you don't even want to advertise the difference to the newbies.
You probably shouldn't even configure CATALINA_HOME/CATALINA_BASE environment 
variables, but let the scripts infer from where you are running them.

Now, once one graduates pass the newbie-friendly - one can start looking when 
CATALINA_HOME != CATALINA_BASE is useful. Here are some ideas, why you would 
maybe want to separate out CATALINA_HOME and CATALINA_BASE:

a) when you want to make your Tomcat upgrades easier over time, so you just 
upgrade your CATALINA_HOME each time and you keep your existing CATALINA_BASE 
(instance configuration) directory.

b) multi-instance environment, when you have multiple Tomcat instances running 
on the same machine, and you are sick-and-tired of copying entire tomcat 
directory for each instance and do the upgrades for each instance individually

Other than that, I don't see another reason to have CATALINA_HOME and 
CATALINA_BASE be any different.



 Although I used Tomcat quite a lot years ago I still consider myself a 
 Tomcat Newbie, mostly because configuration always took days or weeks 
 longer than is reasonable. Now I'm back to Tomcat after years of 
 having it easy using GlassFish. The files might be different now but 
 the grief with configuration is still the same.

 I've been through numerous configurations with various versions of 
 Tomcat
 7 and 8 the furthest I've got is getting a database connection to 
 work. Now having created a minimal CATALINA_BASE I've jumped a few 
 steps back and it won't start.


Exactly my point earlier Vince. You ignore setting up 
CATALINA_HOME/CATALINA_BASE, you let the scripts infer that from where it is 
being started. And then you just configure your datasource either at the 
GlobalNamingResources level (e.g at conf/server.xml) or at the Context 
level (e.g. at conf/Catalina/localhost/myapp.xml).


 I am sure many of the problems would evaporate if only there were 
 built in and permanent clarity over the separation between 
 CATALINA_HOME and CATALINA_BASE.

 Yes, I've read RUNNING.TXT and I'm left wondering why do I have a 
 catalina class not found if all the tomcat jar files are in 
 CATALINA_HOME/lib

 Using CATALINA_BASE:   C:\tomcat8catalina_base
 Using CATALINA_HOME:   C:\tomcat809
 Using CATALINA_TMPDIR: C:\tomcat8catalina_base\temp
 Using JRE_HOME:C:\jdk1.7.0_55
 Using CLASSPATH:
  C:\tomcat809\bin\bootstrap.jar;C:\tomcat8catalina_base\bin\tomcat-juli.jar
 Listening for transport dt_shmem at address: tomcat_shared_memory_id
 03-Nov-2014 17:45:50.410 SEVERE [main] 
 org.apache.tomcat.util.digester.Digester.startElement Begin event 
 threw exception
  java.lang.ClassNotFoundException:
 org.apache.catalina.startup.VersionLoggerListener


 All these experiments are done running Tomcat under NetBeans so 
 perhaps part of my issue is with NetBeans. The CLASSPATH shown above 
 is a bit on the short side, is it meant to be so short ?


If you are running Tomcat instance in IDE, why do you bother separating out 
CATALINA_BASE and CATALINA_HOME? Default unzip and play setup work nicely in 
Eclipse and IntelliJ. I have not played with NetBeans as much, but I am sure it 
is easy out-of-box setup.

Hope that helps!

Cheers!
Neven

Re: Separation of CATALINA_HOME and CATALINA_BASE

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Vince,

On 11/3/14 4:12 PM, vince.w...@thomsonreuters.com wrote:
 Even Tomcat newbies have to do real work that will find its way to
 a real server.
 
 Either of the benefits you described as a) and b) mean
 CATALINA_HOME and CATALINA_BASE need to be separate on a real
 server.
 
 I would rather get it straight from the outset rather than mess
 about with a configuration that is going nowhere.

Separating a unified Tomcat deployment into CATALINA_HOME and
CATALINA_BASE is pretty trivial. Your configuration isn't going nowhere.

Do you know what's worse than a simple configuration to start that can
grow into a complex one? One that is so complex you can't even get
started. Have you ever configured Weblogic? There is (or was, back in
circa 2001 when I had the misfortune of working on that platform) no
such thing as unzip and run bin/startup.sh to launch the server. No,
you basically had to go and get trained (at a high cost, by corporate
trainers, of course) to do anything at all with the darned thing.

If you want to talk about a configuration that is going nowhere,
anything that is automatically done by Eclipse, NetBeans, etc. is not
going anywhere.

 NetBeans separates out CATALINA_HOME and CATALINA_BASE, either 
 automatically making its own decisions about the content of 
 CATALINA_BASE or manually by allowing you to specify your own hand 
 crafted directory.
 
 I just made the switch from letting NetBeans populate
 CATALINA_BASE, to doing it myself. Naturally I want to avoid having
 the same files appear in both directories so I went for minimal
 content.
 
 How much easier it would be if the Tomcat distribution had the 
 correct separation build in.

It would be harder for newbies and no real benefit to experts.

Let me show you the difference in complexity between deploying Tomcat
with a unified versus split configuration:

Unified
- ---

$ wget http://host/path/to/tomcat-x.y.z.tar.gz
$ tar xzf http://host/path/to/tomcat-x.y.z.tar.gz
$ tomcat-x.y.z/bin/startup.sh

Woot!

Separated
- -
$ wget http://host/path/to/tomcat-x.y.z.tar.gz
$ tar xzf http://host/path/to/tomcat-x.y.z.tar.gz
$ mkdir -p my-tomcat-base/conf
$ mkdir -p my-tomcat-base/log
$ mkdir -p my-tomcat-base/work
$ mkdir -p my-tomcat-base/temp
$ mkdir -p my-tomcat-base/webapps
$ cp tomcat-x.y.z/conf/server.xml my-tomcat-base/conf
$ cp tomcat-x.y.z/conf/web.xml my-tomcat-base/conf
  (the above step may not actually be necessary)
$ cp tomcat-x.y.z/webapps/ROOT my-tomcat-base/webapps
$ export CATALINA_HOME=`pwd`/tomcat-x.y.z
$ export CATALINA_BASE=`pwd`/my-tomcat-base
$ $CATALINA_HOME/bin/startup.sh

Done.

So, that's not all that complicated when you think about it, but to
ask someone who knows nothing about a command-line, working
effectively in an operating system, etc. and only knows about
programming in Java -- maybe only servlet programming in Java -- to
configure the server in the split case is confusing as all hell.

Anyone downloading a ZIP or tar archive containing a Tomcat
installation would be confused if the archive contained not one but
two top-level directories. Also, it would overwrite your
split-configuration if you unpacked that archive in the same directory
as when you first started.

An installer program would have to explain what in the world the split
configuration was. Have you ever tried to tell someone how to set up
their email? POP versus IMAP? Most users have absolutely no idea what
that is, and mail programs give no clue as to which one to choose. The
same would be true of CATALINA_HOME versus CATALINA_BASE. (Besides, I
truly doubt that any expert system administrators are using the Tomcat
Windows Installer to install/upgrade their systems. Maybe I'm wrong,
but then again I can't imagine running a Windows server in production.
I value my sleep and prefer to build new things instead of holding
together configurations with chewing gum and duct tape. Oh, and
rebooting all the time.)

Anyhow, we can debate this all you want, but I will be -0 or even -1
to a default split-configuration of Tomcat unless someone has a really
good idea for how to make it make sense to anyone on their first-touch.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUV/STAAoJEBzwKT+lPKRYwq0QAJis//26ab34xcdAbs1Ths8I
0D4XWjh8cNv+QqvexftR8atf+2mN4NCukeHe95CF7AT0GVF0hd/z6irzRp32OXVd
gg8nQkn4u+OjzHC2aCDSHGTDvg2/rkf1RdKqSD84pooB56d6hysMszCdHVZNFKHY
6SCOIFcwiVE/iiaLmV39uyT5tgcMQyAVZ0g9xym3tJHT8pXiFQ4pKZQKxnl4PBhx
ob+l1ksb4gaekFV/WIQEr9HLS73FLcHr9rk0VtsM+4HiE8t2XacYKXveewShWXUX
+kaFD0Udb5VCqlqMRKKZKw2a9kOh2XYGI7C+itYBHVRUXtW//jtwd2G6fje+5Siz
phSB+aq6kHK2iEF4ZxGQ2asqCFrCCBWPfMtrrWScKHrPVYj7suAcLpfk2oaFksGD
BER8LT8WRi35L9VbemNMfFPCSFFEyP2Ej7Xa09ZdS4jqd1O8m8ZsWxHDW5JbYL2s
bcffVeHhZvglyKHfcciCYzSDdFprsI0qglFgVtRy/E35Gn6FkyS23npHl1zeehhy
J/2a/4STTexpMZtC2e1E5nDb+/m3qAn9SkBYW5IxeU9jrYBx1aQeZqt2TxCj4Kt9
GAD5gf3FvX0sAs5UnNNQTe4gf

Re: Separation of CATALINA_HOME and CATALINA_BASE

2014-11-03 Thread Mark Eggers

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Vince,

On 11/3/2014 1:12 PM, vince.w...@thomsonreuters.com wrote:
 Neven Even Tomcat newbies have to do real work that will find its
 way to a real server.
 
 Either of the benefits you described as a) and b) mean
 CATALINA_HOME and CATALINA_BASE need to be separate on a real
 server.
 
 I would rather get it straight from the outset rather than mess
 about with a configuration that is going nowhere.
 
 NetBeans separates out CATALINA_HOME and CATALINA_BASE, either 
 automatically making its own decisions about the content of 
 CATALINA_BASE or manually by allowing you to specify your own hand 
 crafted directory.
 

Actually, at least in recent versions of NetBeans this is not the
default case.

The default case is to use CATALINA_HOME and let NetBeans completely
control the Tomcat instance.

This is the way I normally run NetBeans on my development systems. I
rarely use CATALINA_BASE in development, since I just add all of the
extra jars to $CATALINA_HOME/lib.

 I just made the switch from letting NetBeans populate
 CATALINA_BASE, to doing it myself. Naturally I want to avoid having
 the same files appear in both directories so I went for minimal
 content.
 

This is only true if you select the check box in the server creation
wizard that is labeled Use Private Configuration Folder (Catalina Base).

In short, NetBeans follows the instructions set down in RUNNING.txt.
This is one of the reasons I like NetBeans over other development
environments.

 How much easier it would be if the Tomcat distribution had the 
 correct separation build in.
 

IMHO, I think the way Tomcat currently does it is optimal. Keep it
simple for those people who want to just unpack and go, while making
it relatively easy for those people who want more flexibility.

 Vince

For a development environment, I just typically unpack Tomcat
somewhere, edit tomcat-users.xml, point NetBeans to it, and go.

Typically, a development environment can contain all of the extra JARs
required for development.

This of course means a slightly slower Tomcat start up.

If the start up times are onerous, then you can go ahead and use
CATALINA_HOME and CATALINA_BASE in NetBeans quite easily. It's the
same as setting things up in production, with the exception that
NetBeans populates CATALINA_HOME and CATALINA_BASE based on the values
you entered in the wizard (no environment variables to set).

1. Set up an unaltered Tomcat in one directory
2. Create a duplicate directory structure somewhere else - to whit:

   CATALINA_BASE-+
 +-bin
 +-conf
 +-lib
 +-logs
 +-temp
 +-webapps
 +-work

3. Copy tomcat-juli.jar from CATALINA_HOME/bin to CATALINA_BASE/bin
4. Copy all of the stuff from CATALINA_HOME/conf to CATALINA_BASE/conf
5. Edit CATALINA_BASE/conf/server.xml
   a. change the Server port
   b. change HTTP/1.1 connector port
   c. change the HTTPS connector port or comment it out
   d. change the AJP connector port or comment it out
6. Edit tomcat-users.xml
7. Copy over the manager application
   a. Copy over the application from CATALINA_HOME/webapps - OR -
   b. Create a manager.xml in CATALINA_BASE/conf/Catalina/[hostname]

?xml version=1.0 encoding=UTF-8?
Context
docBase=location of manager application in CATALINA_HOME
antiResourceLocking=false
privileged=true
useHttpOnly=true/

   c. useHttpOnly=true is default for 7.0.x
   d. [hostname] is typically localhost for single Host server.xml

To modify what extra JARs are needed for this CATALINA_BASE, just add
them to CATALINA_BASE/lib. This way your pristine Tomcat remains pristine.

This works for both NetBeans-controlled Tomcats and Tomcats not
running under an IDE.

Please note that the default mechanism used by Eclipse is quite different.

. . . just my two cents.
/mde/

 
 
 -Original Message- From: Neven Cvetkovic 
 [mailto:neven.cvetko...@gmail.com] Sent: 03 November 2014 20:22
 To: Tomcat Users List Subject: Re: Separation of CATALINA_HOME and 
 CATALINA_BASE
 
 Vince,
 
 On Mon, Nov 3, 2014 at 2:38 PM, vince.w...@thomsonreuters.com 
 wrote:
 
 On the subject of Newbie-friendly, I think Tomcat would be a 
 whole lot more friendly if CATALINA_HOME and CATALINA_BASE were 
 always totally separate with a minimum of overlap.
 
 
 Why is that?
 
 I would argue current setup is very simple and newbie-friendly. 
 Most newbies are going to have a single-instance tomcat running,
 even developers in their IDEs (Eclipse, NetBeans, IntelliJ, etc...)
 would probably start with a single Tomcat instance.
 
 You want your CATALINA_HOME = CATALINA_BASE in the newbie 
 situation. Actually you don't even want to advertise the
 difference to the newbies. You probably shouldn't even configure 
 CATALINA_HOME/CATALINA_BASE environment variables, but let the 
 scripts infer from where you are running them.
 
 Now, once one graduates

Re: Separation of CATALINA_HOME and CATALINA_BASE

2014-11-03 Thread Leo Donahue

On Mon, Nov 3, 2014 at 3:33 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Vince,

 On 11/3/14 4:12 PM, vince.w...@thomsonreuters.com wrote:
 
  How much easier it would be if the Tomcat distribution had the
  correct separation build in.

 It would be harder for newbies and no real benefit to experts.

 Let me show you the difference in complexity between deploying Tomcat
 with a unified versus split configuration:

 Unified
 - ---

 $ wget http://host/path/to/tomcat-x.y.z.tar.gz
 $ tar xzf http://host/path/to/tomcat-x.y.z.tar.gz
 $ tomcat-x.y.z/bin/startup.sh


You can do that in linux. not so well in windows.  scripts work
differently.  you log out of the windows session, and the script stops,
hence why every windows user wants to install Tomcat as a service,
whichever way they do that.



 Separated
 - -
 $ wget http://host/path/to/tomcat-x.y.z.tar.gz
 $ tar xzf http://host/path/to/tomcat-x.y.z.tar.gz
 $ mkdir -p my-tomcat-base/conf
 $ mkdir -p my-tomcat-base/log
 $ mkdir -p my-tomcat-base/work
 $ mkdir -p my-tomcat-base/temp
 $ mkdir -p my-tomcat-base/webapps
 $ cp tomcat-x.y.z/conf/server.xml my-tomcat-base/conf
 $ cp tomcat-x.y.z/conf/web.xml my-tomcat-base/conf
   (the above step may not actually be necessary)
 $ cp tomcat-x.y.z/webapps/ROOT my-tomcat-base/webapps
 $ export CATALINA_HOME=`pwd`/tomcat-x.y.z
 $ export CATALINA_BASE=`pwd`/my-tomcat-base
 $ $CATALINA_HOME/bin/startup.sh

 Done.

 So, that's not all that complicated when you think about it, but to
 ask someone who knows nothing about a command-line, working
 effectively in an operating system, etc. and only knows about
 programming in Java -- maybe only servlet programming in Java -- to
 configure the server in the split case is confusing as all hell.

 Anyone downloading a ZIP or tar archive containing a Tomcat
 installation would be confused if the archive contained not one but
 two top-level directories. Also, it would overwrite your
 split-configuration if you unpacked that archive in the same directory
 as when you first started.

 An installer program would have to explain what in the world the split
 configuration was. Have you ever tried to tell someone how to set up
 their email? POP versus IMAP? Most users have absolutely no idea what
 that is, and mail programs give no clue as to which one to choose. The
 same would be true of CATALINA_HOME versus CATALINA_BASE.


Everything has some degree of learning.  New people are trying to learn two
things at once, how something works as well as the why do it this way
conventions that experienced users have implemented.  New users don't
understand the convention and want to learn it the hard way first before
they can appreciate or even understand the convention.


 (Besides, I
 truly doubt that any expert system administrators are using the Tomcat
 Windows Installer to install/upgrade their systems. Maybe I'm wrong,


You had qualify that with 'expert'... now I have nothing more to add.


 but then again I can't imagine running a Windows server in production.


This too shall pass...


 I value my sleep and prefer to build new things instead of holding
 together configurations with chewing gum and duct tape. Oh, and
 rebooting all the time.)

 Anyhow, we can debate this all you want, but I will be -0 or even -1
 to a default split-configuration of Tomcat unless someone has a really
 good idea for how to make it make sense to anyone on their first-touch.

 - -chris


I would rather just point (windows) people to an example of a split
configuration or any other configuration and let them implement it if they
choose to do so, instead of getting Tomcat pre-configured. Part of the draw
to Tomcat is that you have flexibility with how you choose to run it
(script, service, windows installer, etc)

Re: Separation of CATALINA_HOME and CATALINA_BASE

2014-11-03 Thread Mark Eggers

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chris,

On 11/3/2014 1:33 PM, Christopher Schultz wrote:
 Vince,
 
 On 11/3/14 4:12 PM, vince.w...@thomsonreuters.com wrote:
 Even Tomcat newbies have to do real work that will find its way
 to a real server.
 
 Either of the benefits you described as a) and b) mean 
 CATALINA_HOME and CATALINA_BASE need to be separate on a real 
 server.
 
 I would rather get it straight from the outset rather than mess 
 about with a configuration that is going nowhere.
 
 Separating a unified Tomcat deployment into CATALINA_HOME and 
 CATALINA_BASE is pretty trivial. Your configuration isn't going
 nowhere.
 
 Do you know what's worse than a simple configuration to start that
 can grow into a complex one? One that is so complex you can't even
 get started. Have you ever configured Weblogic? There is (or was,
 back in circa 2001 when I had the misfortune of working on that
 platform) no such thing as unzip and run bin/startup.sh to launch
 the server. No, you basically had to go and get trained (at a high
 cost, by corporate trainers, of course) to do anything at all with
 the darned thing.
 

Other application servers are equally unpleasant in my experience.

 If you want to talk about a configuration that is going nowhere, 
 anything that is automatically done by Eclipse, NetBeans, etc. is
 not going anywhere.

By default, NetBeans does absolutely nothing to change the Tomcat
configuration. Even if you decide to use a separate CATALINA_HOME and
CATALINA_BASE, NetBeans follows the model detailed in RUNNING.txt.

 
 NetBeans separates out CATALINA_HOME and CATALINA_BASE, either 
 automatically making its own decisions about the content of 
 CATALINA_BASE or manually by allowing you to specify your own
 hand crafted directory.
 
 I just made the switch from letting NetBeans populate 
 CATALINA_BASE, to doing it myself. Naturally I want to avoid
 having the same files appear in both directories so I went for
 minimal content.
 
 How much easier it would be if the Tomcat distribution had the 
 correct separation build in.
 
 It would be harder for newbies and no real benefit to experts.
 
 Let me show you the difference in complexity between deploying
 Tomcat with a unified versus split configuration:
 
 Unified ---
 
 $ wget http://host/path/to/tomcat-x.y.z.tar.gz $ tar xzf
 http://host/path/to/tomcat-x.y.z.tar.gz $
 tomcat-x.y.z/bin/startup.sh
 
 Woot!
 
 Separated - $ wget http://host/path/to/tomcat-x.y.z.tar.gz 
 $ tar xzf http://host/path/to/tomcat-x.y.z.tar.gz $ mkdir -p
 my-tomcat-base/conf $ mkdir -p my-tomcat-base/log $ mkdir -p
 my-tomcat-base/work $ mkdir -p my-tomcat-base/temp $ mkdir -p
 my-tomcat-base/webapps $ cp tomcat-x.y.z/conf/server.xml
 my-tomcat-base/conf $ cp tomcat-x.y.z/conf/web.xml
 my-tomcat-base/conf (the above step may not actually be necessary) 
 $ cp tomcat-x.y.z/webapps/ROOT my-tomcat-base/webapps $ export
 CATALINA_HOME=`pwd`/tomcat-x.y.z $ export
 CATALINA_BASE=`pwd`/my-tomcat-base $ $CATALINA_HOME/bin/startup.sh
 
 Done.
 

This is not so bad for a person used to the command line, but getting
a developer on any platform to do this is going to be a challenge.

If that developer is only familiar with Windows or the Macintosh at a
user level, you've placed an almost insurmountable burden in getting
Tomcat to run.

 So, that's not all that complicated when you think about it, but
 to ask someone who knows nothing about a command-line, working 
 effectively in an operating system, etc. and only knows about 
 programming in Java -- maybe only servlet programming in Java --
 to configure the server in the split case is confusing as all
 hell.
 

+1

 Anyone downloading a ZIP or tar archive containing a Tomcat 
 installation would be confused if the archive contained not one
 but two top-level directories. Also, it would overwrite your 
 split-configuration if you unpacked that archive in the same
 directory as when you first started.
 
 An installer program would have to explain what in the world the
 split configuration was. Have you ever tried to tell someone how to
 set up their email? POP versus IMAP? Most users have absolutely no
 idea what that is, and mail programs give no clue as to which one
 to choose. The same would be true of CATALINA_HOME versus
 CATALINA_BASE. (Besides, I truly doubt that any expert system
 administrators are using the Tomcat Windows Installer to
 install/upgrade their systems. Maybe I'm wrong, but then again I
 can't imagine running a Windows server in production. I value my
 sleep and prefer to build new things instead of holding together
 configurations with chewing gum and duct tape. Oh, and rebooting
 all the time.)
 

I (sadly) run a few Windows servers in production. I've not tried
CATALINA_HOME / CATALINA_BASE in conjunction with the service install,
since those systems are quite static. However, even updating Java on
those systems is a bit of a pain.

Rebooting is also not nice for reliability

Re: Separation of CATALINA_HOME and CATALINA_BASE

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Leo,

On 11/3/14 5:05 PM, Leo Donahue wrote:
 On Mon, Nov 3, 2014 at 3:33 PM, Christopher Schultz  
 ch...@christopherschultz.net wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
 Vince,
 
 On 11/3/14 4:12 PM, vince.w...@thomsonreuters.com wrote:
 
 How much easier it would be if the Tomcat distribution had the 
 correct separation build in.
 
 It would be harder for newbies and no real benefit to experts.
 
 Let me show you the difference in complexity between deploying
 Tomcat with a unified versus split configuration:
 
 Unified - ---
 
 $ wget http://host/path/to/tomcat-x.y.z.tar.gz $ tar xzf
 http://host/path/to/tomcat-x.y.z.tar.gz $
 tomcat-x.y.z/bin/startup.sh
 
 
 You can do that in linux. not so well in windows.  scripts work 
 differently.  you log out of the windows session, and the script
 stops, hence why every windows user wants to install Tomcat as a
 service, whichever way they do that.

Okay:

C:\whatever wget http://host/path/to/tomcat-x.y.z.zip
C:\whatever unzip http://host/path/to/tomcat-x.y.z.zip (or however you
 unzip from the CLI in Windows.. I haven't been able to
 figure that out, but it's clearer than giving mouse-click
 directions)
C:\whatever SET CATALINA_HOME=C:\whatever\apache-tomcat-x.y.z
C:\whatever SET CATALINA_BASE=C:\whatever\apache-tomcat-x.y.z
C:\whatever %CATALINA_HOME%\bin\service.bat install my-great-webapp
C:\whatever service start my-great-webapp

 Separated - - $ wget
 http://host/path/to/tomcat-x.y.z.tar.gz $ tar xzf
 http://host/path/to/tomcat-x.y.z.tar.gz $ mkdir -p
 my-tomcat-base/conf $ mkdir -p my-tomcat-base/log $ mkdir -p
 my-tomcat-base/work $ mkdir -p my-tomcat-base/temp $ mkdir -p
 my-tomcat-base/webapps $ cp tomcat-x.y.z/conf/server.xml
 my-tomcat-base/conf $ cp tomcat-x.y.z/conf/web.xml
 my-tomcat-base/conf (the above step may not actually be
 necessary) $ cp tomcat-x.y.z/webapps/ROOT my-tomcat-base/webapps 
 $ export CATALINA_HOME=`pwd`/tomcat-x.y.z $ export
 CATALINA_BASE=`pwd`/my-tomcat-base $
 $CATALINA_HOME/bin/startup.sh

For Windowers:

C:\whatever wget http://host/path/to/tomcat-x.y.z.zip
C:\whatever unzip http://host/path/to/tomcat-x.y.z.zip (or however you
 unzip from the CLI in Windows.. I haven't been able to
 figure that out, but it's clearer than giving mouse-click
 directions)
C:\whatever mkdir my-tomcat-base/conf
C:\whatever mkdir my-tomcat-base/log
C:\whatever mkdir my-tomcat-base/work
C:\whatever mkdir my-tomcat-base/temp
C:\whatever mkdir my-tomcat-base/webapps
C:\whatever SET CATALINA_HOME=C:\whatever\apache-tomcat-x.y.z
C:\whatever SET CATALINA_BASE=C:\whatever\my-tomcat-base
C:\whatever %CATALINA_HOME%\bin\service.bat install my-great-webapp
C:\whatever service start my-great-webapp

(All this from memory... apologies if those exact commands don't work.)

 Done.
 
 So, that's not all that complicated when you think about it, but
 to ask someone who knows nothing about a command-line, working 
 effectively in an operating system, etc. and only knows about 
 programming in Java -- maybe only servlet programming in Java --
 to configure the server in the split case is confusing as all
 hell.
 
 Anyone downloading a ZIP or tar archive containing a Tomcat 
 installation would be confused if the archive contained not one
 but two top-level directories. Also, it would overwrite your 
 split-configuration if you unpacked that archive in the same
 directory as when you first started.
 
 An installer program would have to explain what in the world the
 split configuration was. Have you ever tried to tell someone how
 to set up their email? POP versus IMAP? Most users have
 absolutely no idea what that is, and mail programs give no clue
 as to which one to choose. The same would be true of
 CATALINA_HOME versus CATALINA_BASE.
 
 
 Everything has some degree of learning.  New people are trying to
 learn two things at once, how something works as well as the why
 do it this way conventions that experienced users have
 implemented.  New users don't understand the convention and want to
 learn it the hard way first before they can appreciate or even
 understand the convention.

Agreed. The point I'm trying to make is that experts are experts
because they have learned. Peeling-back the covers of Tomcat reveals
those expert features like a split configuration. Being forced to use
a split-configuration because it's what experts do is one sure way
to generate a lot of noise on this mailing list.

 (Besides, I truly doubt that any expert system administrators are
 using the Tomcat Windows Installer to install/upgrade their
 systems. Maybe I'm wrong,
 
 
 You had qualify that with 'expert'... now I have nothing more to
 add.
 
 
 but then again I can't imagine running a Windows server in
 production.
 
 
 This too shall pass...
 
 
 I value my sleep and prefer to build new things instead of
 holding together

Re: Separation of CATALINA_HOME and CATALINA_BASE

2014-11-03 Thread Mark Eggers

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Neven and Vince,

It's dead-simple to run under NetBeans. Just unzip and go - use the
defaults.

On 11/3/2014 12:21 PM, Neven Cvetkovic wrote:
 Vince,
 
 On Mon, Nov 3, 2014 at 2:38 PM, vince.w...@thomsonreuters.com
 wrote:
 
 On the subject of Newbie-friendly, I think Tomcat would be a
 whole lot more friendly if CATALINA_HOME and CATALINA_BASE were
 always totally separate with a minimum of overlap.
 
 
 Why is that?
 
 I would argue current setup is very simple and newbie-friendly.
 Most newbies are going to have a single-instance tomcat running,
 even developers in their IDEs (Eclipse, NetBeans, IntelliJ, etc...)
 would probably start with a single Tomcat instance.
 
 You want your CATALINA_HOME = CATALINA_BASE in the newbie
 situation. Actually you don't even want to advertise the difference
 to the newbies. You probably shouldn't even configure
 CATALINA_HOME/CATALINA_BASE environment variables, but let the
 scripts infer from where you are running them.
 
 Now, once one graduates pass the newbie-friendly - one can start
 looking when CATALINA_HOME != CATALINA_BASE is useful. Here are
 some ideas, why you would maybe want to separate out CATALINA_HOME
 and CATALINA_BASE:
 
 a) when you want to make your Tomcat upgrades easier over time, so
 you just upgrade your CATALINA_HOME each time and you keep your
 existing CATALINA_BASE (instance configuration) directory.
 
 b) multi-instance environment, when you have multiple Tomcat
 instances running on the same machine, and you are sick-and-tired
 of copying entire tomcat directory for each instance and do the
 upgrades for each instance individually
 
 Other than that, I don't see another reason to have CATALINA_HOME
 and CATALINA_BASE be any different.
 
 
 
 Although I used Tomcat quite a lot years ago I still consider
 myself a Tomcat Newbie, mostly because configuration always took
 days or weeks longer than is reasonable. Now I'm back to Tomcat
 after years of having it easy using GlassFish. The files might be
 different now but the grief with configuration is still the
 same.
 
 I've been through numerous configurations with various versions
 of Tomcat 7 and 8 the furthest I've got is getting a database
 connection to work. Now having created a minimal CATALINA_BASE
 I've jumped a few steps back and it won't start.
 
 
 Exactly my point earlier Vince. You ignore setting up 
 CATALINA_HOME/CATALINA_BASE, you let the scripts infer that from
 where it is being started. And then you just configure your
 datasource either at the GlobalNamingResources level (e.g at
 conf/server.xml) or at the Context level (e.g. at
 conf/Catalina/localhost/myapp.xml).
 
 
 I am sure many of the problems would evaporate if only there were
 built in and permanent clarity over the separation between
 CATALINA_HOME and CATALINA_BASE.
 
 Yes, I've read RUNNING.TXT and I'm left wondering why do I have a
 catalina class not found if all the tomcat jar files are in
 CATALINA_HOME/lib
 

 Using CATALINA_BASE:   C:\tomcat8catalina_base Using
 CATALINA_HOME:   C:\tomcat809 Using CATALINA_TMPDIR:
 C:\tomcat8catalina_base\temp Using JRE_HOME:
 C:\jdk1.7.0_55 Using CLASSPATH: 
 C:\tomcat809\bin\bootstrap.jar;C:\tomcat8catalina_base\bin\tomcat-juli.jar

 
Listening for transport dt_shmem at address: tomcat_shared_memory_id
 03-Nov-2014 17:45:50.410 SEVERE [main] 
 org.apache.tomcat.util.digester.Digester.startElement Begin event
 threw exception java.lang.ClassNotFoundException: 
 org.apache.catalina.startup.VersionLoggerListener
 

And the above is broken. You've checked the box marked Use Private
Configuration Folder (Catalina Base) without setting that folder up
properly.

I'm surprised that NetBeans even allowed you to complete that
configuration if it didn't find the requisite folder structure / JARs
/ configuration files in C:\tomcat8catalina_base.

 
 All these experiments are done running Tomcat under NetBeans so
 perhaps part of my issue is with NetBeans. The CLASSPATH shown
 above is a bit on the short side, is it meant to be so short ?

Yes. There is no need to have a long CLASSPATH with Tomcat.

 
 
 If you are running Tomcat instance in IDE, why do you bother
 separating out CATALINA_BASE and CATALINA_HOME? Default unzip and
 play setup work nicely in Eclipse and IntelliJ. I have not played
 with NetBeans as much, but I am sure it is easy out-of-box setup.
 
 Hope that helps!
 
 Cheers! Neven
 

I just did the following without any trouble under NetBeans 8.0.1.

1. Downloaded 8.0.14 (I know 8.0.15 is about out) Windows 64 bit zip
2. Unzipped it
3. Backed up tomcat-users.xml
4. Copied over my tomcat-users.xml from 7.0.56
5. Copied over my setenv.bat from 7.0.56 (sets up JMX, etc)
6. Configured the server in NetBeans
   a. used defaults
   b. added the user with manager-script role
7. Started it

One of the issues I did run into when using tcnative-1.dll is that I
got the following error message:

12.0.0.1 is not a recognized

Re: Separation of CATALINA_HOME and CATALINA_BASE

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 11/3/14 5:16 PM, Mark Eggers wrote:
 Chris,
 
 On 11/3/2014 1:33 PM, Christopher Schultz wrote:
 Vince,
 
 On 11/3/14 4:12 PM, vince.w...@thomsonreuters.com wrote:
 Even Tomcat newbies have to do real work that will find its
 way to a real server.
 
 Either of the benefits you described as a) and b) mean 
 CATALINA_HOME and CATALINA_BASE need to be separate on a real 
 server.
 
 I would rather get it straight from the outset rather than mess
  about with a configuration that is going nowhere.
 
 Separating a unified Tomcat deployment into CATALINA_HOME and 
 CATALINA_BASE is pretty trivial. Your configuration isn't going 
 nowhere.
 
 Do you know what's worse than a simple configuration to start
 that can grow into a complex one? One that is so complex you
 can't even get started. Have you ever configured Weblogic? There
 is (or was, back in circa 2001 when I had the misfortune of
 working on that platform) no such thing as unzip and run
 bin/startup.sh to launch the server. No, you basically had to go
 and get trained (at a high cost, by corporate trainers, of
 course) to do anything at all with the darned thing.
 
 
 Other application servers are equally unpleasant in my experience.
 
 If you want to talk about a configuration that is going nowhere,
  anything that is automatically done by Eclipse, NetBeans, etc.
 is not going anywhere.
 
 By default, NetBeans does absolutely nothing to change the Tomcat 
 configuration. Even if you decide to use a separate CATALINA_HOME
 and CATALINA_BASE, NetBeans follows the model detailed in
 RUNNING.txt.
 
 
 NetBeans separates out CATALINA_HOME and CATALINA_BASE, either
  automatically making its own decisions about the content of 
 CATALINA_BASE or manually by allowing you to specify your own 
 hand crafted directory.
 
 I just made the switch from letting NetBeans populate 
 CATALINA_BASE, to doing it myself. Naturally I want to avoid 
 having the same files appear in both directories so I went for 
 minimal content.
 
 How much easier it would be if the Tomcat distribution had the
  correct separation build in.
 
 It would be harder for newbies and no real benefit to experts.
 
 Let me show you the difference in complexity between deploying 
 Tomcat with a unified versus split configuration:
 
 Unified ---
 
 $ wget http://host/path/to/tomcat-x.y.z.tar.gz $ tar xzf 
 http://host/path/to/tomcat-x.y.z.tar.gz $ 
 tomcat-x.y.z/bin/startup.sh
 
 Woot!
 
 Separated - $ wget
 http://host/path/to/tomcat-x.y.z.tar.gz $ tar xzf
 http://host/path/to/tomcat-x.y.z.tar.gz $ mkdir -p 
 my-tomcat-base/conf $ mkdir -p my-tomcat-base/log $ mkdir -p 
 my-tomcat-base/work $ mkdir -p my-tomcat-base/temp $ mkdir -p 
 my-tomcat-base/webapps $ cp tomcat-x.y.z/conf/server.xml 
 my-tomcat-base/conf $ cp tomcat-x.y.z/conf/web.xml 
 my-tomcat-base/conf (the above step may not actually be
 necessary) $ cp tomcat-x.y.z/webapps/ROOT my-tomcat-base/webapps
 $ export CATALINA_HOME=`pwd`/tomcat-x.y.z $ export 
 CATALINA_BASE=`pwd`/my-tomcat-base $
 $CATALINA_HOME/bin/startup.sh
 
 Done.
 
 
 This is not so bad for a person used to the command line, but
 getting a developer on any platform to do this is going to be a
 challenge.

I presented those examples in CLI terms because they are brief,
concise, and correct. The Nullsoft Installer basically does that same
stuff but with safety gear surrounding it.

 If that developer is only familiar with Windows or the Macintosh at
 a user level, you've placed an almost insurmountable burden in
 getting Tomcat to run.

While a Mac installer might be nice, it's really not hard to unzip
and then bin/startup.sh on Mac. I'd argue that about Windows, but I
recently did some consulting with a company full of Windows
administrators and when I dropped to the command-line to get some
real work done (my words to them), they all got a panicked expression
on their faces. I guess without a point-and-click interface, some
folks are just lost.

 So, that's not all that complicated when you think about it, but 
 to ask someone who knows nothing about a command-line, working 
 effectively in an operating system, etc. and only knows about 
 programming in Java -- maybe only servlet programming in Java -- 
 to configure the server in the split case is confusing as all 
 hell.
 
 
 +1
 
 Anyone downloading a ZIP or tar archive containing a Tomcat 
 installation would be confused if the archive contained not one 
 but two top-level directories. Also, it would overwrite your 
 split-configuration if you unpacked that archive in the same 
 directory as when you first started.
 
 An installer program would have to explain what in the world the 
 split configuration was. Have you ever tried to tell someone how
 to set up their email? POP versus IMAP? Most users have
 absolutely no idea what that is, and mail programs give no clue
 as to which one to choose. The same would be true of
 CATALINA_HOME versus

Re: Separation of CATALINA_HOME and CATALINA_BASE

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 11/3/14 4:59 PM, Mark Eggers wrote:
 1. Set up an unaltered Tomcat in one directory 2. Create a
 duplicate directory structure somewhere else - to whit:
 
 CATALINA_BASE-+ +-bin +-conf +-lib +-logs +-temp +-webapps +-work

You don't need all of that, but you can create all that structure if
you'd like.

 3. Copy tomcat-juli.jar from CATALINA_HOME/bin to
 CATALINA_BASE/bin

tomcat-juli.jar can still live in CATALINA_HOME/bin (unless is
something very specific to Netbeans deployments).

 4. Copy all of the stuff from CATALINA_HOME/conf to
 CATALINA_BASE/conf

You don't need it all. Really, only server.xml is required.

 5. Edit CATALINA_BASE/conf/server.xml a. change the Server port b.
 change HTTP/1.1 connector port c. change the HTTPS connector port
 or comment it out d. change the AJP connector port or comment it
 out 6. Edit tomcat-users.xml 7. Copy over the manager application 
 a. Copy over the application from CATALINA_HOME/webapps - OR - b.
 Create a manager.xml in CATALINA_BASE/conf/Catalina/[hostname]
 
 ?xml version=1.0 encoding=UTF-8? Context docBase=location
 of manager application in CATALINA_HOME 
 antiResourceLocking=false privileged=true useHttpOnly=true/

I've started doing this:

  Context
docBase=${catalina.home}/webapps/manager
...

Since I never deploy from CATALINA_HOME, I can always rely on the
manager sitting there in the webapps/ directory. Actually, in order to
avoid synchronization issues between package-managed manager.xml and
whatever ships with Tomcat, we just wrote an XSL transform that adds a
docBase to the stock
CATALINA_HOME/webapps/manager/WEB-INF/context.xml. So we keep
up-to-date with anything that gets changed in there from release to
release.

 To modify what extra JARs are needed for this CATALINA_BASE, just
 add them to CATALINA_BASE/lib. This way your pristine Tomcat
 remains pristine.

This is the one thing I haven't bothered to do yet for our
deployments. We need a JDBC driver and I usually just drop it into
CATALINA_HOME/lib and call it a day. Many times I've been bitten by
that when I install a new version of Tomcat and try to launch the
webapp, realizing that the JDBC driver wasn't in place.

We don't package-manage the driver and we don't use Maven or anything
like that to go auto-download dependencies or anything crazy like
that, so it's not currently a part of the application build process at
all.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUWApXAAoJEBzwKT+lPKRYEXcP/jCCRuwIxpgt9XcfYrclr8BZ
xGzkqvh8am/Tp/xo980ZuDiLOBLYJdVl0vXmgm0HWHlidpFbqkGJZG8uIDgXDBQ4
qSQGu9InvdwNTgn0sx/tlED9tfS2XDIJno6GUYMetjfaqwmGQEDtsKKdy5ycbigz
xMC91NJEqSgLbcCRp3WOTXGIJPJB14GQtPHGbMU7iOpLXcbxAgE3Ld3Sl2DYzl+H
oafNVVaTglV8ENQbrtKN55bJzco38tEcgJ6IhNbTPZ6XsV/sdwSAzBvrvhmHzPja
uCmnnp/AN9qa+rJUiY+DL9obJef1VxU4PKZ6MtW9PawGlClbQaVGedr/6T7NthjH
ZbJoGVr85KM0cFTYIuys0a4k3u8If1eMoFWXo5jGssAzTfOA10jRyAjByelJbbbT
R+KcZ4PuVOslhXK1J80Di47SEJvMFwdafFUBBRNOBKhv18hB9eeaETacJjB5ChGj
uLk7rdOktoDKmErrvDv5BIw+AhVCTeCP6gwphUZ2sFl6sMan5l8crDOCcfmn+Yod
zhvCOVvhEXaOYW9kXvr3pu3wlxKUzIborxtFnmVlvQMXMeBfJ6XqfK/vmBqrZK2V
8zHnn+eYZ4T/ClTKNxYdfu4Q5pHe1EDTxHP50bTET7zHHqtc25XCZfTHrmQwJJB9
bcEbkdyqN7hzqrRftt33
=vA7W
-END PGP SIGNATURE-

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

Re: Separation of CATALINA_HOME and CATALINA_BASE

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 11/3/14 5:46 PM, Mark Eggers wrote:
 One of the issues I did run into when using tcnative-1.dll is that
 I got the following error message:
 
 12.0.0.1 is not a recognized command, and Tomcat failed to start.
 
 Moving tcnative-1.dll out of the bin directory fixed the problem.
 When I specified JRE_HOME in setenv.bat, that also fixed the
 problem and allowed me to use tcnative-1.dll.
 
 I suspect some brokenness in the way NetBeans is handling the
 JRE_HOME environment variable, since I do have that set
 system-wide.

That's weird. It looks like someone a) mistyped 127.0.0.1 for
localhost and b) a script isn't working properly.

Is this Netbeans-only, or does it happen with a stock Tomcat?

It's also odd that it has something to do with using tcnative at the
same time.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUWAr3AAoJEBzwKT+lPKRYou0P/1hnUCigz86EW8OsbNM68VG+
WXpaQOR389GL6t9WUjfaYg9wvkV4r7IbVwPIBGs9NNYtQjBP/TOrwq392smcuHL8
lsFVy1t4dOsjMeVv68wEBXylmoNY/4hnkuGK2Z9Qt28lBMgnEcvGRWaFcgMDNHiZ
JsoXqTWmj8TfthZ02b+tklbIxIJizDTjPJcgnIxjGBHkjxCSplTODXNPkusmgc+x
ddwGIGHyxYTT89z6OwONhKrlGON7m2NEmqHu9ggbBp4k6QCjBM917GSPHLqYumAt
Z601xOZmJC/RX8sQbkQHSYTAX/oIQvR4ypH4J5pfZ3DidZtyIwmpSPVgy0vXTs3D
B+iialoheRcE8Nldb4apGk4W3pZ1L5agz19Ru037soUxXWqwxEJtp38w5VzX4TcQ
P8Qfd69l90N0ecA02qX+IJ3wnZmFtxLUb/c/XboABj0nWt8tOD8dQ+rEoKALUYMT
aUKXATM+PwuT4z/QcYgcUFcdusHbwlVmftQSD4Atgo87hc4/+yDG4ryswhCodW2O
R89KaQeDr4a8BQP4NmzD4XWgiH4ymSrBpXipaSxeoKq3eCI6ZubSNm8M9X1CF0E3
eqKNoBCmf9qtAA7m0Ku8dExJhtFfQtZCTiy0By+b5W2aV2BGU26ze3W2KNbh6ki/
q9NXGe01Z36YQMMavTYu
=Zo4E
-END PGP SIGNATURE-

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

Re: Separation of CATALINA_HOME and CATALINA_BASE

2014-11-03 Thread Neven Cvetkovic

Chris, Leo, Vince,

On Mon, Nov 3, 2014 at 5:42 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 So, that's not all that complicated when you think about it, but
  to ask someone who knows nothing about a command-line, working
  effectively in an operating system, etc. and only knows about
  programming in Java -- maybe only servlet programming in Java --
  to configure the server in the split case is confusing as all
  hell.


+1


 
  Anyone downloading a ZIP or tar archive containing a Tomcat
  installation would be confused if the archive contained not one
  but two top-level directories. Also, it would overwrite your
  split-configuration if you unpacked that archive in the same
  directory as when you first started.


+1

 An installer program would have to explain what in the world the
  split configuration was. Have you ever tried to tell someone how
  to set up their email? POP versus IMAP? Most users have
  absolutely no idea what that is, and mail programs give no clue
  as to which one to choose. The same would be true of
  CATALINA_HOME versus CATALINA_BASE.
 
 
  Everything has some degree of learning.  New people are trying to
  learn two things at once, how something works as well as the why
  do it this way conventions that experienced users have
  implemented.  New users don't understand the convention and want to
  learn it the hard way first before they can appreciate or even
  understand the convention.

 Agreed. The point I'm trying to make is that experts are experts
 because they have learned. Peeling-back the covers of Tomcat reveals
 those expert features like a split configuration. Being forced to use
 a split-configuration because it's what experts do is one sure way
 to generate a lot of noise on this mailing list.


+1


  I value my sleep and prefer to build new things instead of
  holding together configurations with chewing gum and duct tape.
  Oh, and rebooting all the time.)
 
  Anyhow, we can debate this all you want, but I will be -0 or even
  -1 to a default split-configuration of Tomcat unless someone has
  a really good idea for how to make it make sense to anyone on
  their first-touch.
 
  - -chris
 
 
  I would rather just point (windows) people to an example of a
  split configuration or any other configuration and let them
  implement it if they choose to do so, instead of getting Tomcat
  pre-configured. Part of the draw to Tomcat is that you have
  flexibility with how you choose to run it (script, service, windows
  installer, etc)

 +1


+1

Vince, the current configuration works great:

1) If you are a newbie administrator you are going to use
easy-to-use-newbie-friendly configuration. It will get you started, it
will get your application working, etc... Great starting point.

2) If you are developer (newbie or expert) and using IDE (Eclipse,
Netbeans, IntelliJ) - you are going to use out-of-box tomcat configuration.
Single Tomcat instance, no-split configuration.

3) If you are administrator that is upgrading Tomcat, you will just create
a process to configure your instance with new Tomcat binaries and copy over
the configuration file (most of the stuff is backwards compatible in
server.xml within the point-version) + add any shared libraries to new
tomcat/lib folder (JDBC drivers, etc...). Again, single-tomcat instance,
no-split configuration necessary. Although, may people do like to split for
easier upgrades and separation of concerns.

4) If you are administrator that is managing multi-instance environment,
you can still get away with copying standard out-of-box Tomcat directory
over and over again, for each instance separately. The hassle would be to
do the upgrades on many instances. That's why we have CATALINA_HOME for
shared stuff (binaries+libraries) and CATALINA_BASE for instance-specific
configuration. And in this case you would know about the split directory
setup option and would research how to do that effectively.

My question is - why do you use CATALINA_BASE if you are using IDE
(Netbeans)? If you are developer, there is no need to use split
configuration.


SLIGHTLY-OFFTOPIC:

Although, I would love to see out-of-box setup for additional shared-lib
folder, something other than TOMCAT/lib with Tomcat default libraries.
Essentially, I would love to separate my customer shared libraries from
Tomcat default libraries. I guess - question would be where are
CATALINA_HOME/lib JAR files being loaded from? Can we add another directory
to scan for libraries to be loaded? Is that configurable?

Cheers!
Neven

Re: Separation of CATALINA_HOME and CATALINA_BASE

2014-11-03 Thread Neven Cvetkovic

Reply-to-my question:

On Mon, Nov 3, 2014 at 6:42 PM, Neven Cvetkovic neven.cvetko...@gmail.com
wrote:


 SLIGHTLY-OFFTOPIC:

 Although, I would love to see out-of-box setup for additional shared-lib
 folder, something other than TOMCAT/lib with Tomcat default libraries.
 Essentially, I would love to separate my customer shared libraries from
 Tomcat default libraries. I guess - question would be where are
 CATALINA_HOME/lib JAR files being loaded from? Can we add another directory
 to scan for libraries to be loaded? Is that configurable?



I guess, it's easy to add new directories to
TOMCAT/conf/catalina.properties file:

common.loader=
${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar


to now read:

common.loader=
${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar,${catalina.base}/shared,${catalina.base}/shared/*.jar,${catalina.home}/shared,${catalina.home}/shared/*.jar



What are you thoughts? Would it make sense to keep a separate directory for
shared libraries? Should we make it default - to encourage others to create
a directory if they want to. Default behaviour for
org.apache.catalina.startup.ClassLoaderFactory is to validate if the file
exists/isDirectory/isReadable? That might confuse beginners with a Warning
...


I guess Tomcat philosophy is to keep it simple, and extensible - so experts
that need to customize things they can, and it is simple and not confusing
for beginners.

What are your thoughts?

Cheers!
Neven

RE: Separation of CATALINA_HOME and CATALINA_BASE

2014-10-17 Thread vince.webb

I don’t see their separation as being incompatible with running from a default 
shell or batch file.

It already figures out where to use for CATALINA_HOME, the default place for 
CATALINA_BASE could be a standard difference from CATALINA_HOME, for example:
CATALINA_BASE=$CATALINA_HOME/../catalina_base

I imagine this could work OK directly from an extracted tar distribution as it 
does now. 

I don't know how much difficulty this would cause for IDE plugin's, they might 
end up needing less code rather than more.

Vince

-Original Message-
From: Mark Eggers [mailto:its_toas...@yahoo.com.INVALID] 
Sent: 16 October 2014 20:07
To: Tomcat Users List
Subject: Re: Separation of CATALINA_HOME and CATALINA_BASE

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Konstantin,

On 10/16/2014 11:52 AM, Konstantin Kolinko wrote:
 2014-10-16 22:11 GMT+04:00  vince.w...@thomsonreuters.com:
 Hello I'm coming back to Tomcat after years using GlassFish. The 
 little that I ever understood of Tomcat 3, 4 and 5 is now decidedly 
 rusty so I've been reading Tomcat 7's RUNNING.txt with interest.
 
 The section under the heading: Advanced Configuration - Multiple 
 Tomcat Instances Looks interesting to me even though I have no desire 
 to run multiple instances.
 
 Configuring CATALINA_HOME and CATALINA_BASE to be separate 
 directories looks to me like such a winning idea that I'm left 
 wondering, why the default TOMCAT installation puts all that stuff in 
 one directory ?
 
 I have not looked to see if Tomcat 8 separates them.
 
 1) The default distributive is friendly to newbies. If you just run 
 startup.sh (startup.bat) it assumes that CATALINA_HOME == 
 CATALINA_BASE == its parent directory and starts successfully.
 
 If you separate home and base you have to pass them as environment 
 variables to the scripts. That requires a bit more of configuration 
 from the users.
 
 2) On productive systems you usually configure CATALINA_BASE once 
 (your site) and install a new CATALINA_HOME with each point release.
 
 Even if some files such as webapps are not used in the home 
 directory in this configuration, it may be useful to have them for 
 reference.
 
 http://tomcat.apache.org/migration.html#Before_upgrading_or_migrating

 
http://tomcat.apache.org/migration-8.html#Upgrading_8.0.x
 
 3) Many 3rd parties (Linux vendors) redistribute Tomcat with separate 
 home and base directories.
 
 Best regards, Konstantin Kolinko

I think that the combined approach is useful in a number of scenarios.

1. Newbie-friendly

Just unzip (untar, install) and go. With the installer I suppose you could have 
it query where CATALINA_BASE and CATALINA_HOME are to be placed, so the 
environment variables are constructed and placed in setenv.(bat/sh).

If you use the archive rather than the installer, it's up to the user to figure 
this out.

2. IDE-friendly

NetBeans works well with the combined approach. It even uses the standard 
manager-script role for deployment.

Eclipse is not quite as nice, but again using the combined version makes 
integrating Tomcat with Eclipse as painless as it can be.

IntelliJ seems to fit in between NetBeans and Eclipse in terms of Tomcat 
integration friendliness, and I don't know how it would be impacted by a 
default separation.

Most developers are not very comfortable with administrative tasks (as most 
administrators are not very comfortable with developer tasks), so placing an 
additional barrier for developers would not be welcomed by many.

3. Differing install scenarios

Finally, I can see a scenario somewhat like the following:

a. explode a standard Tomcat distribution b. add a single web application - one 
per Tomcat c. package the result back up d. write a Chef cookbook for deploying 
this to 100s of machines

For a large environment with clustered applications, this may be the way to go. 
It's facilitated (somewhat) by the combined approach.

. . . just some ramblings
/mde/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBAgAGBQJUQBdSAAoJEEFGbsYNeTwtqLAIAJvDJxiS1eOHtV1XF1Dfezr1
u+Kom0QeROZ8XEKfcgYvS6Ig72UOFEsREdMvbUv6YfAGP9zZPagb4hvNfAsE4M3Q
9zzpgZovNXl94ZEDi9shcJqJg+oxFVvrzNHPDMryLIou1YmNJdOSbszeC4zgIge2
grYP4xqlMO8VqUTT1eNVbrtoDyEdjGxAJB9BkR+lYPw+tSqFq9u8C2EtRD2lBn7f
EA97uE5qYLtoj69sI6ThRc26ox2ZtSiWv0ghwanJP8FhtnT7lLd47A+2GndFbxhx
gSRa0z/AHM9x0qI71VyoJfKL41vZGaDZmuPDLU//BF429LfeYzEBOfVSIAmG9R0=
=/suK
-END PGP SIGNATURE-

Separation of CATALINA_HOME and CATALINA_BASE

2014-10-16 Thread vince.webb

Hello
I'm coming back to Tomcat after years using GlassFish. The little that I ever 
understood of Tomcat 3, 4 and 5 is now decidedly rusty so I've been reading 
Tomcat 7's RUNNING.txt with interest.

The section under the heading:
Advanced Configuration - Multiple Tomcat Instances
Looks interesting to me even though I have no desire to run multiple instances.

Configuring CATALINA_HOME and CATALINA_BASE to be separate directories looks to 
me like such a winning idea that I'm left wondering, why the default TOMCAT 
installation puts all that stuff in one directory ?

I have not looked to see if Tomcat 8 separates them.

I welcome your thoughts.

Vince



This e-mail is for the sole use of the intended recipient and contains 
information that may be privileged and/or confidential. If you are not an 
intended recipient, please notify the sender by return e-mail and delete this 
e-mail and any attachments. Certain required legal entity disclosures can be 
accessed on our website.http://thomsonreuters.com/prof_disclosures/

Re: Separation of CATALINA_HOME and CATALINA_BASE

2014-10-16 Thread Mark Thomas

On 16/10/2014 19:11, vince.w...@thomsonreuters.com wrote:
 Hello
 I'm coming back to Tomcat after years using GlassFish. The little that I ever 
 understood of Tomcat 3, 4 and 5 is now decidedly rusty so I've been reading 
 Tomcat 7's RUNNING.txt with interest.
 
 The section under the heading:
 Advanced Configuration - Multiple Tomcat Instances
 Looks interesting to me even though I have no desire to run multiple 
 instances.
 
 Configuring CATALINA_HOME and CATALINA_BASE to be separate directories looks 
 to me like such a winning idea that I'm left wondering, why the default 
 TOMCAT installation puts all that stuff in one directory ?

I'm not sure that is any reason other than it has always been that way.

It is something to consider for 9.0.x (work starting on that soon). An
interesting question here is how smart should we / could we make the
Windows installer?

 I have not looked to see if Tomcat 8 separates them.

It doesn't.

Mark


 
 I welcome your thoughts.
 
 Vince
 
 
 
 This e-mail is for the sole use of the intended recipient and contains 
 information that may be privileged and/or confidential. If you are not an 
 intended recipient, please notify the sender by return e-mail and delete this 
 e-mail and any attachments. Certain required legal entity disclosures can be 
 accessed on our website.http://thomsonreuters.com/prof_disclosures/
 


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

Re: Separation of CATALINA_HOME and CATALINA_BASE

2014-10-16 Thread Konstantin Kolinko

2014-10-16 22:11 GMT+04:00  vince.w...@thomsonreuters.com:
 Hello
 I'm coming back to Tomcat after years using GlassFish. The little that I ever 
 understood of Tomcat 3, 4 and 5 is now decidedly rusty so I've been reading 
 Tomcat 7's RUNNING.txt with interest.

 The section under the heading:
 Advanced Configuration - Multiple Tomcat Instances
 Looks interesting to me even though I have no desire to run multiple 
 instances.

 Configuring CATALINA_HOME and CATALINA_BASE to be separate directories looks 
 to me like such a winning idea that I'm left wondering, why the default 
 TOMCAT installation puts all that stuff in one directory ?

 I have not looked to see if Tomcat 8 separates them.

1) The default distributive is friendly to newbies. If you just run
startup.sh (startup.bat) it assumes that CATALINA_HOME ==
CATALINA_BASE == its parent directory and starts successfully.

If you separate home and base you have to pass them as environment
variables to the scripts. That requires a bit more of configuration
from the users.

2) On productive systems you usually configure CATALINA_BASE once
(your site) and install a new CATALINA_HOME with each point release.

Even if some files such as webapps are not used in the home
directory in this configuration, it may be useful to have them for
reference.

http://tomcat.apache.org/migration.html#Before_upgrading_or_migrating
http://tomcat.apache.org/migration-8.html#Upgrading_8.0.x

3) Many 3rd parties (Linux vendors) redistribute Tomcat with separate
home and base directories.

Best regards,
Konstantin Kolinko

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

Re: Separation of CATALINA_HOME and CATALINA_BASE

2014-10-16 Thread Mark Eggers

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Konstantin,

On 10/16/2014 11:52 AM, Konstantin Kolinko wrote:
 2014-10-16 22:11 GMT+04:00  vince.w...@thomsonreuters.com:
 Hello I'm coming back to Tomcat after years using GlassFish. The
 little that I ever understood of Tomcat 3, 4 and 5 is now
 decidedly rusty so I've been reading Tomcat 7's RUNNING.txt with
 interest.
 
 The section under the heading: Advanced Configuration - Multiple
 Tomcat Instances Looks interesting to me even though I have no
 desire to run multiple instances.
 
 Configuring CATALINA_HOME and CATALINA_BASE to be separate
 directories looks to me like such a winning idea that I'm left
 wondering, why the default TOMCAT installation puts all that
 stuff in one directory ?
 
 I have not looked to see if Tomcat 8 separates them.
 
 1) The default distributive is friendly to newbies. If you just
 run startup.sh (startup.bat) it assumes that CATALINA_HOME == 
 CATALINA_BASE == its parent directory and starts successfully.
 
 If you separate home and base you have to pass them as
 environment variables to the scripts. That requires a bit more of
 configuration from the users.
 
 2) On productive systems you usually configure CATALINA_BASE once 
 (your site) and install a new CATALINA_HOME with each point
 release.
 
 Even if some files such as webapps are not used in the home 
 directory in this configuration, it may be useful to have them for 
 reference.
 
 http://tomcat.apache.org/migration.html#Before_upgrading_or_migrating

 
http://tomcat.apache.org/migration-8.html#Upgrading_8.0.x
 
 3) Many 3rd parties (Linux vendors) redistribute Tomcat with
 separate home and base directories.
 
 Best regards, Konstantin Kolinko

I think that the combined approach is useful in a number of scenarios.

1. Newbie-friendly

Just unzip (untar, install) and go. With the installer I suppose you
could have it query where CATALINA_BASE and CATALINA_HOME are to be
placed, so the environment variables are constructed and placed in
setenv.(bat/sh).

If you use the archive rather than the installer, it's up to the user
to figure this out.

2. IDE-friendly

NetBeans works well with the combined approach. It even uses the
standard manager-script role for deployment.

Eclipse is not quite as nice, but again using the combined version
makes integrating Tomcat with Eclipse as painless as it can be.

IntelliJ seems to fit in between NetBeans and Eclipse in terms of
Tomcat integration friendliness, and I don't know how it would be
impacted by a default separation.

Most developers are not very comfortable with administrative tasks (as
most administrators are not very comfortable with developer tasks), so
placing an additional barrier for developers would not be welcomed by
many.

3. Differing install scenarios

Finally, I can see a scenario somewhat like the following:

a. explode a standard Tomcat distribution
b. add a single web application - one per Tomcat
c. package the result back up
d. write a Chef cookbook for deploying this to 100s of machines

For a large environment with clustered applications, this may be the
way to go. It's facilitated (somewhat) by the combined approach.

. . . just some ramblings
/mde/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBAgAGBQJUQBdSAAoJEEFGbsYNeTwtqLAIAJvDJxiS1eOHtV1XF1Dfezr1
u+Kom0QeROZ8XEKfcgYvS6Ig72UOFEsREdMvbUv6YfAGP9zZPagb4hvNfAsE4M3Q
9zzpgZovNXl94ZEDi9shcJqJg+oxFVvrzNHPDMryLIou1YmNJdOSbszeC4zgIge2
grYP4xqlMO8VqUTT1eNVbrtoDyEdjGxAJB9BkR+lYPw+tSqFq9u8C2EtRD2lBn7f
EA97uE5qYLtoj69sI6ThRc26ox2ZtSiWv0ghwanJP8FhtnT7lLd47A+2GndFbxhx
gSRa0z/AHM9x0qI71VyoJfKL41vZGaDZmuPDLU//BF429LfeYzEBOfVSIAmG9R0=
=/suK
-END PGP SIGNATURE-

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

RE: Separation of CATALINA_HOME and CATALINA_BASE

2014-10-16 Thread vince.webb

Mark
Thank you for such a quick response. 

Personally I don't have much interest in Tomcat's Windows installer. I am more 
interested in the directory structure that you get from expanding 
apache-tomcat-nnn.tar.gz

Vince

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: 16 October 2014 19:44
To: Tomcat Users List
Subject: Re: Separation of CATALINA_HOME and CATALINA_BASE

On 16/10/2014 19:11, vince.w...@thomsonreuters.com wrote:
 Hello
 I'm coming back to Tomcat after years using GlassFish. The little that I ever 
 understood of Tomcat 3, 4 and 5 is now decidedly rusty so I've been reading 
 Tomcat 7's RUNNING.txt with interest.
 
 The section under the heading:
 Advanced Configuration - Multiple Tomcat Instances Looks interesting 
 to me even though I have no desire to run multiple instances.
 
 Configuring CATALINA_HOME and CATALINA_BASE to be separate directories looks 
 to me like such a winning idea that I'm left wondering, why the default 
 TOMCAT installation puts all that stuff in one directory ?

I'm not sure that is any reason other than it has always been that way.

It is something to consider for 9.0.x (work starting on that soon). An 
interesting question here is how smart should we / could we make the Windows 
installer?

 I have not looked to see if Tomcat 8 separates them.

It doesn't.

Mark


 
 I welcome your thoughts.
 
 Vince
 
 
 
 This e-mail is for the sole use of the intended recipient and contains 
 information that may be privileged and/or confidential. If you are not 
 an intended recipient, please notify the sender by return e-mail and 
 delete this e-mail and any attachments. Certain required legal entity 
 disclosures can be accessed on our 
 website.http://thomsonreuters.com/prof_disclosures/
 


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


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

Re: Separation of CATALINA_HOME and CATALINA_BASE

2014-10-16 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 10/16/14 2:43 PM, Mark Thomas wrote:
 On 16/10/2014 19:11, vince.w...@thomsonreuters.com wrote:
 Hello I'm coming back to Tomcat after years using GlassFish. The
 little that I ever understood of Tomcat 3, 4 and 5 is now
 decidedly rusty so I've been reading Tomcat 7's RUNNING.txt with
 interest.
 
 The section under the heading: Advanced Configuration - Multiple
 Tomcat Instances Looks interesting to me even though I have no
 desire to run multiple instances.
 
 Configuring CATALINA_HOME and CATALINA_BASE to be separate
 directories looks to me like such a winning idea that I'm left
 wondering, why the default TOMCAT installation puts all that
 stuff in one directory ?
 
 I'm not sure that is any reason other than it has always been that
 way.

It is a bit easier to configure when CATALINA_BASE = CATALINA_HOME,
especially for automated installers as well as the ZIP installer
(aka just unzip into apache-tomcat-x.y.z directory).

 It is something to consider for 9.0.x (work starting on that soon).
 An interesting question here is how smart should we / could we make
 the Windows installer?

If we added CATALINA_BASE ≠ CATALINA_HOME as default, the automated
installer would have to ask where to install Tomcat and also where to
install Tomcat's first deployment, which would be a bit confusing to
people. The ZIP installer would need to have apache-tomcat-x.y.z
plus something like apache-tomcat-deploy inside of it with Tomcat
defaulting to use that as CATALINA_BASE.

I don't see it working for novice users, and I don't see it working
for advanced users, either, because they already know what they are doing.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUQDJvAAoJEBzwKT+lPKRYsY4P/36Dcuq0+2L1nL7LdGJus6+p
5VkJvzmlwFY3pfRNR4MHsXjEu8iBJV/QwDoplivZHd3KhcjoxGC8R6HKYeVHGub/
kSN1xeRqyPF1pqUJw7ejGKQaHP17UI4YeygxYCb4AKkh+L02Tkdsn+/JFGG5URmA
NWlXFygxIE52HyXXfdEoV2KRY6M7frB2AFIVXOD/TpW36EO+O3QecCHQDTRZRDv1
1o5TQI++DzQeL/eBVYGg7bu/bC8jPAWC5cDBoQXE/H+iqBHbr9+C8tsSGEiYxZS+
mzC/UKhnfnNAp8PqzyLN/qLncwITE2A3QWxkDqFrk1sLlcKO2b2iXCkG+BiOewVw
Iv1x8PJihvE9Tz7YZyv1MC6tVUZq5lBBviOfW+M2iHGPM5gy6j2gYMq1cxlTi1rD
B2rs/0Ues0PPG7PjwDnSazZQtRrbiKYFIpLca8abgGQ8AUPlFqDtl7EN2azt+xjf
Tc07l1W+86JZIkXUvcKbACkHcsHQg2bCcJtnIVaNfkwUnkVIHll/OyffgE53tL7W
xzoBMGzxPNyp96mrvEbXhq+nyHRL+BCkEJDcbK2XSGKZWGTgWOxD4RUm9KUW3pNc
orH8p7YQ7bj2PwQV3qZktDQ1dJw0IPLdbkhX3Nbr5Lp/80eCZXa9BFnrRjgQsgd6
Xv94kVsiBJvoh84wzViV
=XhYF
-END PGP SIGNATURE-

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

Re: $CATALINA_HOME/conf/context.xml .. restrict a context?

2014-03-04 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ravi,

On 3/3/14, 5:53 PM, Ravi Gupta wrote:
 Any idea if the same would work for JBOSS 5.X (uses tomcat under
 the hood)? perhaps it is not the same, but I tried putting 
 admin-console.xml under
 jboss-5.1.0.GA/server/default/deploy/jbossweb.sar it contains 
 Context path=/admin-console Valve
 className=org.apache.catalina.valves.RemoteAddrValve deny=* / 
 /Context
 
 But I was still able to access http://localhost:8080/admin-console
 after a bounce?
 
 Any suggestions would be apreciated

Take a look at the documentation for RemoteAddrValve, particularly the
deny attribute. You have configured this incorrectly.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTFhy0AAoJEBzwKT+lPKRYAvYP/jfH/uFLLSthgf6O+rGh6/Dy
nCYOOmsxG2O8Pc7g26mm75Zz7n1zctq7Bsbz/UNM0nwBbAI3kVwCAJIlQqHb5CxY
qdaZu/B2YqB6xzMAYbdtrQ8io0i3uVPBqKM2K8pvccFhxdWlvfQtbTWIDtlbofaP
Y9cRKWqQFge6BQKQDjeHFgA01htZcwD6+Tm6ckjjQfDGxFXoWIbKEWNxwROhu0zn
6gD97iO9DNAmDbTfrMDX4QfT9jvu2RgtZ+MilUHHEXpKAnVagMmznvbG0pt3CzoL
1g6oGLZJMtiJkNMDQEfU9gtxR/avYBiNCc+UcNz7n+Lb08CzeWrNT5rn/baPV+84
HHXNvw/qCihy0VSKVwnBQ/iewTKysRW5rmO4b8tGR1vvx46kignONMnP74ySL/xC
wjTFIOMcoHTdrLVj3QwifxZqHtxsYF2MGbXjhLfFaqsgKiCneP5oT9BfvoDPUCel
AX4+J/8V3bFZhpdG/5yzQgMkzQOfqCYbkpdfoJIn3PPXJoyAamCe2PeIQ9bgKrnb
SDUgQQoEIuIqYqxLTF+cfT25FDrRrJmwc/z9z8+FLnPp+ld7t5jNdN38L4CW98TO
vuIdXRPT0fEq2WW/XQLG1xDtO4RUJfZUVHCy4N2EGxrC+jiLVH5YKRDD6it+4sOW
T6Bhqe9hES30N5SQ1HSo
=v1We
-END PGP SIGNATURE-

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

$CATALINA_HOME/conf/context.xml .. restrict a context?

Tomcat 6.X
RHEL


I tried adding the below in order to limit access to /admin-console



It worked, but it limits access to EVERY context, which is odd. I am sure I
am doing something wrong or I misunderstand how this works

I want to put restrictions on the /admin-console context, but I do not want
it inside the admin-console.war

 Again, this works, but other contexts are denied as well!

Context path=/admin-console



  Valve className=org.apache.catalina.valves.RemoteAddrValve

  deny=* /



/Context

Re: $CATALINA_HOME/conf/context.xml .. restrict a context?

2014-03-03 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ravi,

On 3/3/14, 5:10 PM, Ravi Gupta wrote:
 Tomcat 6.X RHEL
 
 I tried adding the below in order to limit access to
 /admin-console
 
 It worked, but it limits access to EVERY context, which is odd. I
 am sure I am doing something wrong or I misunderstand how this
 works
 
 I want to put restrictions on the /admin-console context, but I do
 not want it inside the admin-console.war
 
 Again, this works, but other contexts are denied as well!
 
 Context path=/admin-console Valve
 className=org.apache.catalina.valves.RemoteAddrValve deny=* / 
 /Context

I'm guessing the file you edited was CATALINA_BASE/conf/context.xml?

That's not the right file to edit. Undo all the changes you made to
conf/context.xml.

Instead, you want to edit the META-INF/context.xml file in your own
webapp (or CATALINA_BASE/conf/[engine]/[host]/admin-console.xml if you
have manually-deployed your application using an XML descriptor).

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTFQCoAAoJEBzwKT+lPKRYGXQQAKgWOzPpKvC9YvuSJWdDY5Ud
325eSaK73rns77SWz2nUFt3je5GTEFmQAuCyBHueeaGgaFsY9GrkE9/YtsuWxB52
gO22zYywmTtfSY4MNt5z4dolbWfkktcFkLA96FQxa4ZI7ZdvmyL4XRRPJSSKRck3
qushWLC5IhbTknnbbOFm3OAv/xY60dzorB8ashIDjMO1Rm+6xOWf2x3PeTAeuy8K
h5rKVi1u2KkMnbMtvJABX2WGdYZA+r/LNozotXHDGApvEVFu4+YtRWpZx2kgeVVG
0pbgLlfmT3cltDGkfOLq7xk11/VJNVR/A276naolfA+lWlqg0ccTVy7T/HrYaVZ8
dHXh09GFAgxneC+JCdMzDGFaI1LEhMaDv9OhyEYCOjoz60c1lYg2idfFXffSTiFj
QRgfesyer8jYWD0pyEQ939EOXKLnR2ClbwqkHvXZNKDf8NtitBeF45hUmxixuDhb
GBu+tuBVEHWXJpmCkmh/Xd9iwGPU3w2geGnZXPUpDaERdKlKL/zbzLBpxvP9TpOs
0IMc3ZkZ39jnrMVfDbbloNRKMdbxSSlb/OMyDocZheSLw6QlECALfLZumQZCk759
z5BDS8zvINbpdUrUxLG7ZYTW+6ZXpR7N9nVF+ab2BnTC58J5aUb623FtSOuk1J2/
hMPVhRwdGyHLNccn82t4
=YZJb
-END PGP SIGNATURE-

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

Re: $CATALINA_HOME/conf/context.xml .. restrict a context?

Thanks, the issue is that my customer does not want to restrict the
admin-console in it's war - the rational is anybody can then just redeploy
a new admin-console.war and access it (overwrite the restrictions). They
want to restrict access to this context from OUTSIDE the actual deployment.
Make sense?


On Mon, Mar 3, 2014 at 4:22 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Ravi,

 On 3/3/14, 5:10 PM, Ravi Gupta wrote:
  Tomcat 6.X RHEL
 
  I tried adding the below in order to limit access to
  /admin-console
 
  It worked, but it limits access to EVERY context, which is odd. I
  am sure I am doing something wrong or I misunderstand how this
  works
 
  I want to put restrictions on the /admin-console context, but I do
  not want it inside the admin-console.war
 
  Again, this works, but other contexts are denied as well!
 
  Context path=/admin-console Valve
  className=org.apache.catalina.valves.RemoteAddrValve deny=* /
  /Context

 I'm guessing the file you edited was CATALINA_BASE/conf/context.xml?

 That's not the right file to edit. Undo all the changes you made to
 conf/context.xml.

 Instead, you want to edit the META-INF/context.xml file in your own
 webapp (or CATALINA_BASE/conf/[engine]/[host]/admin-console.xml if you
 have manually-deployed your application using an XML descriptor).

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQIcBAEBCAAGBQJTFQCoAAoJEBzwKT+lPKRYGXQQAKgWOzPpKvC9YvuSJWdDY5Ud
 325eSaK73rns77SWz2nUFt3je5GTEFmQAuCyBHueeaGgaFsY9GrkE9/YtsuWxB52
 gO22zYywmTtfSY4MNt5z4dolbWfkktcFkLA96FQxa4ZI7ZdvmyL4XRRPJSSKRck3
 qushWLC5IhbTknnbbOFm3OAv/xY60dzorB8ashIDjMO1Rm+6xOWf2x3PeTAeuy8K
 h5rKVi1u2KkMnbMtvJABX2WGdYZA+r/LNozotXHDGApvEVFu4+YtRWpZx2kgeVVG
 0pbgLlfmT3cltDGkfOLq7xk11/VJNVR/A276naolfA+lWlqg0ccTVy7T/HrYaVZ8
 dHXh09GFAgxneC+JCdMzDGFaI1LEhMaDv9OhyEYCOjoz60c1lYg2idfFXffSTiFj
 QRgfesyer8jYWD0pyEQ939EOXKLnR2ClbwqkHvXZNKDf8NtitBeF45hUmxixuDhb
 GBu+tuBVEHWXJpmCkmh/Xd9iwGPU3w2geGnZXPUpDaERdKlKL/zbzLBpxvP9TpOs
 0IMc3ZkZ39jnrMVfDbbloNRKMdbxSSlb/OMyDocZheSLw6QlECALfLZumQZCk759
 z5BDS8zvINbpdUrUxLG7ZYTW+6ZXpR7N9nVF+ab2BnTC58J5aUb623FtSOuk1J2/
 hMPVhRwdGyHLNccn82t4
 =YZJb
 -END PGP SIGNATURE-

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

Re: $CATALINA_HOME/conf/context.xml .. restrict a context?

2014-03-03 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ravi,

(Moving the discussion back onto the list: please reply to the list
and not to individuals. That's what community is about.)

On 3/3/14, 5:29 PM, Ravi Gupta wrote:
 Thanks, the issue is that my customer does not want to restrict
 the admin-console in it's war - the rational is anybody can then
 just redeploy a new admin-console.war and access it (overwrite the 
 restrictions). They want to restrict access to this context from
 OUTSIDE the actual deployment. Make sense?

It makes perfect sense.

To deploy your web application in a safe way, you need to do the
following:

0. Start with a stopped Tomcat.
1. Put the WAR wherever you want it to live. CATALINA_BASE/webapps is
fine.
2. Extract META-INF/context.xml from your WAR file and place it in
CATALINA_BASE/conf/[engine]/[host]/[appname].xml
3. Modify [appname].xml to add whatever restrictions you want.
4. Start Tomcat.

If you overwrite the WAR file, the restrictions you have set should be
maintained. Note that if you /undeploy/ the webapp and then redeploy
it, any customizations will be lost and will have to be re-applied.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTFQPbAAoJEBzwKT+lPKRYRmoQALE8fXXv+UVHkMCwzBHHfyvI
FVfO8pxCEk8oxvrMunLjC/E2+O8KVCCSDYEjWYYuQs0L1cKjEWyuF6w0P8QDo6fB
lE1pxuShreC1SMMZBEGf9GX0QORPgAB1C4tFnKEYP7/O/0l0KORGh81/AolhroG+
8UvlNbFeb0LUR/ABHjdc2PN1UVL3FjruFMhkJSu0ZGqK8TpO7D74VWG2B5JD6zy6
ecFKQVSKf7wCLYJ5vXLpyLFJ/H5DKb6c5BBa7L0Edw+bEM8/YM9f7eoXl77TyBup
Lhx19LOzrfFqcDNPXpqiSKy8VCEJH0TNd1iegJwWH4uTK/BYOu38pALspQ6piGjJ
re8/goyGahK4Ii7A7B6463I/WqzuSwYxzoNYOMFd0db3gp5gzCq8u6MUgx1jTupA
iG4f9SvGC4pvytTKujS/c36uHVipn3YbgTZzbsyhUug7VvTn5uSZUN1e68v+y9LA
JV0sLGlzay6STujPamVInO6ICOEiqnY5TuoRoedmlYSLC0dkT5Nvpw9G4trL0WMc
WZLVlKKgd3eQU4hUBNqeVfnlmwRuE2LFwHdAC1TpyWVsHkNaTtcCMq/YMkl+xAD0
4uka25gHs3g+j7KmGvvo4gjnPY1ODfTJbYrAdlhSZoMkuesyAW8gaYqG4NR6FoWm
/tcZDv4FLrEtv5zXrz9l
=L2bz
-END PGP SIGNATURE-

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

Re: $CATALINA_HOME/conf/context.xml .. restrict a context?

Any idea if the same would work for JBOSS 5.X (uses tomcat under the hood)?
perhaps it is not the same, but I tried putting
admin-console.xml under jboss-5.1.0.GA/server/default/deploy/jbossweb.sar
it contains
Context path=/admin-console
  Valve className=org.apache.catalina.valves.RemoteAddrValve deny=* /
/Context

But I was still able to access http://localhost:8080/admin-console after a
bounce?

Any suggestions would be apreciated


On Mon, Mar 3, 2014 at 4:36 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Ravi,

 (Moving the discussion back onto the list: please reply to the list
 and not to individuals. That's what community is about.)

 On 3/3/14, 5:29 PM, Ravi Gupta wrote:
  Thanks, the issue is that my customer does not want to restrict
  the admin-console in it's war - the rational is anybody can then
  just redeploy a new admin-console.war and access it (overwrite the
  restrictions). They want to restrict access to this context from
  OUTSIDE the actual deployment. Make sense?

 It makes perfect sense.

 To deploy your web application in a safe way, you need to do the
 following:

 0. Start with a stopped Tomcat.
 1. Put the WAR wherever you want it to live. CATALINA_BASE/webapps is
 fine.
 2. Extract META-INF/context.xml from your WAR file and place it in
 CATALINA_BASE/conf/[engine]/[host]/[appname].xml
 3. Modify [appname].xml to add whatever restrictions you want.
 4. Start Tomcat.

 If you overwrite the WAR file, the restrictions you have set should be
 maintained. Note that if you /undeploy/ the webapp and then redeploy
 it, any customizations will be lost and will have to be re-applied.

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQIcBAEBCAAGBQJTFQPbAAoJEBzwKT+lPKRYRmoQALE8fXXv+UVHkMCwzBHHfyvI
 FVfO8pxCEk8oxvrMunLjC/E2+O8KVCCSDYEjWYYuQs0L1cKjEWyuF6w0P8QDo6fB
 lE1pxuShreC1SMMZBEGf9GX0QORPgAB1C4tFnKEYP7/O/0l0KORGh81/AolhroG+
 8UvlNbFeb0LUR/ABHjdc2PN1UVL3FjruFMhkJSu0ZGqK8TpO7D74VWG2B5JD6zy6
 ecFKQVSKf7wCLYJ5vXLpyLFJ/H5DKb6c5BBa7L0Edw+bEM8/YM9f7eoXl77TyBup
 Lhx19LOzrfFqcDNPXpqiSKy8VCEJH0TNd1iegJwWH4uTK/BYOu38pALspQ6piGjJ
 re8/goyGahK4Ii7A7B6463I/WqzuSwYxzoNYOMFd0db3gp5gzCq8u6MUgx1jTupA
 iG4f9SvGC4pvytTKujS/c36uHVipn3YbgTZzbsyhUug7VvTn5uSZUN1e68v+y9LA
 JV0sLGlzay6STujPamVInO6ICOEiqnY5TuoRoedmlYSLC0dkT5Nvpw9G4trL0WMc
 WZLVlKKgd3eQU4hUBNqeVfnlmwRuE2LFwHdAC1TpyWVsHkNaTtcCMq/YMkl+xAD0
 4uka25gHs3g+j7KmGvvo4gjnPY1ODfTJbYrAdlhSZoMkuesyAW8gaYqG4NR6FoWm
 /tcZDv4FLrEtv5zXrz9l
 =L2bz
 -END PGP SIGNATURE-

Re: $CATALINA_HOME/conf/context.xml .. restrict a context?