Re: Authentication Memcached + Tomcat

[Nilson Uehara]

2014-11-02 4:34 GMT-02:00 Igor Cicimov icici...@gmail.com:

 On 01/11/2014 6:52 AM, Nilson Uehara nilueh...@gmail.com wrote:
 
  I'm testing Memcached to implement failover on my Tomcat servers.
 
  Is there any way of implementing security by user / password?
 From what I can see here

 https://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration
 the instructions are pretty clear. You need memcache compiled and
 configured with sasl support and thats pretty much it.


I found the solution!
I included memcachedProtocol=binary in the context.xml.

Manager className=de.javakaffee.web.msm.MemcachedBackupSessionManager
memcachedNodes=n1:1.2.3.4:11211
memcachedProtocol=binary
requestUriIgnorePattern=.*\.(png|gif|jpg|css|js|ico)$
username=user
password=123
/

Re: From HTTP to HTTPS request.getHeader(referer)

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Léa,

On 11/2/14 10:07 AM, Léa Massiot wrote:
 Hello Mark, Chris and Terence. Thank you for your answers. After
 reading them and observing a few things I realized that my problem
 is not exactly the one I described at first.
 
 
 Christopher Schultz-2 wrote
 The Referer is going to be the URL that was showing in the web
 browser when the user clicked on the Submit button.
 
 This is right. I hadn't noticed it but the URL which is showing is
 NOT https://host/webapp/example1.jsp. Instead, it is
 https://host/webapp/do_example. So, what I was describing as
 abnormal in my first post is actually normal.

Exactly.

 So the problem is coming from elsewhere...
 
 Before I tried to make the webapp work with HTTPS, I was always
 using calls like these: 
 --

 
response.sendRedirect(example1.jsp);

When sending redirects, you probably always want to:

1. Run the URL through response.encodeRedirectURL
2. Use a URL that starts with /, which is easiest by doing this:

  String url = response.encodeRedirectURL(request.getContextPath()
  + /example1.jsp));

  response.sendRedirect(url);

 --

  Last week, I replaced all these calls with these new ones: 
 --

 
requestDispatcher =
 getServletContext().getRequestDispatcher(/example1.jsp); 
 requestDispatcher.forward(request, response); 
 --

 
(with the appropriate JSP of course).
 
 I made that change because sendRedirect() didn't work with
 HTTPS.

Redirects definitely work with HTTPS. You must be doing something
wrong. Perhaps a configuration mistake with a port number or something
like that.

 I didn't mention this before because I thought it was solving this
 other problem. Instead, it provokes new ones.

Yup.

 What I actually would like is the webapp to behave like before:
 showing JSP page names in the URLs bar instead of URL patterns: 
 in a given servlet, I generally have several forward() calls and
 hence several different .jsp pages to forward to depending on
 what happens inside the servlet. Having all of them replaced by
 something like do_example is kind of not what I had planned. It's
 definitely very problematic.

So use redirects. They should work and you should figure out why they
aren't working. Put your code back the way you had it, take more data,
and post a new question if you need help.

 So, hum, as I didn't asked it at the time: why can't I go on using 
 sendRedirect() along with HTTPS? If I have to use forward(), is
 there any way I could make it behave the way I described above?

When you use a forward, you will always end up with the URL the
client first used as what the client sees. If you want to accept
data (e.g. POST) *and* prepare some data for the next screen to be
seen, consider a POST-then-redirect scheme:

1. Client POSTs to some URL e.g. /do_example
2. /do_example servlet runs and handles the POST data, then
redirect()s to /prepare_view
3. /prepare_view servlet runs and gathers whatever data is appropriate
for the next display screen and forward()s to /example1.jsp

After all that, the user is looking at the URL /prepare_view instead
of /do_example. That way, your referrer for the next POST will be
/prepare_view instead of /do_example.

 Is there another method I could use that would suit my needs?

Your only tools to transfer control (other than direct function calls)
are forward, redirect, and include.

 P.S. For the problem I was posting at first, as I don't really need
 to rely on the referer request header, I can instead, set a
 session attribute in each JSP. In example1.jsp for instance: 
 

 
c:set var=sessAtt
 value=example1.jsp scope=session/c:set 
 

 
When in the doPost() method of the servlet, I'll know which JSP form what
 submitted...

What if the user hits the BACK button and looks at a previous page,
then re-submits that old page? Your server thinks that the source page
was example1.jsp but the client actually posted example0.jsp or
something else...

Web application workflow management is non-trivial.

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

iQIcBAEBCAAGBQJUV6CAAAoJEBzwKT+lPKRY9zcQAIpXKkNLAq/TVtm9EiRkDHQs
boOAcbNluN0D9wK+V94aQTRF1iSFblpaNv6Tr/mmE3hM5c2tuUAxlq3tNAKz9zyn
ltzS8w87Zu7zad4i/kZZXKo3IpmpWz8NkWORlHwF4yQQUC/IhtYBxB7nq+7nVfDG
aSdKa77rBE6DHklBYutvjdDc2HeYx2B4IgzbYuPGBPEqMKASfhIoxRp51B/lwjEF
Zs4TTuiL4SziP/luFBV/GK5kFiPMsEyZhr3YmOi23z44doIgvet89nwOr6im8OEf
eFMIyBhos55A3Yc6NEREhyJSBbHbBHIV0cmXxS0qWrsMcj6BEn/Dl6tTyTKyWt1M

Re: From HTTP to HTTPS request.getHeader(referer)

[Léa Massiot]

Hi, thank you for your answer.

 On 2014-11-03 4:34 PM, Christopher Schultz wrote:
 Redirects definitely work with HTTPS. You must be doing something
 wrong. Perhaps a configuration mistake with a port number or something
 like that.

My configuration in Tomcat 7.0.55 server.xml is:
(
- basically it is the same as the one packaged in the Tomcat distribution, I
only changed the connectors ;
- I removed all the comments and I'm testing on localhost for this config.
)
-
?xml version='1.0' encoding='utf-8'?
Server port=8005 shutdown=SHUTDOWN
  Listener className=org.apache.catalina.core.AprLifecycleListener
SSLEngine=on /
  Listener className=org.apache.catalina.core.JasperListener /
  Listener
className=org.apache.catalina.core.JreMemoryLeakPreventionListener /
  Listener
className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener /
  Listener
className=org.apache.catalina.core.ThreadLocalLeakPreventionListener /

  GlobalNamingResources
Resource name=UserDatabase auth=Container
  type=org.apache.catalina.UserDatabase
  description=User database that can be updated and saved
  factory=org.apache.catalina.users.MemoryUserDatabaseFactory
  pathname=conf/tomcat-users.xml /
  /GlobalNamingResources

  Service name=Catalina





Connector port=443
   keystoreFile=where/the/ssl/keystore/is/kstore.txt
   keystorePass=example
   SSLEnabled=true
   acceptCount=100
   clientAuth=false
   disableUploadTimeout=true
   enableLookups=false
   maxThreads=25
   protocol=org.apache.coyote.http11.Http11NioProtocol
   scheme=https
   secure=true
   sslProtocol=TLS /

Connector port=80 enableLookups=false redirectPort=443/

Connector port=8009 protocol=AJP/1.3 redirectPort=443 /
   

Engine name=Catalina defaultHost=localhost

  Realm className=org.apache.catalina.realm.LockOutRealm
Realm className=org.apache.catalina.realm.UserDatabaseRealm
   resourceName=UserDatabase/
  /Realm

  Host name=localhost  appBase=webapps
unpackWARs=true autoDeploy=true

Valve className=org.apache.catalina.valves.AccessLogValve
directory=logs
   prefix=localhost_access_log. suffix=.txt
   pattern=%h %l %u %t quot;%rquot; %s %b /

  /Host
/Engine
  /Service
/Server
-

As for the webapp I would like to HTTPS serve, I only added what follows
to its web.xml:
-
  security-constraint
web-resource-collection
web-resource-namesecuredapp/web-resource-name
url-pattern/*/url-pattern
/web-resource-collection
user-data-constraint
transport-guaranteeCONFIDENTIAL/transport-guarantee
/user-data-constraint
  /security-constraint
-

Is there something wrong or missing?

 On 2014-11-03 4:34 PM, Christopher Schultz wrote:
 So use redirects. They should work and you should figure out why they
 aren't working. Put your code back the way you had it, take more data,
 and post a new question if you need help.

Ok. Thank you.
I restored the sendRedirect() calls I was making at first.
I proceeded like I described in my last post: passing complete URLs to the
sendRedirect() methods (ex.
sendRedirect(https://host/webapp/example.jsp;);).
As a reminder, before, I used to pass only the JSP page name as an argument
to the sendRedirect() method (ex. sendRedirect(example.jsp);).
It looks like that the webapp is now working nicely.
I noticed your comment about encodeRedirectURL(). Thanks for mentioning it.

 When you use a forward, you will always end up with the URL the
 client first used as what the client sees. If you want to accept
 data (e.g. POST) *and* prepare some data for the next screen to be
 seen, consider a POST-then-redirect scheme:

 1. Client POSTs to some URL e.g. /do_example
 2. /do_example servlet runs and handles the POST data, then
 redirect()s to /prepare_view
 3. /prepare_view servlet runs and gathers whatever data is appropriate
 for the next display screen and forward()s to /example1.jsp

 After all that, the user is looking at the URL /prepare_view instead
 of /do_example. That way, your referrer for the next POST will be
 /prepare_view instead of /do_example.

Thank you. It's interesting.

 What if the user hits the BACK button and looks at a previous page,
 then re-submits that old page? Your server thinks that the source page
 was example1.jsp but the client actually posted example0.jsp or
 something else...

 Web application workflow management is non-trivial.

Yes, it's tricky.

Best 

troubleshoot tomcat database connection

[Mark Maciolek]

hi,

system is running Scientific Linux release 6.5
rpm installed

tomcat6-servlet-2.5-api-6.0.24-78.el6_5.noarch
tomcat6-javadoc-6.0.24-78.el6_5.noarch
tomcat6-lib-6.0.24-78.el6_5.noarch
tomcat-native-1.1.30-1.el6.x86_64
tomcat6-el-2.1-api-6.0.24-78.el6_5.noarch
tomcat6-admin-webapps-6.0.24-78.el6_5.noarch
apache-tomcat-apis-0.1-1.el6.noarch
tomcat6-jsp-2.1-api-6.0.24-78.el6_5.noarch
tomcat6-webapps-6.0.24-78.el6_5.noarch
tomcat-servlet-3.0-api-7.0.33-4.el6.noarch
tomcat6-6.0.24-78.el6_5.noarch
tomcat6-docs-webapp-6.0.24-78.el6_5.noarch

httpd-2.2.15-31.sl6.x86_64

tomcat starts and I can reach the page on the 8080 port

It never starts the connection host name connection from the server.xml

I do a kill -3 on the tomcat pid and this is what the logs shows:

INFO: Starting Servlet Engine: Apache Tomcat/6.0.24
Nov 3, 2014 1:19:10 PM org.apache.catalina.startup.HostConfig 
deployDescriptor

INFO: Deploying configuration descriptor host-manager.xml
Nov 3, 2014 1:19:10 PM org.apache.catalina.startup.HostConfig 
deployDescriptor

INFO: Deploying configuration descriptor manager.xml
Nov 3, 2014 1:19:10 PM org.apache.catalina.startup.HostConfig 
deployDirectory

INFO: Deploying web application directory ROOT
Nov 3, 2014 1:19:10 PM org.apache.catalina.startup.HostConfig 
deployDirectory

INFO: Deploying web application directory examples
Nov 3, 2014 1:19:11 PM org.apache.catalina.startup.HostConfig 
deployDirectory

INFO: Deploying web application directory sample
Nov 3, 2014 1:19:11 PM org.apache.catalina.startup.HostConfig 
deployDirectory

INFO: Deploying web application directory docs
Nov 3, 2014 1:19:11 PM org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
Nov 3, 2014 1:19:11 PM org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /0.0.0.0:8009
Nov 3, 2014 1:19:11 PM org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/54  config=null
Nov 3, 2014 1:19:11 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 1307 ms
2014-11-03 13:19:37
Full thread dump OpenJDK 64-Bit Server VM (23.25-b01 mixed mode):

TP-Monitor daemon prio=10 tid=0x7feca454d800 nid=0x729f in 
Object.wait() [0x7feca241]

   java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xba74ea78 (a 
org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable)
at 
org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable.run(ThreadPool.java:565)
- locked 0xba74ea78 (a 
org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable)

at java.lang.Thread.run(Thread.java:701)

TP-Processor4 daemon prio=10 tid=0x7feca452f000 nid=0x729e 
runnable [0x7feca2511000]

   java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketAccept(Native Method)
at 
java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:375)

at java.net.ServerSocket.implAccept(ServerSocket.java:478)
at java.net.ServerSocket.accept(ServerSocket.java:446)
at 
org.apache.jk.common.ChannelSocket.accept(ChannelSocket.java:307)
at 
org.apache.jk.common.ChannelSocket.acceptConnections(ChannelSocket.java:661)
at 
org.apache.jk.common.ChannelSocket$SocketAcceptor.runIt(ChannelSocket.java:872)
at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)

at java.lang.Thread.run(Thread.java:701)

TP-Processor3 daemon prio=10 tid=0x7feca452d000 nid=0x729d in 
Object.wait() [0x7feca2612000]

   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xba74e3a8 (a 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)

at java.lang.Object.wait(Object.java:502)
at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:662)
- locked 0xba74e3a8 (a 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)

at java.lang.Thread.run(Thread.java:701)

TP-Processor2 daemon prio=10 tid=0x7feca4532000 nid=0x729c in 
Object.wait() [0x7feca2713000]

   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xba74e010 (a 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)

at java.lang.Object.wait(Object.java:502)
at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:662)
- locked 0xba74e010 (a 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)

at java.lang.Thread.run(Thread.java:701)

TP-Processor1 daemon prio=10 tid=0x7feca452a000 nid=0x729b in 
Object.wait() [0x7feca2814000]

   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xba74dc60 (a 

Re: From HTTP to HTTPS request.getHeader(referer)

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Léa,

On 11/2/14 12:34 PM, Léa Massiot wrote:
 Hi again. It looks like sendRedirect() is working if I pass it a
 HTTPS URL as an argument:
 
 - String s_prov
 = request.getScheme() + :// + request.getServerName() +
 request.getContextPath() + / + example1.jsp;
 
 response.sendRedirect(s_prov); 
 -
 
 Nota: in my case, request.getScheme() is equal to https.
 
 I think I'm going back to sendRedirect()... Snif :'/, it's a lot
 of matches to replace back (from forward() to 
 sendRedirect())...

If you want to switch protocols, then you will have to build the
entire URL including the protocol.

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

iQIcBAEBCAAGBQJUV9YnAAoJEBzwKT+lPKRY6IIP/iM8zeEPhqVKX69XpLDm/7kF
SFegFsT2dCQIXA1UhhS6soW7T/7pC92iBFXxJZ6quYG3wHx+mmY5tarb+jpShNo7
FhO+0pKwhV2cixSbXV1mISaheDDfx1PIA7CBRyL9LtA2cioLAxJKdIaMgRQYN2cd
FEjqRhpHWKQXYT1CmHNz80FcArVCKMy3UnXMUZbe/XOpNmHRCemS/pAFAtaHm7EV
hiej35ztAAUJm5UGq0VhAL61of3ij1sHFthbH4lupc11HWIOqz+pl9KnByYmbIBf
ZOJM8Ydma2/41BurVs/vrunqHRI4kNTi475I+xkjt/nYLXuStqsb3D0t7qKtdfkl
R02jPFEq76MSvUoe2h73awOfPzddSeMDpwt+ld9BMltOwtsFdqNC6dXXQHB5O4yM
y4ov0EIOK0WLgqqhebMquQ1JgIu8+6C3FW7z8HWIRCgkUUl6MaiYJQNTCAIiVYyI
a0yKafVBk2nPCWNf2TxOy+yi4AT2SYnCpEsac9wCpracS/cfF7A3N/iJC5bkW+hS
s91Y5O7E+p+iD46mT0i3BsiB0V7cVlDWd5I/I0P/dRB7dDUcxKIgnqMAWDGyswxe
AU8DNTsWwYSpX51Awq0WkSmInbIgPRRZ8iuY4t7vy5zmB8gHV52zglbH8wsGvnQF
BstMynBcam41fi62FgTW
=9dkF
-END PGP SIGNATURE-

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

Re: troubleshoot tomcat database connection

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 11/3/14 1:58 PM, Mark Maciolek wrote:
 system is running Scientific Linux release 6.5 rpm installed
 
 tomcat6-servlet-2.5-api-6.0.24-78.el6_5.noarch 
 tomcat6-javadoc-6.0.24-78.el6_5.noarch 
 tomcat6-lib-6.0.24-78.el6_5.noarch 
 tomcat-native-1.1.30-1.el6.x86_64 
 tomcat6-el-2.1-api-6.0.24-78.el6_5.noarch 
 tomcat6-admin-webapps-6.0.24-78.el6_5.noarch 
 apache-tomcat-apis-0.1-1.el6.noarch 
 tomcat6-jsp-2.1-api-6.0.24-78.el6_5.noarch 
 tomcat6-webapps-6.0.24-78.el6_5.noarch 
 tomcat-servlet-3.0-api-7.0.33-4.el6.noarch 
 tomcat6-6.0.24-78.el6_5.noarch 
 tomcat6-docs-webapp-6.0.24-78.el6_5.noarch

Wow, those are really out of date. I know that RPM packages often have
the wrong versions numbers with back-ported bug and security fixes,
etc., so it's tough to tell, but you may be hideously out of date.

 httpd-2.2.15-31.sl6.x86_64
 
 tomcat starts and I can reach the page on the 8080 port

Great.

 It never starts the connection host name connection from the
 server.xml

I'm not sure what you mean here. What is the connection host name
connection and why should it start?

 I do a kill -3 on the tomcat pid and this is what the logs shows:
 
 INFO: Starting Servlet Engine: Apache Tomcat/6.0.24 Nov 3, 2014
 1:19:10 PM org.apache.catalina.startup.HostConfig deployDescriptor 
 INFO: Deploying configuration descriptor host-manager.xml Nov 3,
 2014 1:19:10 PM org.apache.catalina.startup.HostConfig 
 deployDescriptor INFO: Deploying configuration descriptor
 manager.xml Nov 3, 2014 1:19:10 PM
 org.apache.catalina.startup.HostConfig deployDirectory INFO:
 Deploying web application directory ROOT Nov 3, 2014 1:19:10 PM
 org.apache.catalina.startup.HostConfig deployDirectory INFO:
 Deploying web application directory examples Nov 3, 2014 1:19:11 PM
 org.apache.catalina.startup.HostConfig deployDirectory INFO:
 Deploying web application directory sample Nov 3, 2014 1:19:11 PM
 org.apache.catalina.startup.HostConfig deployDirectory INFO:
 Deploying web application directory docs Nov 3, 2014 1:19:11 PM
 org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote
 HTTP/1.1 on http-8080 Nov 3, 2014 1:19:11 PM
 org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening
 on /0.0.0.0:8009 Nov 3, 2014 1:19:11 PM org.apache.jk.server.JkMain
 start INFO: Jk running ID=0 time=0/54  config=null Nov 3, 2014
 1:19:11 PM org.apache.catalina.startup.Catalina start INFO: Server
 startup in 1307 ms

So you have an HTTP connector on port 8080 and an AJP connector on
port 8009. That's an out-of-the-box configuration of Tomcat if you
download it from apache.org (or a mirror) so that's nice.

 2014-11-03 13:19:37 Full thread dump OpenJDK 64-Bit Server VM
 (23.25-b01 mixed mode):
 
 TP-Monitor daemon prio=10 tid=0x7feca454d800 nid=0x729f in 
 Object.wait() [0x7feca241] java.lang.Thread.State:
 TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native
 Method) - waiting on 0xba74ea78 (a 
 org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable) at 
 org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable.run(ThreadPool.java:565)

  - locked 0xba74ea78 (a 
 org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable) at
 java.lang.Thread.run(Thread.java:701)
 
 TP-Processor4 daemon prio=10 tid=0x7feca452f000 nid=0x729e 
 runnable [0x7feca2511000] java.lang.Thread.State: RUNNABLE at
 java.net.PlainSocketImpl.socketAccept(Native Method) at 
 java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:375)

 
at java.net.ServerSocket.implAccept(ServerSocket.java:478)
 at java.net.ServerSocket.accept(ServerSocket.java:446) at 
 org.apache.jk.common.ChannelSocket.accept(ChannelSocket.java:307) 
 at 
 org.apache.jk.common.ChannelSocket.acceptConnections(ChannelSocket.java:661)

  at 
 org.apache.jk.common.ChannelSocket$SocketAcceptor.runIt(ChannelSocket.java:872)

  at 
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)

  at java.lang.Thread.run(Thread.java:701)
 
 TP-Processor3 daemon prio=10 tid=0x7feca452d000 nid=0x729d
 in Object.wait() [0x7feca2612000] java.lang.Thread.State:
 WAITING (on object monitor) at java.lang.Object.wait(Native
 Method) - waiting on 0xba74e3a8 (a 
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable) at
 java.lang.Object.wait(Object.java:502) at 
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:662)

  - locked 0xba74e3a8 (a 
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable) at
 java.lang.Thread.run(Thread.java:701)
 
 TP-Processor2 daemon prio=10 tid=0x7feca4532000 nid=0x729c
 in Object.wait() [0x7feca2713000] java.lang.Thread.State:
 WAITING (on object monitor) at java.lang.Object.wait(Native
 Method) - waiting on 0xba74e010 (a 
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable) at
 java.lang.Object.wait(Object.java:502) at 
 

Re: troubleshoot tomcat database connection

[Daniel Mikusa]

On Mon, Nov 3, 2014 at 1:58 PM, Mark Maciolek m...@sr.unh.edu wrote:

 hi,

 system is running Scientific Linux release 6.5
 rpm installed

 tomcat6-servlet-2.5-api-6.0.24-78.el6_5.noarch
 tomcat6-javadoc-6.0.24-78.el6_5.noarch
 tomcat6-lib-6.0.24-78.el6_5.noarch
 tomcat-native-1.1.30-1.el6.x86_64
 tomcat6-el-2.1-api-6.0.24-78.el6_5.noarch
 tomcat6-admin-webapps-6.0.24-78.el6_5.noarch
 apache-tomcat-apis-0.1-1.el6.noarch
 tomcat6-jsp-2.1-api-6.0.24-78.el6_5.noarch
 tomcat6-webapps-6.0.24-78.el6_5.noarch
 tomcat-servlet-3.0-api-7.0.33-4.el6.noarch
 tomcat6-6.0.24-78.el6_5.noarch
 tomcat6-docs-webapp-6.0.24-78.el6_5.noarch


For what it's worth, 6.0.24 is pretty old.  You should strongly consider
upgrading to 6.0.41, or whatever is the latest at the time you go to
upgrade.



 httpd-2.2.15-31.sl6.x86_64

 tomcat starts and I can reach the page on the 8080 port


Good!



 It never starts the connection host name connection from the server.xml


Hmm, not sure what you mean here.  Are you talking about virtual hosting
with Tomcat?

  http://tomcat.apache.org/tomcat-6.0-doc/virtual-hosting-howto.html



 I do a kill -3 on the tomcat pid and this is what the logs shows:

 INFO: Starting Servlet Engine: Apache Tomcat/6.0.24
 Nov 3, 2014 1:19:10 PM org.apache.catalina.startup.HostConfig
 deployDescriptor
 INFO: Deploying configuration descriptor host-manager.xml
 Nov 3, 2014 1:19:10 PM org.apache.catalina.startup.HostConfig
 deployDescriptor
 INFO: Deploying configuration descriptor manager.xml
 Nov 3, 2014 1:19:10 PM org.apache.catalina.startup.HostConfig
 deployDirectory
 INFO: Deploying web application directory ROOT
 Nov 3, 2014 1:19:10 PM org.apache.catalina.startup.HostConfig
 deployDirectory
 INFO: Deploying web application directory examples
 Nov 3, 2014 1:19:11 PM org.apache.catalina.startup.HostConfig
 deployDirectory
 INFO: Deploying web application directory sample
 Nov 3, 2014 1:19:11 PM org.apache.catalina.startup.HostConfig
 deployDirectory
 INFO: Deploying web application directory docs
 Nov 3, 2014 1:19:11 PM org.apache.coyote.http11.Http11Protocol start
 INFO: Starting Coyote HTTP/1.1 on http-8080
 Nov 3, 2014 1:19:11 PM org.apache.jk.common.ChannelSocket init
 INFO: JK: ajp13 listening on /0.0.0.0:8009
 Nov 3, 2014 1:19:11 PM org.apache.jk.server.JkMain start
 INFO: Jk running ID=0 time=0/54  config=null
 Nov 3, 2014 1:19:11 PM org.apache.catalina.startup.Catalina start
 INFO: Server startup in 1307 ms
 2014-11-03 13:19:37
 Full thread dump OpenJDK 64-Bit Server VM (23.25-b01 mixed mode):

 TP-Monitor daemon prio=10 tid=0x7feca454d800 nid=0x729f in
 Object.wait() [0x7feca241]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
 at java.lang.Object.wait(Native Method)
 - waiting on 0xba74ea78 (a org.apache.tomcat.util.
 threads.ThreadPool$MonitorRunnable)
 at org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable.run(
 ThreadPool.java:565)
 - locked 0xba74ea78 (a org.apache.tomcat.util.
 threads.ThreadPool$MonitorRunnable)
 at java.lang.Thread.run(Thread.java:701)

 TP-Processor4 daemon prio=10 tid=0x7feca452f000 nid=0x729e runnable
 [0x7feca2511000]
java.lang.Thread.State: RUNNABLE
 at java.net.PlainSocketImpl.socketAccept(Native Method)
 at java.net.AbstractPlainSocketImpl.accept(
 AbstractPlainSocketImpl.java:375)
 at java.net.ServerSocket.implAccept(ServerSocket.java:478)
 at java.net.ServerSocket.accept(ServerSocket.java:446)
 at org.apache.jk.common.ChannelSocket.accept(
 ChannelSocket.java:307)
 at org.apache.jk.common.ChannelSocket.acceptConnections(
 ChannelSocket.java:661)
 at org.apache.jk.common.ChannelSocket$SocketAcceptor.
 runIt(ChannelSocket.java:872)
 at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
 ThreadPool.java:690)
 at java.lang.Thread.run(Thread.java:701)

 TP-Processor3 daemon prio=10 tid=0x7feca452d000 nid=0x729d in
 Object.wait() [0x7feca2612000]
java.lang.Thread.State: WAITING (on object monitor)
 at java.lang.Object.wait(Native Method)
 - waiting on 0xba74e3a8 (a org.apache.tomcat.util.
 threads.ThreadPool$ControlRunnable)
 at java.lang.Object.wait(Object.java:502)
 at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
 ThreadPool.java:662)
 - locked 0xba74e3a8 (a org.apache.tomcat.util.
 threads.ThreadPool$ControlRunnable)
 at java.lang.Thread.run(Thread.java:701)

 TP-Processor2 daemon prio=10 tid=0x7feca4532000 nid=0x729c in
 Object.wait() [0x7feca2713000]
java.lang.Thread.State: WAITING (on object monitor)
 at java.lang.Object.wait(Native Method)
 - waiting on 0xba74e010 (a org.apache.tomcat.util.
 threads.ThreadPool$ControlRunnable)
 at java.lang.Object.wait(Object.java:502)
 at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
 

RE: Separation of CATALINA_HOME and CATALINA_BASE

[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: troubleshoot tomcat database connection

[Mark Maciolek]

On 11/3/2014 2:29 PM, Daniel Mikusa wrote:

On Mon, Nov 3, 2014 at 1:58 PM, Mark Maciolek m...@sr.unh.edu wrote:


hi,

system is running Scientific Linux release 6.5
rpm installed

tomcat6-servlet-2.5-api-6.0.24-78.el6_5.noarch
tomcat6-javadoc-6.0.24-78.el6_5.noarch
tomcat6-lib-6.0.24-78.el6_5.noarch
tomcat-native-1.1.30-1.el6.x86_64
tomcat6-el-2.1-api-6.0.24-78.el6_5.noarch
tomcat6-admin-webapps-6.0.24-78.el6_5.noarch
apache-tomcat-apis-0.1-1.el6.noarch
tomcat6-jsp-2.1-api-6.0.24-78.el6_5.noarch
tomcat6-webapps-6.0.24-78.el6_5.noarch
tomcat-servlet-3.0-api-7.0.33-4.el6.noarch
tomcat6-6.0.24-78.el6_5.noarch
tomcat6-docs-webapp-6.0.24-78.el6_5.noarch


For what it's worth, 6.0.24 is pretty old.  You should strongly consider
upgrading to 6.0.41, or whatever is the latest at the time you go to
upgrade.



httpd-2.2.15-31.sl6.x86_64

tomcat starts and I can reach the page on the 8080 port


Good!



It never starts the connection host name connection from the server.xml


Hmm, not sure what you mean here.  Are you talking about virtual hosting
with Tomcat?

   http://tomcat.apache.org/tomcat-6.0-doc/virtual-hosting-howto.html


not currently just this one site on the server serving jsp file.

I do a kill -3 on the tomcat pid and this is what the logs shows:

INFO: Starting Servlet Engine: Apache Tomcat/6.0.24
Nov 3, 2014 1:19:10 PM org.apache.catalina.startup.HostConfig
deployDescriptor
INFO: Deploying configuration descriptor host-manager.xml
Nov 3, 2014 1:19:10 PM org.apache.catalina.startup.HostConfig
deployDescriptor
INFO: Deploying configuration descriptor manager.xml
Nov 3, 2014 1:19:10 PM org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deploying web application directory ROOT
Nov 3, 2014 1:19:10 PM org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deploying web application directory examples
Nov 3, 2014 1:19:11 PM org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deploying web application directory sample
Nov 3, 2014 1:19:11 PM org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deploying web application directory docs
Nov 3, 2014 1:19:11 PM org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
Nov 3, 2014 1:19:11 PM org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /0.0.0.0:8009
Nov 3, 2014 1:19:11 PM org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/54  config=null
Nov 3, 2014 1:19:11 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 1307 ms
2014-11-03 13:19:37
Full thread dump OpenJDK 64-Bit Server VM (23.25-b01 mixed mode):

TP-Monitor daemon prio=10 tid=0x7feca454d800 nid=0x729f in
Object.wait() [0x7feca241]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
 at java.lang.Object.wait(Native Method)
 - waiting on 0xba74ea78 (a org.apache.tomcat.util.
threads.ThreadPool$MonitorRunnable)
 at org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable.run(
ThreadPool.java:565)
 - locked 0xba74ea78 (a org.apache.tomcat.util.
threads.ThreadPool$MonitorRunnable)
 at java.lang.Thread.run(Thread.java:701)

TP-Processor4 daemon prio=10 tid=0x7feca452f000 nid=0x729e runnable
[0x7feca2511000]
java.lang.Thread.State: RUNNABLE
 at java.net.PlainSocketImpl.socketAccept(Native Method)
 at java.net.AbstractPlainSocketImpl.accept(
AbstractPlainSocketImpl.java:375)
 at java.net.ServerSocket.implAccept(ServerSocket.java:478)
 at java.net.ServerSocket.accept(ServerSocket.java:446)
 at org.apache.jk.common.ChannelSocket.accept(
ChannelSocket.java:307)
 at org.apache.jk.common.ChannelSocket.acceptConnections(
ChannelSocket.java:661)
 at org.apache.jk.common.ChannelSocket$SocketAcceptor.
runIt(ChannelSocket.java:872)
 at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
ThreadPool.java:690)
 at java.lang.Thread.run(Thread.java:701)

TP-Processor3 daemon prio=10 tid=0x7feca452d000 nid=0x729d in
Object.wait() [0x7feca2612000]
java.lang.Thread.State: WAITING (on object monitor)
 at java.lang.Object.wait(Native Method)
 - waiting on 0xba74e3a8 (a org.apache.tomcat.util.
threads.ThreadPool$ControlRunnable)
 at java.lang.Object.wait(Object.java:502)
 at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
ThreadPool.java:662)
 - locked 0xba74e3a8 (a org.apache.tomcat.util.
threads.ThreadPool$ControlRunnable)
 at java.lang.Thread.run(Thread.java:701)

TP-Processor2 daemon prio=10 tid=0x7feca4532000 nid=0x729c in
Object.wait() [0x7feca2713000]
java.lang.Thread.State: WAITING (on object monitor)
 at java.lang.Object.wait(Native Method)
 - waiting on 0xba74e010 (a org.apache.tomcat.util.
threads.ThreadPool$ControlRunnable)
 at java.lang.Object.wait(Object.java:502)
 at 

[OT] jaxws 2.2 spec

[Leo Donahue]

I know this isn't really a Tomcat specific question, but there are alot of
web service people on the list who may want to provide their two cents.

http://download.oracle.com/otndocs/jcp/jaxws-2_2a-mrel4-eval-spec/
Page 10 indicates the following:

In the absence of customizations, the name of an SEI MUST be the value of
the name attribute of the corresponding wsdl:portType element mapped
according to the rules described in section 2.8.

In bottom up web service development, you can annotate your SEI with an
@WebService property for name which indicates the name of the
wsdl:portType

However, I don't see a way to provide that using the wsgen utility.  wsgen
provides a wsdl:port option but that one is part of the wsdl:service. So
while I can name my port in a sub element of wsdl:service, I don't see how
I can tell wsgen to use that name for wsdl:portType.  And I don't see a way
to set the soap:address location via wsgen either (although you can with
the wsconsume toolkit)

In top down web service development, you can specify everything up front,
as long as you remember to name your SEI according to the name used in the
wsdl:portType, and as long as you remember to annotate your SEI with the
same serviceName property used in wsd:service in the .wsdl file.

In bottom up web service development, there is a fear of a changing
contract if there are POJOs laying around that can be used in a build to
regenerate the wsdl.  But it seems like this is the favored approach for
two reasons:

1.  Annotations exist to make creating the wsdl easier
2.  Toolkit utilities exist to make creating the wsdl easier

I don't want to start an argument, but where do most of you find
yourselves?  Are you creating your wsdls from scratch or from a set of Java
classes?

leo

Re: troubleshoot tomcat database connection

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 11/3/14 2:41 PM, Mark Maciolek wrote:
 
 On 11/3/2014 2:29 PM, Daniel Mikusa wrote:
 On Mon, Nov 3, 2014 at 1:58 PM, Mark Maciolek m...@sr.unh.edu
 wrote:
 
 hi,
 
 system is running Scientific Linux release 6.5 rpm installed
 
 tomcat6-servlet-2.5-api-6.0.24-78.el6_5.noarch 
 tomcat6-javadoc-6.0.24-78.el6_5.noarch 
 tomcat6-lib-6.0.24-78.el6_5.noarch 
 tomcat-native-1.1.30-1.el6.x86_64 
 tomcat6-el-2.1-api-6.0.24-78.el6_5.noarch 
 tomcat6-admin-webapps-6.0.24-78.el6_5.noarch 
 apache-tomcat-apis-0.1-1.el6.noarch 
 tomcat6-jsp-2.1-api-6.0.24-78.el6_5.noarch 
 tomcat6-webapps-6.0.24-78.el6_5.noarch 
 tomcat-servlet-3.0-api-7.0.33-4.el6.noarch 
 tomcat6-6.0.24-78.el6_5.noarch 
 tomcat6-docs-webapp-6.0.24-78.el6_5.noarch
 
 For what it's worth, 6.0.24 is pretty old.  You should strongly
 consider upgrading to 6.0.41, or whatever is the latest at the
 time you go to upgrade.
 
 
 httpd-2.2.15-31.sl6.x86_64
 
 tomcat starts and I can reach the page on the 8080 port
 
 Good!
 
 
 It never starts the connection host name connection from the
 server.xml
 
 Hmm, not sure what you mean here.  Are you talking about virtual
 hosting with Tomcat?
 
 http://tomcat.apache.org/tomcat-6.0-doc/virtual-hosting-howto.html


 
not currently just this one site on the server serving jsp file.
 I do a kill -3 on the tomcat pid and this is what the logs
 shows:
 
 INFO: Starting Servlet Engine: Apache Tomcat/6.0.24 Nov 3, 2014
 1:19:10 PM org.apache.catalina.startup.HostConfig 
 deployDescriptor INFO: Deploying configuration descriptor
 host-manager.xml Nov 3, 2014 1:19:10 PM
 org.apache.catalina.startup.HostConfig deployDescriptor INFO:
 Deploying configuration descriptor manager.xml Nov 3, 2014
 1:19:10 PM org.apache.catalina.startup.HostConfig 
 deployDirectory INFO: Deploying web application directory ROOT 
 Nov 3, 2014 1:19:10 PM org.apache.catalina.startup.HostConfig 
 deployDirectory INFO: Deploying web application directory
 examples Nov 3, 2014 1:19:11 PM
 org.apache.catalina.startup.HostConfig deployDirectory INFO:
 Deploying web application directory sample Nov 3, 2014 1:19:11
 PM org.apache.catalina.startup.HostConfig deployDirectory INFO:
 Deploying web application directory docs Nov 3, 2014 1:19:11 PM
 org.apache.coyote.http11.Http11Protocol start INFO: Starting
 Coyote HTTP/1.1 on http-8080 Nov 3, 2014 1:19:11 PM
 org.apache.jk.common.ChannelSocket init INFO: JK: ajp13
 listening on /0.0.0.0:8009 Nov 3, 2014 1:19:11 PM
 org.apache.jk.server.JkMain start INFO: Jk running ID=0
 time=0/54  config=null Nov 3, 2014 1:19:11 PM
 org.apache.catalina.startup.Catalina start INFO: Server startup
 in 1307 ms 2014-11-03 13:19:37 Full thread dump OpenJDK 64-Bit
 Server VM (23.25-b01 mixed mode):
 
 TP-Monitor daemon prio=10 tid=0x7feca454d800 nid=0x729f
 in Object.wait() [0x7feca241] java.lang.Thread.State:
 TIMED_WAITING (on object monitor) at
 java.lang.Object.wait(Native Method) - waiting on
 0xba74ea78 (a org.apache.tomcat.util. 
 threads.ThreadPool$MonitorRunnable) at 
 org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable.run( 
 ThreadPool.java:565) - locked 0xba74ea78 (a
 org.apache.tomcat.util. threads.ThreadPool$MonitorRunnable) at
 java.lang.Thread.run(Thread.java:701)
 
 TP-Processor4 daemon prio=10 tid=0x7feca452f000
 nid=0x729e runnable [0x7feca2511000] 
 java.lang.Thread.State: RUNNABLE at
 java.net.PlainSocketImpl.socketAccept(Native Method) at
 java.net.AbstractPlainSocketImpl.accept( 
 AbstractPlainSocketImpl.java:375) at
 java.net.ServerSocket.implAccept(ServerSocket.java:478) at
 java.net.ServerSocket.accept(ServerSocket.java:446) at
 org.apache.jk.common.ChannelSocket.accept( 
 ChannelSocket.java:307) at
 org.apache.jk.common.ChannelSocket.acceptConnections( 
 ChannelSocket.java:661) at
 org.apache.jk.common.ChannelSocket$SocketAcceptor. 
 runIt(ChannelSocket.java:872) at 
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run( 
 ThreadPool.java:690) at java.lang.Thread.run(Thread.java:701)
 
 TP-Processor3 daemon prio=10 tid=0x7feca452d000
 nid=0x729d in Object.wait() [0x7feca2612000] 
 java.lang.Thread.State: WAITING (on object monitor) at
 java.lang.Object.wait(Native Method) - waiting on
 0xba74e3a8 (a org.apache.tomcat.util. 
 threads.ThreadPool$ControlRunnable) at
 java.lang.Object.wait(Object.java:502) at 
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run( 
 ThreadPool.java:662) - locked 0xba74e3a8 (a
 org.apache.tomcat.util. threads.ThreadPool$ControlRunnable) at
 java.lang.Thread.run(Thread.java:701)
 
 TP-Processor2 daemon prio=10 tid=0x7feca4532000
 nid=0x729c in Object.wait() [0x7feca2713000] 
 java.lang.Thread.State: WAITING (on object monitor) at
 java.lang.Object.wait(Native Method) - waiting on
 0xba74e010 (a org.apache.tomcat.util. 
 threads.ThreadPool$ControlRunnable) at
 java.lang.Object.wait(Object.java:502) at 
 

Re: troubleshoot tomcat database connection

[Mark Maciolek]

On 11/3/2014 2:52 PM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 11/3/14 2:41 PM, Mark Maciolek wrote:

On 11/3/2014 2:29 PM, Daniel Mikusa wrote:

On Mon, Nov 3, 2014 at 1:58 PM, Mark Maciolek m...@sr.unh.edu
wrote:


hi,

system is running Scientific Linux release 6.5 rpm installed

tomcat6-servlet-2.5-api-6.0.24-78.el6_5.noarch
tomcat6-javadoc-6.0.24-78.el6_5.noarch
tomcat6-lib-6.0.24-78.el6_5.noarch
tomcat-native-1.1.30-1.el6.x86_64
tomcat6-el-2.1-api-6.0.24-78.el6_5.noarch
tomcat6-admin-webapps-6.0.24-78.el6_5.noarch
apache-tomcat-apis-0.1-1.el6.noarch
tomcat6-jsp-2.1-api-6.0.24-78.el6_5.noarch
tomcat6-webapps-6.0.24-78.el6_5.noarch
tomcat-servlet-3.0-api-7.0.33-4.el6.noarch
tomcat6-6.0.24-78.el6_5.noarch
tomcat6-docs-webapp-6.0.24-78.el6_5.noarch


For what it's worth, 6.0.24 is pretty old.  You should strongly
consider upgrading to 6.0.41, or whatever is the latest at the
time you go to upgrade.



httpd-2.2.15-31.sl6.x86_64

tomcat starts and I can reach the page on the 8080 port


Good!



It never starts the connection host name connection from the
server.xml


Hmm, not sure what you mean here.  Are you talking about virtual
hosting with Tomcat?

http://tomcat.apache.org/tomcat-6.0-doc/virtual-hosting-howto.html


not currently just this one site on the server serving jsp file.

I do a kill -3 on the tomcat pid and this is what the logs
shows:

INFO: Starting Servlet Engine: Apache Tomcat/6.0.24 Nov 3, 2014
1:19:10 PM org.apache.catalina.startup.HostConfig
deployDescriptor INFO: Deploying configuration descriptor
host-manager.xml Nov 3, 2014 1:19:10 PM
org.apache.catalina.startup.HostConfig deployDescriptor INFO:
Deploying configuration descriptor manager.xml Nov 3, 2014
1:19:10 PM org.apache.catalina.startup.HostConfig
deployDirectory INFO: Deploying web application directory ROOT
Nov 3, 2014 1:19:10 PM org.apache.catalina.startup.HostConfig
deployDirectory INFO: Deploying web application directory
examples Nov 3, 2014 1:19:11 PM
org.apache.catalina.startup.HostConfig deployDirectory INFO:
Deploying web application directory sample Nov 3, 2014 1:19:11
PM org.apache.catalina.startup.HostConfig deployDirectory INFO:
Deploying web application directory docs Nov 3, 2014 1:19:11 PM
org.apache.coyote.http11.Http11Protocol start INFO: Starting
Coyote HTTP/1.1 on http-8080 Nov 3, 2014 1:19:11 PM
org.apache.jk.common.ChannelSocket init INFO: JK: ajp13
listening on /0.0.0.0:8009 Nov 3, 2014 1:19:11 PM
org.apache.jk.server.JkMain start INFO: Jk running ID=0
time=0/54  config=null Nov 3, 2014 1:19:11 PM
org.apache.catalina.startup.Catalina start INFO: Server startup
in 1307 ms 2014-11-03 13:19:37 Full thread dump OpenJDK 64-Bit
Server VM (23.25-b01 mixed mode):

TP-Monitor daemon prio=10 tid=0x7feca454d800 nid=0x729f
in Object.wait() [0x7feca241] java.lang.Thread.State:
TIMED_WAITING (on object monitor) at
java.lang.Object.wait(Native Method) - waiting on
0xba74ea78 (a org.apache.tomcat.util.
threads.ThreadPool$MonitorRunnable) at
org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable.run(
ThreadPool.java:565) - locked 0xba74ea78 (a
org.apache.tomcat.util. threads.ThreadPool$MonitorRunnable) at
java.lang.Thread.run(Thread.java:701)

TP-Processor4 daemon prio=10 tid=0x7feca452f000
nid=0x729e runnable [0x7feca2511000]
java.lang.Thread.State: RUNNABLE at
java.net.PlainSocketImpl.socketAccept(Native Method) at
java.net.AbstractPlainSocketImpl.accept(
AbstractPlainSocketImpl.java:375) at
java.net.ServerSocket.implAccept(ServerSocket.java:478) at
java.net.ServerSocket.accept(ServerSocket.java:446) at
org.apache.jk.common.ChannelSocket.accept(
ChannelSocket.java:307) at
org.apache.jk.common.ChannelSocket.acceptConnections(
ChannelSocket.java:661) at
org.apache.jk.common.ChannelSocket$SocketAcceptor.
runIt(ChannelSocket.java:872) at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
ThreadPool.java:690) at java.lang.Thread.run(Thread.java:701)

TP-Processor3 daemon prio=10 tid=0x7feca452d000
nid=0x729d in Object.wait() [0x7feca2612000]
java.lang.Thread.State: WAITING (on object monitor) at
java.lang.Object.wait(Native Method) - waiting on
0xba74e3a8 (a org.apache.tomcat.util.
threads.ThreadPool$ControlRunnable) at
java.lang.Object.wait(Object.java:502) at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
ThreadPool.java:662) - locked 0xba74e3a8 (a
org.apache.tomcat.util. threads.ThreadPool$ControlRunnable) at
java.lang.Thread.run(Thread.java:701)

TP-Processor2 daemon prio=10 tid=0x7feca4532000
nid=0x729c in Object.wait() [0x7feca2713000]
java.lang.Thread.State: WAITING (on object monitor) at
java.lang.Object.wait(Native Method) - waiting on
0xba74e010 (a org.apache.tomcat.util.
threads.ThreadPool$ControlRunnable) at
java.lang.Object.wait(Object.java:502) at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
ThreadPool.java:662) - locked 

Re: Separation of CATALINA_HOME and CATALINA_BASE

[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: troubleshoot tomcat database connection

[Daniel Mikusa]

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

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Mark,

 On 11/3/14 2:41 PM, Mark Maciolek wrote:
 
  On 11/3/2014 2:29 PM, Daniel Mikusa wrote:
  On Mon, Nov 3, 2014 at 1:58 PM, Mark Maciolek m...@sr.unh.edu
  wrote:
 
  hi,
 
  system is running Scientific Linux release 6.5 rpm installed
 
  tomcat6-servlet-2.5-api-6.0.24-78.el6_5.noarch
  tomcat6-javadoc-6.0.24-78.el6_5.noarch
  tomcat6-lib-6.0.24-78.el6_5.noarch
  tomcat-native-1.1.30-1.el6.x86_64
  tomcat6-el-2.1-api-6.0.24-78.el6_5.noarch
  tomcat6-admin-webapps-6.0.24-78.el6_5.noarch
  apache-tomcat-apis-0.1-1.el6.noarch
  tomcat6-jsp-2.1-api-6.0.24-78.el6_5.noarch
  tomcat6-webapps-6.0.24-78.el6_5.noarch
  tomcat-servlet-3.0-api-7.0.33-4.el6.noarch
  tomcat6-6.0.24-78.el6_5.noarch
  tomcat6-docs-webapp-6.0.24-78.el6_5.noarch
 
  For what it's worth, 6.0.24 is pretty old.  You should strongly
  consider upgrading to 6.0.41, or whatever is the latest at the
  time you go to upgrade.
 
 
  httpd-2.2.15-31.sl6.x86_64
 
  tomcat starts and I can reach the page on the 8080 port
 
  Good!
 
 
  It never starts the connection host name connection from the
  server.xml
 
  Hmm, not sure what you mean here.  Are you talking about virtual
  hosting with Tomcat?
 
  http://tomcat.apache.org/tomcat-6.0-doc/virtual-hosting-howto.html
 
 
 
 not currently just this one site on the server serving jsp file.
  I do a kill -3 on the tomcat pid and this is what the logs
  shows:
 
  INFO: Starting Servlet Engine: Apache Tomcat/6.0.24 Nov 3, 2014
  1:19:10 PM org.apache.catalina.startup.HostConfig
  deployDescriptor INFO: Deploying configuration descriptor
  host-manager.xml Nov 3, 2014 1:19:10 PM
  org.apache.catalina.startup.HostConfig deployDescriptor INFO:
  Deploying configuration descriptor manager.xml Nov 3, 2014
  1:19:10 PM org.apache.catalina.startup.HostConfig
  deployDirectory INFO: Deploying web application directory ROOT
  Nov 3, 2014 1:19:10 PM org.apache.catalina.startup.HostConfig
  deployDirectory INFO: Deploying web application directory
  examples Nov 3, 2014 1:19:11 PM
  org.apache.catalina.startup.HostConfig deployDirectory INFO:
  Deploying web application directory sample Nov 3, 2014 1:19:11
  PM org.apache.catalina.startup.HostConfig deployDirectory INFO:
  Deploying web application directory docs Nov 3, 2014 1:19:11 PM
  org.apache.coyote.http11.Http11Protocol start INFO: Starting
  Coyote HTTP/1.1 on http-8080 Nov 3, 2014 1:19:11 PM
  org.apache.jk.common.ChannelSocket init INFO: JK: ajp13
  listening on /0.0.0.0:8009 Nov 3, 2014 1:19:11 PM
  org.apache.jk.server.JkMain start INFO: Jk running ID=0
  time=0/54  config=null Nov 3, 2014 1:19:11 PM
  org.apache.catalina.startup.Catalina start INFO: Server startup
  in 1307 ms 2014-11-03 13:19:37 Full thread dump OpenJDK 64-Bit
  Server VM (23.25-b01 mixed mode):
 
  TP-Monitor daemon prio=10 tid=0x7feca454d800 nid=0x729f
  in Object.wait() [0x7feca241] java.lang.Thread.State:
  TIMED_WAITING (on object monitor) at
  java.lang.Object.wait(Native Method) - waiting on
  0xba74ea78 (a org.apache.tomcat.util.
  threads.ThreadPool$MonitorRunnable) at
  org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable.run(
  ThreadPool.java:565) - locked 0xba74ea78 (a
  org.apache.tomcat.util. threads.ThreadPool$MonitorRunnable) at
  java.lang.Thread.run(Thread.java:701)
 
  TP-Processor4 daemon prio=10 tid=0x7feca452f000
  nid=0x729e runnable [0x7feca2511000]
  java.lang.Thread.State: RUNNABLE at
  java.net.PlainSocketImpl.socketAccept(Native Method) at
  java.net.AbstractPlainSocketImpl.accept(
  AbstractPlainSocketImpl.java:375) at
  java.net.ServerSocket.implAccept(ServerSocket.java:478) at
  java.net.ServerSocket.accept(ServerSocket.java:446) at
  org.apache.jk.common.ChannelSocket.accept(
  ChannelSocket.java:307) at
  org.apache.jk.common.ChannelSocket.acceptConnections(
  ChannelSocket.java:661) at
  org.apache.jk.common.ChannelSocket$SocketAcceptor.
  runIt(ChannelSocket.java:872) at
  org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
  ThreadPool.java:690) at java.lang.Thread.run(Thread.java:701)
 
  TP-Processor3 daemon prio=10 tid=0x7feca452d000
  nid=0x729d in Object.wait() [0x7feca2612000]
  java.lang.Thread.State: WAITING (on object monitor) at
  java.lang.Object.wait(Native Method) - waiting on
  0xba74e3a8 (a org.apache.tomcat.util.
  threads.ThreadPool$ControlRunnable) at
  java.lang.Object.wait(Object.java:502) at
  org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
  ThreadPool.java:662) - locked 0xba74e3a8 (a
  org.apache.tomcat.util. threads.ThreadPool$ControlRunnable) at
  java.lang.Thread.run(Thread.java:701)
 
  TP-Processor2 daemon prio=10 tid=0x7feca4532000
  nid=0x729c in Object.wait() [0x7feca2713000]
  java.lang.Thread.State: WAITING (on object monitor) at
  java.lang.Object.wait(Native Method) - 

Re: Separation of CATALINA_HOME and CATALINA_BASE

[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

[Christopher Schultz]

-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

RE: Separation of CATALINA_HOME and CATALINA_BASE

[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

[Christopher Schultz]

-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

Re: Separation of CATALINA_HOME and CATALINA_BASE

[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

[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

[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

[Christopher Schultz]

-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

[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

[Christopher Schultz]

-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

[Christopher Schultz]

-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

[Christopher Schultz]

-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

[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

[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: From HTTP to HTTPS request.getHeader(referer)

[Terence M. Bandoian]

On 11/2/2014 11:34 AM, Léa Massiot wrote:

Hi again.
It looks like sendRedirect() is working if I pass it a HTTPS URL as an
argument:

-
String s_prov =
request.getScheme() + ://
+ request.getServerName()
+ request.getContextPath() + /
+ example1.jsp;
 
response.sendRedirect(s_prov);

-

Nota: in my case, request.getScheme() is equal to https.

I think I'm going back to sendRedirect()...
Snif :'/, it's a lot of matches to replace back (from forward() to
sendRedirect())...

Best regards.



Hi, Léa-

I'm not sure how you're using it but it's worth pointing out that 
response.sendRedirect Sends a temporary redirect response to the 
client...  The client (browser) must then send another request to the 
server before any additional processing takes place.  In contrast, 
pageContext.forward takes place entirely on the server.


-Terence Bandoian


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