date:20140130

Hi,

I wrote a sample app to demonstrate the problem:
https://github.com/yanns/servlet31_async

You can generate an exploded war with maven: mvn war:exploded
I deployed the application in tomcat 8.0.0-RC10.

The 2 upload form does work.
The 1st upload form uses a new thread in , and that does not work.
https://github.com/yanns/servlet31_async/blob/master/src/main/java/com/yann/ReadListenerImpl.java#L22

The onDataAvailable is called only one time.

With jetty, it does work (mvn jetty:run)

I hope this can help.

Yann

2014-01-08 Yann Simon yann.simon...@gmail.com:
2014/1/8 Daniel Mikusa dmik...@gopivotal.com:
On Jan 8, 2014, at 12:04 PM, Yann Simon yann.simon...@gmail.com wrote:

Hi,

I am trying to write a servlet that asynchronously read data from the
servlet request input stream.
I tested my servlet with tomcat 8.0.0-RC5.

If possible, you might want to try 8.0.0-RC10 or trunk and see if you're
getting the same behavior.

the symptoms:
- I must synchronously read the input stream in onDataAvailable() so
that the upload works

what I expected:
I want to be more reactive (buzzword of the moment) and not read the
input stream until I am ready (=until the previous chunk is processed)
I though I could return from onDataAvailable() before having read all
the data, read the data in another thread.

Do you have a code sample? It would help to see what you're doing.

I expected onDataAvailable() to be called again when I consumed all the data
(servletInputStream.isReady becomes false)

Generally this sounds OK. When you call ServletInputStream.isReady() and it
returns false, that should trigger the container to call onDataAvailable()
when more data is available to be read. If you return from
onDataAvailable() and ServletInputStream.isReady() is still true the
container won't call onDataAvailable() again. You'll be responsible for
calling it when you're ready to read more.

That way, I could implement back pressure on the browser as long as my
servlet has not finished its work with the actual chunk

But if I do that, neither onDataAvailable() nor onAllDataRead() is called
again.

Again, a code sample would be helpful. Debugging non-blocking IO is tricky.
If you can include a sample Servlet or test case, it would greatly increase
your chance of getting feedback.

Thanks for the quick answer!

I have a code sample, but it may be too complicated to help debugging
the problem.
It is written in Scala. Its purpose is to provide a servlet that runs
asynchronous action from Playframework (http://www.playframework.com/)

https://github.com/yanns/play2-war-plugin/blob/servlet31/project-code/core/servlet31/src/main/scala/play/core/server/servlet31/RequestHandler31.scala#L74

The line 80 (iteratee = iteratee.pureFlatFold ) use a closure that
consumes the input stream asynchronously in another thread.

I'll try to take the time to write a much simpler code sample in Java.

Dan

When I consume the input stream synchronously in onDataAvailable(), it
works as expected.

Am I misunderstanding the asynchron IO in Tomcat 8?

Thanks in advance for any ideas!
Yann

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

Re: Tomcat 8.0.0-RC5: asynchron IO and back pressure with ReadListener

2014-01-30 Thread Rémy Maucherat

2014-01-30 Yann Simon yann.simon...@gmail.com:

 Hi,

 I wrote a sample app to demonstrate the problem:
 https://github.com/yanns/servlet31_async

 You can generate an exploded war with maven: mvn war:exploded
 I deployed the application in tomcat 8.0.0-RC10.

 The 2 upload form does work.
 The 1st upload form uses a new thread in , and that does not work.

 https://github.com/yanns/servlet31_async/blob/master/src/main/java/com/yann/ReadListenerImpl.java#L22

 The onDataAvailable is called only one time.

 With jetty, it does work (mvn jetty:run)

 I hope this can help.


You must read data until the ready flag flips, and you must do it in the
onDataAvailable invocation (= synchronously). Asynchronous reads is not the
threading and sync model that was chosen by the specification, so you
should simply not do that. I doubt it will reliably work in any container
since it is almost certain you can run in thread safety issues.

Rémy

Re: Tomcat 8.0.0-RC5: asynchron IO and back pressure with ReadListener

2014-01-30 Rémy Maucherat r...@apache.org:
2014-01-30 Yann Simon yann.simon...@gmail.com:

Hi,

I wrote a sample app to demonstrate the problem:
https://github.com/yanns/servlet31_async

You can generate an exploded war with maven: mvn war:exploded
I deployed the application in tomcat 8.0.0-RC10.

The 2 upload form does work.
The 1st upload form uses a new thread in , and that does not work.

https://github.com/yanns/servlet31_async/blob/master/src/main/java/com/yann/ReadListenerImpl.java#L22

The onDataAvailable is called only one time.

With jetty, it does work (mvn jetty:run)

I hope this can help.

You must read data until the ready flag flips, and you must do it in the
onDataAvailable invocation (= synchronously). Asynchronous reads is not the
threading and sync model that was chosen by the specification, so you
should simply not do that. I doubt it will reliably work in any container
since it is almost certain you can run in thread safety issues.

Rémy

Thx for the explanation.
What is the part of the specification that is saying that
onDataAvailbale must be consumed synchronously?
Is it the last sentence The Servlet container must access methods in
ReadListener in a thread safe manner. from:

The ReadListener provides the following callback methods for non blocking IO -
■ ReadListener
■ onDataAvailable() . The onDataAvailable method is invoked on the
ReadListener when data is available to read from the incoming request
stream. The container will invoke the method the first time when data is
available to read. The container will subsequently invoke the onDataAvailable
method if and only if isReady method on ServletInputStream , described
below, returns false .
■ onAllDataRead() . The onAllDataRead method is invoked when you have
finished reading all the data for the ServletRequest for which the listener was
registered.
■ onError(Throwable t) . The onError method is invoked if there is any error or
exception that occurs while processing the request.
The Servlet container must access methods in ReadListener in a thread
safe manner.

It means we cannot write real asynchronous reactive applications with
servlet 3.1... disappointing.

Yann

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

Re: Tomcat 8.0.0-RC5: asynchron IO and back pressure with ReadListener

2014-01-30 Thread Daniel Mikusa

On Jan 30, 2014, at 11:18 AM, Yann Simon yann.simon...@gmail.com wrote:

Hi,

I wrote a sample app to demonstrate the problem:
https://github.com/yanns/servlet31_async

You can generate an exploded war with maven: mvn war:exploded
I deployed the application in tomcat 8.0.0-RC10.

The 2 upload form does work.
The 1st upload form uses a new thread in , and that does not work.
https://github.com/yanns/servlet31_async/blob/master/src/main/java/com/yann/ReadListenerImpl.java#L22

I’m not sure I see the point of the code here. If you force it to block with
Thread.sleep() you’re going to tie up the thread that you’ve created and you’re
going to be back to having threads sitting around and doing nothing. If that’s
the case, you may as well save yourself some trouble and use the blocking apis.

Here’s what I’d suggest to make this work.

- in onDataAvailable read as much data as possible
- if you read until input.isReady() is false then just exit the function.
The container will call back when more data can be read.
- if you need to stop reading for some reason but input.isReady() is still
true, use a thread pool to schedule your own call back to onDataAvailable at
some point in the future. You can then continue reading at that point in time.
- Repeat until you’ve read all the data.

You still need additional threads with this approach, but it’s not one to one.
A small thread pool can service many requests because the thread is only active
when data is being read.

Here’s an example of this in action.

http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/tree/jetty-servlets/src/main/java/org/eclipse/jetty/servlets/DataRateLimitedServlet.java

Dan

The onDataAvailable is called only one time.

With jetty, it does work (mvn jetty:run)

I hope this can help.

Yann

2014-01-08 Yann Simon yann.simon...@gmail.com:
2014/1/8 Daniel Mikusa dmik...@gopivotal.com:
On Jan 8, 2014, at 12:04 PM, Yann Simon yann.simon...@gmail.com wrote:

Hi,

I am trying to write a servlet that asynchronously read data from the
servlet request input stream.
I tested my servlet with tomcat 8.0.0-RC5.

If possible, you might want to try 8.0.0-RC10 or trunk and see if you're
getting the same behavior.

the symptoms:
- I must synchronously read the input stream in onDataAvailable() so
that the upload works

Do you have a code sample? It would help to see what you're doing.

I expected onDataAvailable() to be called again when I consumed all the
data
(servletInputStream.isReady becomes false)

Generally this sounds OK. When you call ServletInputStream.isReady() and
it returns false, that should trigger the container to call
onDataAvailable() when more data is available to be read. If you return
from onDataAvailable() and ServletInputStream.isReady() is still true the
container won't call onDataAvailable() again. You'll be responsible for
calling it when you're ready to read more.

That way, I could implement back pressure on the browser as long as my
servlet has not finished its work with the actual chunk

But if I do that, neither onDataAvailable() nor onAllDataRead() is called
again.

Again, a code sample would be helpful. Debugging non-blocking IO is
tricky. If you can include a sample Servlet or test case, it would greatly
increase your chance of getting feedback.

Thanks for the quick answer!

https://github.com/yanns/play2-war-plugin/blob/servlet31/project-code/core/servlet31/src/main/scala/play/core/server/servlet31/RequestHandler31.scala#L74

The line 80 (iteratee = iteratee.pureFlatFold ) use a closure that
consumes the input stream asynchronously in another thread.

I'll try to take the time to write a much simpler code sample in Java.

Dan

When I consume the input stream synchronously in onDataAvailable(), it
works as expected.

Am I misunderstanding the asynchron IO in Tomcat 8?

Thanks in advance for any ideas!
Yann

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

-
To unsubscribe, e-mail:

Re: Tomcat 8.0.0-RC5: asynchron IO and back pressure with ReadListener

2014-01-30 Thread Rémy Maucherat

2014-01-30 Yann Simon yann.simon...@gmail.com:

 It means we cannot write real asynchronous reactive applications with
 servlet 3.1... disappointing.

 onDataAvailable is already something asynchronous, so starting an
asynchronous operation from it to do the same thing you're supposed to do
is not going to make things more asynchronous.

Unless you really are careful to do things exactly like in your example,
async reads is going to produce thread safety problems.

About the specific example, I'd say it doesn't work because the NIO
connector doesn't do anything to add the channel to its poller when ready
flips unless it is already in that state when the container thread returns,
but the APR connector does (so it would likely work).

Rémy

Work temp queries-tomcat 6

2014-01-30 Thread vicky007aggarwal

Hi Guys,

I've following queries,pls help me in understand the concepts :--

is it required to delete the work  temp while doing a deployment in Tomcat ?

 is it required to restart the tomcat instance in case of deploying a new 
 version of code?

 sometimes  i did observe that there are certain cache issues which make 
 the application refers the old code even when new code has been 
 deployed,this usually get fixed with cleaning work  temp directories, is 
 this the expected behavior ??

 does work  temp directories get recreated every time on restart??,,can you 
 help me in understand that under what scenarios work  temp directories are 
 created because at times at saw if i delete work  temp directories then 
 work is getting created not temp directory on a restart.

 how work  temp is being used by a Tomcat ??

 how important is a temp directory for a code to run?? I do see issues in 
 the past in case temp directory is not present in a catalina_base then the 
 application throws error .while startup.


Thanks,
Vicky

Manager Doesn't Recognize context = /

I have a virtual server that has one app (other than manager), and
this app resides at the root of the domain. I know that is not the
best practices recommended... but it is what it is, and it works, at
least other than with the manager.

The manager lists the / context and tells me how many active
sessions, etc.  But when I try to stop and restart the app using the
buttons on that line on the manager, I get:

FAIL - No context exists for path /

Is there something I can do to the configuration to make the manager
be able to stop/start this app?

Thx.

Jerry

Server: Apache Tomcat/7.0.27
JVM:  1.7.0_13-b20
Win Server 2008

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

Re: class from jar in tomcat/lib not found

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jakub,

On 1/29/14, 5:39 PM, Ja kub wrote:
 Caused by: java.lang. NoClassDefFoundError: Could not initialize
 class net.sf.hajdbc.sql.Driver at java.lang.Class.forName0(Native
 Method) ~[na:1.6.0_37] at java.lang.Class.forName(Class.java:169)
 ~[na:1.6.0_37] at 
 org.apache.tomcat.dbcp.dbcp.BasicDataSource.createConnectionFactory(BasicDataSource.java:1415)

 
~[tomcat-dbcp.jar:7.0.50]
 ... 34 common frames omitted Jan 29, 2014 12:10:06 AM
 org.apache.catalina.core. StandardContext startInternal SEVERE:
 Error listenerStart
 
 was just the bottom of stack trace and it was printed as above, I
 didn't cut anything, possibly it was in  ... 34 common frames
 omitted how can I unfold this 34 common frames ?

They should all be listed in one of the several stack traces shown.
The JVM does not hide Caused by items... only duplicate stack-trace
items.

I'm surprised the stack traces do not tell you what was actually missing.

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

iQIcBAEBCAAGBQJS6pwUAAoJEBzwKT+lPKRYNK4QAI7y9vZMiqIzQsMaXIUHGGaH
+USXOgZCFjyk8hSy4B6DhX06qrcBTpJPKCl0ne+o3TPdG1YO33BeeAjNXiXSZpCq
WGsLkCSYCjAhJCnZ1OBTBZyZ7dJh4pSYCeQZS/IVJVBA8/arv9qbjTWJSlX20nzT
EZjQPLwWelBAH63FvJTdHMJhF/JeYy58n4KWAPNeV1xG9UGOFlmoNLYE+4UZ30+s
hNLf7uaV8aG9aSQXm1bDvRcSdUuwWryaJopZTdYz3l2Mg0buQqOW+Hc0//TNWSa+
1MS42k74YXxQ74iPVy01hgsqfq89A+rOS31Ej4gaVV9exS1yep99ywkFu+qYqooE
GNkdxcxlo/lfpnG3VQ+DBNaHvswi5rxWB61AjZfRltLejRa4UIDMKKOhcWHOqKPK
nCPcF9cpbUrV/Q1Z73rxYm3XDW7RJqC+Vyu3SXahEavncPjzWply1SiCjNyIlsLx
q0zHAccxVrHaj6spvxv2cdUSLyVJzt9zBvB1Xj0mw0+d12k+ZqdUtWJfKAk4QVJx
8gpAG3sewa5qRadyC1+bRG/DKQSDKwW3VEouKsqS8lTW7SQZz8xefP5xJjuCve+p
9c9CyMrNPO6ljD1kMXnPoeie0Y/3jA92sop2uBTKW1HVbz1Vra+vxuQOskpP4qR5
H2ScaCkWBDrgluaLo9l3
=hSYM
-END PGP SIGNATURE-

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

Re: [OT] Tomcat v6.0.20 - Cannot Remove Date From JULI Log File Names

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 1/30/14, 10:34 AM, Mark H. Wood wrote:
 On Wed, Jan 29, 2014 at 10:27:13AM -0500, Christopher Schultz
 wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
 Mark,
 
 On 1/29/14, 9:49 AM, Mark H. Wood wrote:
 On Tue, Jan 28, 2014 at 12:32:22PM -0500, Daniel Mikusa wrote:
 On Jan 28, 2014, at 12:05 PM, Vye v...@vye.me wrote:
 I have been unsuccessfully trying to remove the date from 
 catalina’s log file name. My ultimate goal is to logrotate
 the file, which is best done when the file name is static.
 
 I’m curious, why are you trying to do this?  The log files
 are being rotated out-of-the-box.  They rotate by date, hence
 why the date is part of the name.  Why do you need to rotate
 them with some other tool?  What doesn’t work about the
 out-of-the-box configuration?
 
 I agree.  logrotate is a very nice crutch for use when the 
 application doesn't rotate its own logs, but it is better to
 use the application's rotation code when it exists, since the 
 application (with full knowledge of its internal state) can do
 this more safely and efficiently than any external tool.
 
 I actually like logrotate's capabilities for maintaining a set of
 log files: rotate, compress, delete, script, etc.
 
 I agree that logrotate's set of features is quite nice.
 
 Cleaning up old log files is easily done with a simple cron
 job, if the application does not trim old files.  That
 operation can be done just as well externally as internally.
 
 Sure, you can do this with scheduled scripts, but it logrotate
 is willing to do that work for you (e.g. easier commands, etc.)
 why not use it?
 
 logrotate works very well for logs created by short-lived
 processes. No particular coordination is required, when the source
 of the log starts, opens the file, writes a few records, and exits,
 from time to time.
 
 Long-running processes require coordination, or else the new file
 may sit empty for hours or days while the old file continues to
 receive the log entries.

logrotate and httpd work very well together, and httpd falls into the
latter category.

 logrotate has ways to handle this:
 
 o  send the process a signal that causes it to close and reopen
 logs. I don't think Tomcat has this.

Correct. It's tough to receive signals in Java because it's such an
OS-implementation detail. You can write native code to capture them,
but ... eew.

 jsvc does, and so (if you use jsvc to start Tomcat) you can use 
 this to rotate catalina.out.

+1

 There's some good stuff about this at 
 http://wiki.apache.org/tomcat/FAQ/Logging#Q10 but it's for sysout, 
 not logging packages like JULI.  I see some intriguing notes there 
 about logrotate's 'copytruncate' option, which I'll have to read
 up on.

With copytruncate, it is possible to lose data and end up with a few
corrupted entries, so it's best used with it remains the only
remaining option.

 o  run a command that somehow causes the process to close and
 reopen logs.  I don't think Tomcat has this.

This kind of thing could be added: JMX can support arbitrary
operations... an operation like flushLogs could be added that did
just that.

 o  stop and restart the daemon, which forces a close/open of the 
 logs.  It takes Tomcat several minutes to restart here, and while 
 I'm looking at ways to trim startup time, I really don't want to 
 bounce our services *at all* just to tidy the logs.

Tomcat takes like 1 second to start itself up (which may be too long
for you, granted). If your web application takes longer, then it's
your web application's problem ;)

 Thus I prefer to let Tomcat rotate its logs, since it can do that 
 without interfering with its operation, and to provide scripts to 
 handle trimming or archiving or other post-processing of the
 closed logs.

This is a reasonable conclusion, and I think it makes sense given the
constraints of Java itself, the web application lifecycle, etc.

 [just to be thorough]
 
 There are other options in some cases.
 
 o  Apache HTTPD comes with 'rotatelogs', a filter that absorbs text
 and writes it into files with a maximum size, maximum age,
 date-stamped names, etc.  If there's a way to connect log output to
 a pipeline, a daemon that does not contain rotation logic can still
 have rotated log files without restarting.

Right. Tomcat does this by streaming logs to an outside process.
Tomcat can't readily do this, but I think if you use a named pipe on
the filesystem, it might be possible to do.

 o  Some syslog packages work well with logrotate (using the signal 
 mechanism), so if your daemon can log to syslog then the rotation 
 can be handled downstream.

+1

syslog may be ugly, but it sure is good at its job. syslog can do
things like aggregate logs from multiple servers into a single log
elsewhere, etc. Plus there are tons of utilities that are built for
watching syslog for various events, and you can leverage these things
for monitoring, etc.

- -chris
-BEGIN PGP

Re: Work temp queries-tomcat 6

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Vicky,

On 1/30/14, 12:53 PM, vicky007aggar...@yahoo.co.in wrote:
 I've following queries,pls help me in understand the concepts :--
 
 is it required to delete the work  temp while doing a deployment
 in Tomcat ?

No, but it sometimes helps when things get ... broken.

 is it required to restart the tomcat instance in case of deploying
 a new version of code?

Not unless your code has a class of memory leaks that can cause
ClassLoaders to be pinned in memory. If you do, you'll find that
re-deploying your web application wastes a lot of memory, and
ultimately you will get OOME after several reloads.

 sometimes  i did observe that there are certain cache issues which 
 make the application refers the old code even when new code has
 been deployed,this usually get fixed with cleaning work  temp 
 directories, is this the expected behavior ??

No. If you have things like context-started threads still running
after the web application should have been shut down, you can get
problems like this. A Tomcat restart is the only thing that will clear
those away. The work directory is likely not related unless your code
uses the work directory for something.

 does work  temp directories get recreated every time on 
 restart??,,can you help me in understand that under what scenarios 
 work  temp directories are created because at times at saw if i 
 delete work  temp directories then work is getting created not
 temp directory on a restart.

Work and temp directories are created whenever Tomcat needs them. The
temp directory is guaranteed to be available by the servlet spec, so
it's created if it does not exist. The rules for whether the work
directory is required or not are unclear to me.

 how work  temp is being used by a Tomcat ??

The temp dir is required by the servlet spec. I don't believe Tomcat
uses it for anything. The work directory is used to cache resources
from WAR files, to compile .jsp files into .java and ultimately .class
files, etc.

 how important is a temp directory for a code to run?

Pretty important. Are you having some kind of problem with it?

 I do see issues in the past in case temp directory is not present
 in a catalina_base then the application throws error .while
 startup.

What version and what error message(s)?

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

iQIcBAEBCAAGBQJS6p8EAAoJEBzwKT+lPKRYpJsP/iVHTOm1KsrSAZXFVuXMUtvz
LJuTYdw/VYdD/fzMXHZwCXw1IFleIYTo4udJ3WmToac1bijzGGj7E+YCbEyBGMrC
BJvjWj5iqv2rtmvNpRksjC88LnDdY3AqMUNrix4jFbkhf+h4Ll83e47jyGLw4oCL
ex7fW+zzdjY4OlR9SXs9s8GGpegF6znn+SdEpVVfZJEuSkEMNtaWcjddWay7TBFz
OWOyvnccJB69ahElkFFyxxsrCrmCdYxlKLYBTd5naUyjDiej9A7V18d57j1Bl+y0
LYTI6oRsCuONXvYy0NgdGJYlWJOiCoOjWOJnvkNYxv//YEDYBBGHrLu4t+XRED0i
EE9pzeyQ4uZPT7xshkpkN0QmBIdaUY3zogFmVqLEjCw+D5SgZyz4Rxb8UpbDO/3F
GYap4wV5IZSUUo1FlfwdvOGbpvLTaKwWzRrP24qqoZ28y6F+VAmNNT2lE5ZxxJCW
gKHCKA/WcDRCUT4nzwEDKDZBRtw7AH+22IhSuoS7eTcRxBXtX0yhimDeyQUAyxrL
xFS/PbPYG6RpzWEfVZ1gZbXAoipo7SdgTyNUdVwFeP0rp8680RlYeM9+th4Zj/tq
bdyceewAzK9oSkyNbEdcBM1Kpdxb64OUiIsYJBBd28zZLTTJ+t7UKDvCgCowEQJN
1W4TdMpWAuAoF0fERveI
=0urU
-END PGP SIGNATURE-

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

Re: Manager Doesn't Recognize context = /

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jerry,

On 1/30/14, 1:31 PM, Jerry Malcolm wrote:
 I have a virtual server that has one app (other than manager), and 
 this app resides at the root of the domain. I know that is not the 
 best practices recommended... but it is what it is, and it works,
 at least other than with the manager.
 
 The manager lists the / context and tells me how many active 
 sessions, etc.  But when I try to stop and restart the app using
 the buttons on that line on the manager, I get:
 
 FAIL - No context exists for path /
 
 Is there something I can do to the configuration to make the
 manager be able to stop/start this app?
 
 Thx.
 
 Jerry
 
 Server: Apache Tomcat/7.0.27 JVM:  1.7.0_13-b20 Win Server 2008

Where is your WAR file (or exploded WAR dir) located (and what is it
called)? How have you configured Tomcat to deploy the WAR (auto-deploy
from webapps/, XML-file deployment from
conf/[engine]/[host]/[webapp].xml, or directly in server.xml)?

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

iQIcBAEBCAAGBQJS6p9uAAoJEBzwKT+lPKRYW84P/Ax+WPeKtLl3rgoimHFWNOUZ
29HB2yMxyJfiD0iKoJyuGDDsYh86nutxXPjx9SViqHcObn7r8TwIWNYU+oHKPfxC
b8EotWCqf2nW+CrdJFFRjTJtetn3JeAiU1pm9UwIkxhWci0loL0Zo3UpG/KITED/
FVvz7pu9xtQuoSLV2UDQ//5UAZgjXaGRC2TzJIBkTVe3LmxGck2epXzcQV1iGmQf
SwWsUsgGzq3bQU0prZ+4IFnyEZK+tvLtW/uJsmkomXeTVyFRlGY7tPpZmyir80Px
69fheYIwJAIWTNKgRfPkHCnPTcfrbH5e4vtfVmQXqaeA0G+k8oGV7Z1oCR21S6qM
uqQJhm8b68mACMv2ZeiSlixjyV78Fux4wXPr+SBZYtD//wqT5SHm9Il4Dipx9i3r
NdrecjPWvLjtmL8t3hZXVMk3KmROmUuaRwS7zEndA7XYFf1nRDN2fLEhpFeO4bZE
4JxW87PpwLVN7Z90Uvg1XUTCIjwONj8kSstmhFA+3vwXwmy+UJDHiLp8jsPybyv2
ZxDdBLH+l+eZufEh2m5q2lM9+wC4otqytS5kgL4lcb/Hh2rKU6zZ6sH1icTOmxvP
JEiTm/N4UkMq5J4posI2sXptGDiLS2YPRjmEd1WRQbUKlH1ui0YaxlpjJjjw8yaf
vTkJkawVvN5wPfQBQzD5
=9qSC
-END PGP SIGNATURE-

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

Re: Manager Doesn't Recognize context = /

Hi Christopher,

I don't use a WAR.  Everything is static (folder structure is already
set up in docRoot folder).  The WEB-INF folder is in the root.

Server.xml:

Host name=aa.bb.net debug=0
appBase=c:\domains\aa.bb.net unpackWARs=true 
   Valve className=org.apache.catalina.authenticator.SingleSignOn
debug=0 /
   Valve className=org.apache.catalina.valves.AccessLogValve
directory=logs prefix=staging_access. suffix=.log
pattern=common /
   Logger className=org.apache.catalina.logger.FileLogger
directory=c:\domains\aa.bb.net/logs  prefix=sa
suffix=.txt timestamp=true /

   Context path=/manager privileged=true
docBase=c:\Tomcat7\webapps\manager /

   Context path=/ docBase= debug=0 reloadable=true
crossContext=true /
/Host

On Thu, Jan 30, 2014 at 12:52 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Jerry,

 On 1/30/14, 1:31 PM, Jerry Malcolm wrote:
 I have a virtual server that has one app (other than manager), and
 this app resides at the root of the domain. I know that is not the
 best practices recommended... but it is what it is, and it works,
 at least other than with the manager.

 The manager lists the / context and tells me how many active
 sessions, etc.  But when I try to stop and restart the app using
 the buttons on that line on the manager, I get:

 FAIL - No context exists for path /

 Is there something I can do to the configuration to make the
 manager be able to stop/start this app?

 Thx.

 Jerry

 Server: Apache Tomcat/7.0.27 JVM:  1.7.0_13-b20 Win Server 2008

 Where is your WAR file (or exploded WAR dir) located (and what is it
 called)? How have you configured Tomcat to deploy the WAR (auto-deploy
 from webapps/, XML-file deployment from
 conf/[engine]/[host]/[webapp].xml, or directly in server.xml)?

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

 iQIcBAEBCAAGBQJS6p9uAAoJEBzwKT+lPKRYW84P/Ax+WPeKtLl3rgoimHFWNOUZ
 29HB2yMxyJfiD0iKoJyuGDDsYh86nutxXPjx9SViqHcObn7r8TwIWNYU+oHKPfxC
 b8EotWCqf2nW+CrdJFFRjTJtetn3JeAiU1pm9UwIkxhWci0loL0Zo3UpG/KITED/
 FVvz7pu9xtQuoSLV2UDQ//5UAZgjXaGRC2TzJIBkTVe3LmxGck2epXzcQV1iGmQf
 SwWsUsgGzq3bQU0prZ+4IFnyEZK+tvLtW/uJsmkomXeTVyFRlGY7tPpZmyir80Px
 69fheYIwJAIWTNKgRfPkHCnPTcfrbH5e4vtfVmQXqaeA0G+k8oGV7Z1oCR21S6qM
 uqQJhm8b68mACMv2ZeiSlixjyV78Fux4wXPr+SBZYtD//wqT5SHm9Il4Dipx9i3r
 NdrecjPWvLjtmL8t3hZXVMk3KmROmUuaRwS7zEndA7XYFf1nRDN2fLEhpFeO4bZE
 4JxW87PpwLVN7Z90Uvg1XUTCIjwONj8kSstmhFA+3vwXwmy+UJDHiLp8jsPybyv2
 ZxDdBLH+l+eZufEh2m5q2lM9+wC4otqytS5kgL4lcb/Hh2rKU6zZ6sH1icTOmxvP
 JEiTm/N4UkMq5J4posI2sXptGDiLS2YPRjmEd1WRQbUKlH1ui0YaxlpjJjjw8yaf
 vTkJkawVvN5wPfQBQzD5
 =9qSC
 -END PGP SIGNATURE-

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


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

Re: Manager Doesn't Recognize context = /

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jerry,

On 1/30/14, 2:06 PM, Jerry Malcolm wrote:
 Hi Christopher,
 
 I don't use a WAR.  Everything is static (folder structure is
 already set up in docRoot folder).  The WEB-INF folder is in the
 root.

You should probably switch deployment strategies. It will save you
headaches in the long-run.

 Server.xml:
 
 Host name=aa.bb.net debug=0 
 appBase=c:\domains\aa.bb.net unpackWARs=true  Valve
 className=org.apache.catalina.authenticator.SingleSignOn 
 debug=0 / Valve
 className=org.apache.catalina.valves.AccessLogValve 
 directory=logs prefix=staging_access. suffix=.log 
 pattern=common / Logger
 className=org.apache.catalina.logger.FileLogger 
 directory=c:\domains\aa.bb.net/logs  prefix=sa 
 suffix=.txt timestamp=true /
 
 Context path=/manager privileged=true 
 docBase=c:\Tomcat7\webapps\manager /
 
 Context path=/ docBase= debug=0 reloadable=true 
 crossContext=true / /Host

The Context path is incorrect. For the root context, you want to use
path= not path=/.

 Server: Apache Tomcat/7.0.27

You should seriously consider upgrading to a later version (current it
Tomcat 7.0.50).

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

iQIcBAEBCAAGBQJS6qOKAAoJEBzwKT+lPKRYtlkP/1tVSDaiGBMa4n4mWXOSCAIK
N/csRS1/RtiGEVyw4ApTLIrSx6yd70P0OafFWPKyFVZJUNQf1CtitWOOCb1ER8po
pFXKid47Trg17E1UIV8fIHfF8LtgoU9jpDnG4kO1Xh2VkekSvqqFfHtWaKk/eIgF
gQwpCz5rKD67lAnOpQmL7OG2LNrzcplyv6MwjfFP7emTvTIZFVSK8OUiYXQi9Loo
QoHPMM+nLYWoD9Gt4XgoooWUe5rdPJt67y7wBEIEPwZsvz0s1MEm1MMySPg12M28
v2kYzFDhtI9MPwc4QnHMjqZihfiVe8XayLZTearDt04UNgElAh30RdfExbpTThoj
fcFbe7yQlacvooccxEwoD5KX2pSZpdG3wdsKEwncPEDbSob8K7EMR+IhMq+t0vif
l00q7Ztcfue27Kuwc5nvhx7ty+EIbuKd5E+BJkjb3jGE5PK4XR8rWbOxjMFbmQUK
VNIPIryfZd/Vdk3PkrMZcJJhMLxByS1R1rTBjd7lch4hajcTlTaK7uEXKC7iWmbY
h5sVachHBYLBAE/fxyIe0NCi++Xx7z49pZvK9jMurgrnae1VG6S39TzP8SD9tcEs
82yId53HS9awTmySdi77qjLNt6hhRkRLH9ousPanOVjBh2FFKwNT0WVqst4bJ8cs
IknyXW7cNJNJmY7OD76r
=gDQx
-END PGP SIGNATURE-

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

RE: Manager Doesn't Recognize context = /

2014-01-30 Thread Jeffrey Janner

 -Original Message-
 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Sent: Thursday, January 30, 2014 1:10 PM
 To: Tomcat Users List
 Subject: Re: Manager Doesn't Recognize context = /

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Jerry,

 On 1/30/14, 2:06 PM, Jerry Malcolm wrote:
  Hi Christopher,

  I don't use a WAR.  Everything is static (folder structure is already
  set up in docRoot folder).  The WEB-INF folder is in the root.

 You should probably switch deployment strategies. It will save you
 headaches in the long-run.

  Server.xml:

  Host name=aa.bb.net debug=0
  appBase=c:\domains\aa.bb.net unpackWARs=true  Valve
  className=org.apache.catalina.authenticator.SingleSignOn
  debug=0 / Valve
  className=org.apache.catalina.valves.AccessLogValve
  directory=logs prefix=staging_access. suffix=.log
  pattern=common / Logger
  className=org.apache.catalina.logger.FileLogger
  directory=c:\domains\aa.bb.net/logs  prefix=sa
  suffix=.txt timestamp=true /

  Context path=/manager privileged=true
  docBase=c:\Tomcat7\webapps\manager /

  Context path=/ docBase= debug=0 reloadable=true
  crossContext=true / /Host

 The Context path is incorrect. For the root context, you want to use
 path= not path=/.

  Server: Apache Tomcat/7.0.27

 You should seriously consider upgrading to a later version (current it
 Tomcat 7.0.50).

I'm not totally surprised that this config works, but back when I used static 
deployment (not WAR files), I would have done it this way:
 Host name=aa.bb.net debug=0 appBase=anydirectory 
unpackWARs=false 
  Context path= docBase= c:\domains\aa.bb.net  debug=0 
reloadable=true
   crossContext=true / 
 /Host
And, of course, I'd have put the two Context entries into manager.xml and 
ROOT.xml files in the conf/{Engine}/{Host} directory and left off the path= 
parameter completely.

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

RE: Manager Doesn't Recognize context = /

 From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
 Subject: Re: Manager Doesn't Recognize context = /

  The WEB-INF folder is in the root.

I don't know exactly what that means, but it's probably a big mistake.

 You should probably switch deployment strategies. It will save you
 headaches in the long-run.

+1 to that.

  Valve className=org.apache.catalina.authenticator.SingleSignOn 
  debug=0 /

There is no debug attribute in any element of server.xml, and there hasn't been 
one for years.

  Logger className=org.apache.catalina.logger.FileLogger 
  directory=c:\domains\aa.bb.net/logs  prefix=sa 
  suffix=.txt timestamp=true /

The Logger element hasn't been valid in Tomcat for longer than I can 
remember.  This config smacks of someone blindly copying over a very, very old 
setup into a more recent installation.  Bad idea.

  Context path=/ docBase= debug=0 reloadable=true 
  crossContext=true /

 The Context path is incorrect. For the root context, you want to use
 path= not path=/.

Also, it is _always_ illegal to have an empty docBase.  Your default webapp 
must be named either ROOT.war or located in appBase/ROOT (ROOT is case 
sensitive, even on Windows).

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

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

Re: Manager Doesn't Recognize context = /

Thanks, Chris.  I'll make that change.

Regarding upgrading to the latest version, I know there are tons of
bug fixes and improvements in each version update.  But my paranoia
sets in, and I tend to get into the if it ain't broke, don't fix it
mode fearing that there's been some tweak in the latest version
that'll break something that currently works.  Other than bug fixes
and possibly improved stability, is there anything in 7.0.50 that is
an absolute must-have?  I'm willing to take the risk of upgrading if
there is a justifiable advantage to moving up.

On Thu, Jan 30, 2014 at 1:10 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Jerry,

 On 1/30/14, 2:06 PM, Jerry Malcolm wrote:
 Hi Christopher,

 I don't use a WAR.  Everything is static (folder structure is
 already set up in docRoot folder).  The WEB-INF folder is in the
 root.

 You should probably switch deployment strategies. It will save you
 headaches in the long-run.

 Server.xml:

 Host name=aa.bb.net debug=0
 appBase=c:\domains\aa.bb.net unpackWARs=true  Valve
 className=org.apache.catalina.authenticator.SingleSignOn
 debug=0 / Valve
 className=org.apache.catalina.valves.AccessLogValve
 directory=logs prefix=staging_access. suffix=.log
 pattern=common / Logger
 className=org.apache.catalina.logger.FileLogger
 directory=c:\domains\aa.bb.net/logs  prefix=sa
 suffix=.txt timestamp=true /

 Context path=/manager privileged=true
 docBase=c:\Tomcat7\webapps\manager /

 Context path=/ docBase= debug=0 reloadable=true
 crossContext=true / /Host

 The Context path is incorrect. For the root context, you want to use
 path= not path=/.

 Server: Apache Tomcat/7.0.27

 You should seriously consider upgrading to a later version (current it
 Tomcat 7.0.50).

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

 iQIcBAEBCAAGBQJS6qOKAAoJEBzwKT+lPKRYtlkP/1tVSDaiGBMa4n4mWXOSCAIK
 N/csRS1/RtiGEVyw4ApTLIrSx6yd70P0OafFWPKyFVZJUNQf1CtitWOOCb1ER8po
 pFXKid47Trg17E1UIV8fIHfF8LtgoU9jpDnG4kO1Xh2VkekSvqqFfHtWaKk/eIgF
 gQwpCz5rKD67lAnOpQmL7OG2LNrzcplyv6MwjfFP7emTvTIZFVSK8OUiYXQi9Loo
 QoHPMM+nLYWoD9Gt4XgoooWUe5rdPJt67y7wBEIEPwZsvz0s1MEm1MMySPg12M28
 v2kYzFDhtI9MPwc4QnHMjqZihfiVe8XayLZTearDt04UNgElAh30RdfExbpTThoj
 fcFbe7yQlacvooccxEwoD5KX2pSZpdG3wdsKEwncPEDbSob8K7EMR+IhMq+t0vif
 l00q7Ztcfue27Kuwc5nvhx7ty+EIbuKd5E+BJkjb3jGE5PK4XR8rWbOxjMFbmQUK
 VNIPIryfZd/Vdk3PkrMZcJJhMLxByS1R1rTBjd7lch4hajcTlTaK7uEXKC7iWmbY
 h5sVachHBYLBAE/fxyIe0NCi++Xx7z49pZvK9jMurgrnae1VG6S39TzP8SD9tcEs
 82yId53HS9awTmySdi77qjLNt6hhRkRLH9ousPanOVjBh2FFKwNT0WVqst4bJ8cs
 IknyXW7cNJNJmY7OD76r
 =gDQx
 -END PGP SIGNATURE-

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


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

Re: Manager Doesn't Recognize context = /

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chuck,

On 1/30/14, 2:24 PM, Caldarale, Charles R wrote:
 From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
 Subject: Re: Manager Doesn't Recognize context = /

 The WEB-INF folder is in the root.

 I don't know exactly what that means, but it's probably a big
 mistake.

 You should probably switch deployment strategies. It will save
 you headaches in the long-run.

 +1 to that.

 Valve
 className=org.apache.catalina.authenticator.SingleSignOn 
 debug=0 /

 There is no debug attribute in any element of server.xml, and there
 hasn't been one for years.

 Logger className=org.apache.catalina.logger.FileLogger 
 directory=c:\domains\aa.bb.net/logs  prefix=sa 
 suffix=.txt timestamp=true /

 The Logger element hasn't been valid in Tomcat for longer than I
 can remember.  This config smacks of someone blindly copying over a
 very, very old setup into a more recent installation.  Bad idea.

 Context path=/ docBase= debug=0 reloadable=true 
 crossContext=true /

 The Context path is incorrect. For the root context, you want
 to use path= not path=/.

 Also, it is _always_ illegal to have an empty docBase.  Your
 default webapp must be named either ROOT.war or located in
 appBase/ROOT (ROOT is case sensitive, even on Windows).

Oh, yeah. I didn't even notice that. The OP probably has
webapps/WEB-INF directory and a whole slew of security problems
because Tomcat has auto-deployed all the subdirectories of webapps/ to
their own separate contexts.

Jerry, you really have to fix your deployment.

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

iQIcBAEBCAAGBQJS6qgMAAoJEBzwKT+lPKRYQbEQALNa9CMDhXLmS7SOrIl8sBhB
+bDVZDw4P3o0H3vr2PHqzlL+LfznSFbxTNz9G0/Pcvd9Q7iugoJtgw0bwZKmlMA1
dEjDtftc4LG4mnNJHHCgPs2d8Rj9lPbEvk4znEVtRe0Ex7UpO9T7JbBgHqSsDyB8
pskD1o63jPrFK8qUR/+Z17NbomU5pf10pfzQfz/NT6P7PU1aBdv9G6PNeJCGVnun
td0QFc+5qDUVdBHGHXwdYjCRqGsrZm6xTGP3Xy28CaDsnhMXgwFlKfssTKWUs3Jy
bML8P6QVyV2co8nrA/nQROZkVoIAPvoWJfV1qFPcqBMpbadSlbVBxkZU2kusUHTC
Hb1P8+USfdswfyj5O2D8w1NGKSu2s3ISuvL6hlaMH4Eh0oHck2DkkQy1mn+3RPMf
BNgkKh3s1uMRH41J9aQcM7q2oDkiTJ5leBSBG7WxWwlA/Y6stDx25XcNMewvE2fM
acLI9XFWMy/16TpK0M+y4sGXh64m0h1r+TEQuumPPXCzIAEOMXmw70hA3SngYN3c
BtkDfDtWLOMl1P7CUVSfnxOlR3ToRqsQYHfP1k0lUPAGxmMGrIO1n/0qPqVlZ33l
JrvZpvrrkb11XY5KIbZPV0VK4O9F7IVYPyC303b9mZwdilQenfCt16HY2KzhNkyX
oKZBqMDD/H9QvYz/NJTU
=cyEi
-END PGP SIGNATURE-

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

RE: Manager Doesn't Recognize context = /

2014-01-30 Thread Jeffrey Janner

 -Original Message-
 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Sent: Thursday, January 30, 2014 1:29 PM
 To: Tomcat Users List
 Subject: Re: Manager Doesn't Recognize context = /

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Chuck,

 On 1/30/14, 2:24 PM, Caldarale, Charles R wrote:
  From: Christopher Schultz [mailto:ch...@christopherschultz.net]
  Subject: Re: Manager Doesn't Recognize context = /

  The WEB-INF folder is in the root.

  I don't know exactly what that means, but it's probably a big
 mistake.

  You should probably switch deployment strategies. It will save you
  headaches in the long-run.

  +1 to that.

  Valve
  className=org.apache.catalina.authenticator.SingleSignOn
  debug=0 /

  There is no debug attribute in any element of server.xml, and there
  hasn't been one for years.

  Logger className=org.apache.catalina.logger.FileLogger
  directory=c:\domains\aa.bb.net/logs  prefix=sa
  suffix=.txt timestamp=true /

  The Logger element hasn't been valid in Tomcat for longer than I
 can
  remember.  This config smacks of someone blindly copying over a very,
  very old setup into a more recent installation.  Bad idea.

  Context path=/ docBase= debug=0 reloadable=true
  crossContext=true /

  The Context path is incorrect. For the root context, you want to
  use path= not path=/.

  Also, it is _always_ illegal to have an empty docBase.  Your default
  webapp must be named either ROOT.war or located in appBase/ROOT
  (ROOT is case sensitive, even on Windows).

 Oh, yeah. I didn't even notice that. The OP probably has webapps/WEB-
 INF directory and a whole slew of security problems because Tomcat has
 auto-deployed all the subdirectories of webapps/ to their own separate
 contexts.

 Jerry, you really have to fix your deployment.

I would think his logs directory would be browsable, but as Chuck states, 
it's probably not being populated.
If anything, this looks like a server.xml and deployment strategy that hasn't 
been updated since Tomcat 4.x
Jeff

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

RE: Manager Doesn't Recognize context = /

 From: Jerry Malcolm [mailto:2ndgenfi...@gmail.com] 
 Subject: Re: Manager Doesn't Recognize context = /

 Other than bug fixes and possibly improved stability, is there 
 anything in 7.0.50 that is an absolute must-have?

Depends on how willing you are to have your site exposed to published security 
vulnerabilities, several of which have been fixed between 7.0.20 and .50 (look 
at the 7.0 changelog for details).

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

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

Re: Manager Doesn't Recognize context = /

 The Logger element hasn't been valid in Tomcat for longer than I can 
 remember.  This config smacks of someone blindly copying over a very, very 
 old setup into a more recent installation.  Bad idea.

You're making my point precisely about why I don't upgrade every time
a new release comes out.  Yes. I'm someone who 'blindly copies' a
config file, bad idea or not  I've got a major environment that
works and is in critical business path production for my client.  I
guess I'm supposed to take a blank piece of paper or some canned
template and re-create my entire configuration from scratch each time
I upgrade the server code.  But I'm going to have a tough time
explaining the down time to my client while I debug and try to get the
brand new config file back up and running and researching, for
example, why logger went away in the new release and what I need to
do to replace the functionality that worked in an earlier release.
This process may work for some users.  But it would put me out of
business.  This is why I'm on 7.0.27 and, sadly, will probably not be
moving soon.

Are there any config file migration tools available?

On Thu, Jan 30, 2014 at 1:27 PM, Jerry Malcolm 2ndgenfi...@gmail.com wrote:
 Thanks, Chris.  I'll make that change.

 Regarding upgrading to the latest version, I know there are tons of
 bug fixes and improvements in each version update.  But my paranoia
 sets in, and I tend to get into the if it ain't broke, don't fix it
 mode fearing that there's been some tweak in the latest version
 that'll break something that currently works.  Other than bug fixes
 and possibly improved stability, is there anything in 7.0.50 that is
 an absolute must-have?  I'm willing to take the risk of upgrading if
 there is a justifiable advantage to moving up.

 On Thu, Jan 30, 2014 at 1:10 PM, Christopher Schultz
 ch...@christopherschultz.net wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Jerry,

 On 1/30/14, 2:06 PM, Jerry Malcolm wrote:
 Hi Christopher,

 I don't use a WAR.  Everything is static (folder structure is
 already set up in docRoot folder).  The WEB-INF folder is in the
 root.

 You should probably switch deployment strategies. It will save you
 headaches in the long-run.

 Server.xml:

 Host name=aa.bb.net debug=0
 appBase=c:\domains\aa.bb.net unpackWARs=true  Valve
 className=org.apache.catalina.authenticator.SingleSignOn
 debug=0 / Valve
 className=org.apache.catalina.valves.AccessLogValve
 directory=logs prefix=staging_access. suffix=.log
 pattern=common / Logger
 className=org.apache.catalina.logger.FileLogger
 directory=c:\domains\aa.bb.net/logs  prefix=sa
 suffix=.txt timestamp=true /

 Context path=/manager privileged=true
 docBase=c:\Tomcat7\webapps\manager /

 Context path=/ docBase= debug=0 reloadable=true
 crossContext=true / /Host

 The Context path is incorrect. For the root context, you want to use
 path= not path=/.

 Server: Apache Tomcat/7.0.27

 You should seriously consider upgrading to a later version (current it
 Tomcat 7.0.50).

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

 iQIcBAEBCAAGBQJS6qOKAAoJEBzwKT+lPKRYtlkP/1tVSDaiGBMa4n4mWXOSCAIK
 N/csRS1/RtiGEVyw4ApTLIrSx6yd70P0OafFWPKyFVZJUNQf1CtitWOOCb1ER8po
 pFXKid47Trg17E1UIV8fIHfF8LtgoU9jpDnG4kO1Xh2VkekSvqqFfHtWaKk/eIgF
 gQwpCz5rKD67lAnOpQmL7OG2LNrzcplyv6MwjfFP7emTvTIZFVSK8OUiYXQi9Loo
 QoHPMM+nLYWoD9Gt4XgoooWUe5rdPJt67y7wBEIEPwZsvz0s1MEm1MMySPg12M28
 v2kYzFDhtI9MPwc4QnHMjqZihfiVe8XayLZTearDt04UNgElAh30RdfExbpTThoj
 fcFbe7yQlacvooccxEwoD5KX2pSZpdG3wdsKEwncPEDbSob8K7EMR+IhMq+t0vif
 l00q7Ztcfue27Kuwc5nvhx7ty+EIbuKd5E+BJkjb3jGE5PK4XR8rWbOxjMFbmQUK
 VNIPIryfZd/Vdk3PkrMZcJJhMLxByS1R1rTBjd7lch4hajcTlTaK7uEXKC7iWmbY
 h5sVachHBYLBAE/fxyIe0NCi++Xx7z49pZvK9jMurgrnae1VG6S39TzP8SD9tcEs
 82yId53HS9awTmySdi77qjLNt6hhRkRLH9ousPanOVjBh2FFKwNT0WVqst4bJ8cs
 IknyXW7cNJNJmY7OD76r
 =gDQx
 -END PGP SIGNATURE-

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


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

Re: Manager Doesn't Recognize context = /

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jerry,

On 1/30/14, 2:27 PM, Jerry Malcolm wrote:
 Regarding upgrading to the latest version, I know there are tons
 of bug fixes and improvements in each version update.  But my
 paranoia sets in, and I tend to get into the if it ain't broke,
 don't fix it mode fearing that there's been some tweak in the
 latest version that'll break something that currently works.

It's broke.

 Other than bug fixes and possibly improved stability, is there 
 anything in 7.0.50 that is an absolute must-have?  I'm willing to 
 take the risk of upgrading if there is a justifiable advantage to 
 moving up.

http://tomcat.apache.org/security-7.html

Another reason to maintain reasonable parity with Tomcat releases is
that the more you get into the process of upgrading, the less scary it
can be.

About 10 years ago, I inherited a project that was running on Tomcat
4.1.x and I too was petrified about upgrading. The kind folks on this
list laughed at me until I finally made the 4.1 - 5.5 - 6.0 - 7.0
migration. I probably could have saved myself a lot of trouble by just
junking the original configuration and going all the way up to Tomcat
7, but I went ahead and did the slow migration path.

I use our own internal release cycle to deploy updated versions of
Tomcat. We have a roughly-quarterly release cycle, and so we upgrade
Tomcat quite often. I have never had a testing-period go by where a
Tomcat upgrade has broken anything. Of course, YMMV.

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

iQIcBAEBCAAGBQJS6q2uAAoJEBzwKT+lPKRYYK4QAINpV6jzAz8LTP44d2hnQLlA
zskIoo+bWh/IggUndTha28yR2+IyxXz/h6kD6q/lC6kHyAk8iiIBltf25Zd3W/eO
Lbj/FX++Fdh5PyM9ZDl5YIEe5pdI4TcnOpPfvI345Q9ztzSI+URf0PQhT+TRG9gy
3dvpI94vF65vbca+feVq+u4kWGvJU3tG9ykpiaMS6H2eUBvWDH9ueAyiS2MGJb/2
oyGVGh6Oned00idLo+baa1YPUak3ut2ePJMnJ3yxwoKkFUeUv6r5DYOqKN+OFUAr
PCzXjwXjul7XhPvl2I9X+HMfnxwaHJQuDTqx1iDw4dTjLe5fBuQfZpkKQ7CAK1oH
juFQcTTiurkDTTxOWXy/w9V7LhYneV8oOWwrSsNxFRmjzdj8YX4QhSfQQxCSZRe6
tdl7mVjrFpzEukoXvR/jeR2Dk8FrX7ily+6ZourW59wP6NDX07o7+8FiHckLin+5
XXi9B36KeNr4fJ2TiVIW5rN1Z2U/7HlzbKCSAAzsmePrsKVyEmT4Mj27zJhxOIpP
K97lQ/Mb36edRwCAKpxeMpPoXY/E75omHNlBUL/I3I/FdA/LG63yNUtSpCJ6TE54
rvpkgmPi3gcb08fOdYBOkDPg80PFb8c451GaAe3Qat6uPqAViTR5Vpl0EAqBryQV
5Kk6ToF1RV087FXxrS3B
=A2ns
-END PGP SIGNATURE-

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

Re: Manager Doesn't Recognize context = /

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jerry,

On 1/30/14, 2:49 PM, Jerry Malcolm wrote:
 The Logger element hasn't been valid in Tomcat for longer
 than I can remember.  This config smacks of someone blindly
 copying over a very, very old setup into a more recent
 installation.  Bad idea.
 
 You're making my point precisely about why I don't upgrade every
 time a new release comes out.  Yes. I'm someone who 'blindly
 copies' a config file, bad idea or not  I've got a major
 environment that works and is in critical business path production
 for my client.

All the more reason why you should clean everything up.

 I guess I'm supposed to take a blank piece of paper or some canned
  template and re-create my entire configuration from scratch each 
 time I upgrade the server code.

Not necessarily. It would be good for you to identify how your
(server) configuration differs from the default. For us, the only
differences are in the Connector and Executor elements: everything
else is the same. We keep a server.xml template file under revision
control for every major version of Tomcat on which we expect to deploy
(e.g. 5.5, 6.0, 7.0) and usually point-releases don't require
modification of those files at all. Our build process merges the
template with the required values (port numbers, for instance) and
builds a working Tomcat instance.

If you move your Context configuration out of server.xml, that will
help a lot, too.

 But I'm going to have a tough time explaining the down time to my 
 client while I debug and try to get the brand new config file back
 up and running

That's what test environments are for. You can even set one up on a
laptop: they aren't that complicated.

 and researching, for example, why logger went away in the new 
 release and what I need to do to replace the functionality that 
 worked in an earlier release.

Logger went away in favor of a more standardized logging system
(which has caused a great deal of uproar within the community, I might
add).

 This process may work for some users.  But it would put me out of 
 business.  This is why I'm on 7.0.27 and, sadly, will probably not
 be moving soon.
 
 Are there any config file migration tools available?

Not really. Configurations are mostly simple: connector/port, maybe a
Host or two. We use the default configuration for Host (everything
is localhost, i.e. we don't care about formal virtual hosts), and
access logging is configured in our web app's META-INF/context.xml file.

Do you have any idea where your original configuration came from? You
could do a diff against the stock version of that configuration and
then make similar changes to a fresh server.xml from tomcat.apache.org.

I'm sure there are folks on the list who would be available to help
you physically do all this (for a fee, of course) and walk you through
the process (I myself might be such a person). Otherwise, you are free
to post as many questions as you'd like and we'll try to answer them,
explain, etc.

It's really worth putting the time in to clean-up our configuration
and understand what is going on. That will make updates less painful
and scary.

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

iQIcBAEBCAAGBQJS6q+/AAoJEBzwKT+lPKRYmTYP/3PCNlck5jdP9gaRxGvjeg3m
Y9VlfsPE2WkXCHXY0k+kxvmsIC8AOoz3x9olYlc0VVr2FqcB9m6go424RLPxNBK0
TFICD8NEo1so31ZZekyK0waUZI6pu1Cbeb3bHJKdL60pfbuiEhm5RN4vJrGIdqph
C3CtNOngCqolIc9VKXpc/n1GvO761gDH+nWwv2kz8XyrY/j0sMV5yiHfRc1WjXe/
iNBXLFmjoQgWf5LfTv4leBca0QC67++c1C6kEopm+uF7M68tmt9vDcxjTee3MWHb
IFzJEokjye7lmPXmZkr+ytoelMghK8EPVJXmtgezLl5yRD/qZif6mMm5ETNEuMS/
fJWgmlNm14USGfgZg5BH1znm4yPlyU97VnfGz4EMf6qBr7tGEZqrKgEgzfl/ttGL
MS4wxllpoG6yfPn5InD3heHbg9rVZ9DbtefjGhEWSNo9li0kCvaRhMdMlWEqQWni
QKPdrmO/MsBh53N7RHuzS29E81RrExBFVANrklqhyqDgHbCJNFu3jnOYDu6IezzE
Tzo2Oahh34U6T1XLt5X5QVnaX5UEFjP5IQxgQpX6FNGssVBR9jiKZ5W1C01XG5bh
FPQCWV7SbMWMWv6MV+55ypAURZIzUON/c1ICBnrH+RyY6XlfBpewL7mp0utq1Ifa
F2ydDKM7NRBbT2Z/IIsE
=my7M
-END PGP SIGNATURE-

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

Re: Tomcat 8.0.0-RC5: asynchron IO and back pressure with ReadListener

2014-01-30 Daniel Mikusa dmik...@gopivotal.com:
On Jan 30, 2014, at 11:18 AM, Yann Simon yann.simon...@gmail.com wrote:

Hi,

I wrote a sample app to demonstrate the problem:
https://github.com/yanns/servlet31_async

You can generate an exploded war with maven: mvn war:exploded
I deployed the application in tomcat 8.0.0-RC10.

The 2 upload form does work.
The 1st upload form uses a new thread in , and that does not work.
https://github.com/yanns/servlet31_async/blob/master/src/main/java/com/yann/ReadListenerImpl.java#L22

I’m not sure I see the point of the code here. If you force it to block with
Thread.sleep() you’re going to tie up the thread that you’ve created and
you’re going to be back to having threads sitting around and doing nothing.
If that’s the case, you may as well save yourself some trouble and use the
blocking apis.

This sample application is only a simple way to show what I want to
achieve with a more complex application that I mentioned at the
beginning of the thread:
https://github.com/yanns/play2-war-plugin/blob/servlet31/project-code/core/servlet31/src/main/scala/play/core/server/servlet31/RequestHandler31.scala#L80

Let me try to explain the use case:
let's say we want to save the uploaded file chunk by chunk in a
database, for which we have an asynchronous API.
- we receive the first chunk, that we can read synchronously in
onDataAvailable, no problem so far
- we trigger the saving of this chunk in the database, and of course,
we do not wait for the completion of the operation
- we receive the signal that a new chunk is available - the container
call onDataAvailable
- we cannot push this chunk into the database, as the first operation
is not completed
- we asynchronously wait for the completion of the database operation.
We do not read any data so that the container push the pressure back
to the browser, telling it to slowdown. We do not want to block any
thread here. That's why we must exit the onDataAvailable without
having read any data.
- when the database says us that it is ready for a new operation (by a
callback, or an event), then we can read the second chunk and trigger
the save operation in the database

This a what I simulated with the new Thread and Thread.sleep.
In reality, there are no new Thread - it just simulates that at some
point later, the database driver informs us that the database is ready
for a new operation.
There are no Thread.sleep neither - it just simulates a slow database
to check the back-pressure mechanism that the container should do on
the browser.

Also, if you said that I must consume the chunks synchronously in
onDataAvailable, I can simply not implement this double triggering
(from browser and from database) without blocking any thread. For me,
it means that I cannot totally use the asynchronous IO mechanism of
the OS.

I hope I made my goals clear.

Cheers,
Yann

Here’s what I’d suggest to make this work.

You still need additional threads with this approach, but it’s not one to
one. A small thread pool can service many requests because the thread is
only active when data is being read.

Here’s an example of this in action.

http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/tree/jetty-servlets/src/main/java/org/eclipse/jetty/servlets/DataRateLimitedServlet.java

Dan

The onDataAvailable is called only one time.

With jetty, it does work (mvn jetty:run)

I hope this can help.

Yann

2014-01-08 Yann Simon yann.simon...@gmail.com:
2014/1/8 Daniel Mikusa dmik...@gopivotal.com:
On Jan 8, 2014, at 12:04 PM, Yann Simon yann.simon...@gmail.com wrote:

Hi,

I am trying to write a servlet that asynchronously read data from the
servlet request input stream.
I tested my servlet with tomcat 8.0.0-RC5.

If possible, you might want to try 8.0.0-RC10 or trunk and see if you're
getting the same behavior.

the symptoms:
- I must synchronously read the input stream in onDataAvailable() so
that the upload works

Do you have a code sample? It would help to see what you're doing.

I expected onDataAvailable() to be called again when I consumed all the
data
(servletInputStream.isReady becomes false)

Generally this sounds OK. When you call

Re: Manager Doesn't Recognize context = /

ok... I'm going to bite the bullet and move forward... I've set up a
sandbox and downloaded 7.0.50.

As I started comparing my server.xml to the template in the 7.0.50, I
realized that I actually did start from the template for 7.0.27 for
everything except the context blocks.  That's where I hit a brick wall
and just copied all of the contexts from the original
who-knows-how-far-back config.

Here's my main problem that I simply cannot figure out at this
point In my environment, I have the same web app deployed across
several virtual hosts.  With each host I have a different database.
The way I learned to configure things eternities ago was to simply
include all of the context blocks inside the host blocks in
server.xml.  And then I'd define different resource tags referencing
the different databases inside each context block:

host 1
 context 'myApp1'.
 resource database = host1dbForMyApp1.
 /context
/host

host 2
 context 'myApp1'.
 resource database = host2dbForMyApp1.
 /context
/host

That's worked fine.  I have known for a while that the recommendation
is to NOT include context blocks in server.xml and to rather create
context.xml files in META-INF directory.  Fine but here's the wall
I'm hitting if I have one context.xml for myApp1 that now is
common to all hosts, HOW do I tell myApp1 to use one db resource for
host1 and a different db resource for host2?  I've read through tons
of the how-to pages in the docs, and I'm coming up empty.  I would
think it would make sense to define the resource at the host level.
But according to what I can find in the docs, a resource tag is not
legal directly under a host tag.

If you can help me out with this, I'll be well on my way

Thanks.

On Thu, Jan 30, 2014 at 2:02 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Jerry,

 On 1/30/14, 2:49 PM, Jerry Malcolm wrote:
 The Logger element hasn't been valid in Tomcat for longer
 than I can remember.  This config smacks of someone blindly
 copying over a very, very old setup into a more recent
 installation.  Bad idea.

 You're making my point precisely about why I don't upgrade every
 time a new release comes out.  Yes. I'm someone who 'blindly
 copies' a config file, bad idea or not  I've got a major
 environment that works and is in critical business path production
 for my client.

 All the more reason why you should clean everything up.

 I guess I'm supposed to take a blank piece of paper or some canned
  template and re-create my entire configuration from scratch each
 time I upgrade the server code.

 Not necessarily. It would be good for you to identify how your
 (server) configuration differs from the default. For us, the only
 differences are in the Connector and Executor elements: everything
 else is the same. We keep a server.xml template file under revision
 control for every major version of Tomcat on which we expect to deploy
 (e.g. 5.5, 6.0, 7.0) and usually point-releases don't require
 modification of those files at all. Our build process merges the
 template with the required values (port numbers, for instance) and
 builds a working Tomcat instance.

 If you move your Context configuration out of server.xml, that will
 help a lot, too.

 But I'm going to have a tough time explaining the down time to my
 client while I debug and try to get the brand new config file back
 up and running

 That's what test environments are for. You can even set one up on a
 laptop: they aren't that complicated.

 and researching, for example, why logger went away in the new
 release and what I need to do to replace the functionality that
 worked in an earlier release.

 Logger went away in favor of a more standardized logging system
 (which has caused a great deal of uproar within the community, I might
 add).

 This process may work for some users.  But it would put me out of
 business.  This is why I'm on 7.0.27 and, sadly, will probably not
 be moving soon.

 Are there any config file migration tools available?

 Not really. Configurations are mostly simple: connector/port, maybe a
 Host or two. We use the default configuration for Host (everything
 is localhost, i.e. we don't care about formal virtual hosts), and
 access logging is configured in our web app's META-INF/context.xml file.

 Do you have any idea where your original configuration came from? You
 could do a diff against the stock version of that configuration and
 then make similar changes to a fresh server.xml from tomcat.apache.org.

 I'm sure there are folks on the list who would be available to help
 you physically do all this (for a fee, of course) and walk you through
 the process (I myself might be such a person). Otherwise, you are free
 to post as many questions as you'd like and we'll try to answer them,
 explain, etc.

 It's really worth putting the time in to clean-up our configuration
 and understand what

Re: Manager Doesn't Recognize context = /

2014-01-30 Thread Mark Thomas

On 30/01/2014 21:43, Jerry Malcolm wrote:
 That's worked fine.  I have known for a while that the
 recommendation is to NOT include context blocks in server.xml and
 to rather create context.xml files in META-INF directory.  Fine
 but here's the wall I'm hitting if I have one context.xml for
 myApp1 that now is common to all hosts, HOW do I tell myApp1 to use
 one db resource for host1 and a different db resource for host2?
 I've read through tons of the how-to pages in the docs, and I'm
 coming up empty.  I would think it would make sense to define the
 resource at the host level. But according to what I can find in the
 docs, a resource tag is not legal directly under a host tag.
 
 If you can help me out with this, I'll be well on my way

Take what was in the Context .../ blocks in server.xml and move them
into separate context.xml files. These files need to be named to match
the context names (e.g. for an app with path /foo, name the file
foo.xml). Then place then in the following directory structure:
$CATALINA_BASE/conf/engine-name/host-name/context-xml-files-go-here

So each virtual host has its own directory.

HTH,

Mark

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

Re: Tomcat 8.0.0-RC5: asynchron IO and back pressure with ReadListener

2014-01-30 Thread Daniel Mikusa

On Jan 30, 2014, at 3:38 PM, Yann Simon yann.simon...@gmail.com wrote:

2014-01-30 Daniel Mikusa dmik...@gopivotal.com:
On Jan 30, 2014, at 11:18 AM, Yann Simon yann.simon...@gmail.com wrote:

Hi,

I wrote a sample app to demonstrate the problem:
https://github.com/yanns/servlet31_async

You can generate an exploded war with maven: mvn war:exploded
I deployed the application in tomcat 8.0.0-RC10.

The 2 upload form does work.
The 1st upload form uses a new thread in , and that does not work.
https://github.com/yanns/servlet31_async/blob/master/src/main/java/com/yann/ReadListenerImpl.java#L22

I’m not sure I see the point of the code here. If you force it to block
with Thread.sleep() you’re going to tie up the thread that you’ve created
and you’re going to be back to having threads sitting around and doing
nothing. If that’s the case, you may as well save yourself some trouble and
use the blocking apis.

I haven’t looked at your code. I’m not a Scala guy, so I can’t begin to
comment on that. What you’ve described below sounds feasible though.
Including some notes below.

Ok. Because this is our first call to onDataAvailable, the container is going
to handle that for us. Question. Are we reading until isReady() returns false
here? or are we existing onDataAvailable with data that still needs to be
read? This is important to know so we know who’s responsibility it is to
continue the reading process.

- we trigger the saving of this chunk in the database, and of course,
we do not wait for the completion of the operation

- we receive the signal that a new chunk is available - the container
call onDataAvailable

This is not quite correct. The container won’t call onDataAvailable here,
unless you read all of the data that was available in the first step (i.e. read
till isReady() returns false). It’s not specified, but it doesn’t sound like
that’s your intent here.

- we cannot push this chunk into the database, as the first operation
is not completed

Ok. At this point, you’re going to have to either buffer data or stop reading.
It sounds like you want to do the later, so you’re going to need to make sure
something in your code starts reading again when your code can process more
data, since the container is not going to handle the call back.

- we asynchronously wait for the completion of the database operation.
We do not read any data so that the container push the pressure back
to the browser, telling it to slowdown. We do not want to block any
thread here. That's why we must exit the onDataAvailable without
having read any data.

Sounds OK, but you’re now responsible for making sure that the rest of the data
is consumed. If you don’t do this, the request will appear to hang until it
times out.

- when the database says us that it is ready for a new operation (by a
callback, or an event), then we can read the second chunk and trigger
the save operation in the database

Once the database write is complete, you’re just going to need to call
onDataAvailable manually some how. The container won’t do it because you
previously exited before isReady() returned false.

Ok, I understand what you’re going for here.

The non-blocking API that Servlet 3.1 exposes is pretty flexible, but things
get complicated quick. I don’t see any reason why you couldn’t do what you’ve
described. It’s just going to be complicated. You’re going to have to know
when the container will call onDataAvailable and when you need to call it.

Hope that helps.

Dan

I hope I made my goals clear.

Cheers,
Yann

Here’s what I’d suggest to make this work.

- in onDataAvailable read as much data as possible
- if you read until

Re: Manager Doesn't Recognize context = /

Makes sense... thanks

I'll be back :-)

On Thu, Jan 30, 2014 at 4:00 PM, Mark Thomas ma...@apache.org wrote:
 On 30/01/2014 21:43, Jerry Malcolm wrote:
 That's worked fine.  I have known for a while that the
 recommendation is to NOT include context blocks in server.xml and
 to rather create context.xml files in META-INF directory.  Fine
 but here's the wall I'm hitting if I have one context.xml for
 myApp1 that now is common to all hosts, HOW do I tell myApp1 to use
 one db resource for host1 and a different db resource for host2?
 I've read through tons of the how-to pages in the docs, and I'm
 coming up empty.  I would think it would make sense to define the
 resource at the host level. But according to what I can find in the
 docs, a resource tag is not legal directly under a host tag.

 If you can help me out with this, I'll be well on my way

 Take what was in the Context .../ blocks in server.xml and move them
 into separate context.xml files. These files need to be named to match
 the context names (e.g. for an app with path /foo, name the file
 foo.xml). Then place then in the following directory structure:
 $CATALINA_BASE/conf/engine-name/host-name/context-xml-files-go-here

 So each virtual host has its own directory.

 HTH,

 Mark

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


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

Tomcat Maven plugin with JDK 1.7.0_51 and fork set to true


Folks,

I'm trying to create some integration tests with the Maven plugin.

OS: Fedora 20 64 bit
Windows 7 Home Premium 64 bit
JRE:1.7.0_51
JDK:1.7.0_51
Maven:  3.12 on Fedora
3.10 on Windows
Plugin: 2.2

First thing is I guess I've misunderstood the forktrue/fork 
configuration option. I was hoping it would start up a Tomcat process in 
a separate JVM, but that doesn't seem to happen (at least with the 
Tomcat 6 plugin and JRE/JDK 1.6).


However, I need forktrue/fork so I can then run some integration 
tests. Setting this causes the following errors (from Maven 3.12 on Linux):


Tomcat 6


Exception in thread Thread-2 java.lang.NoClassDefFoundError:
   org/apache/catalina/Authenticator
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2531)
at java.lang.Class.getMethod0(Class.java:2774)
at java.lang.Class.getMethod(Class.java:1663)
at
org.apache.tomcat.maven.common.run.EmbeddedRegistry.shutdownAll(EmbeddedRegistry.java:109)
at
org.apache.tomcat.maven.common.run.EmbeddedRegistry$1.run(EmbeddedRegistry.java:69)

Caused by: java.lang.ClassNotFoundException:
   org.apache.catalina.Authenticator
at
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
... 6 more

Tomcat 7


ERROR: IllegalAccessException for stop method in class
   org.apache.tomcat.maven.plugin.tomcat7.run.ExtendedTomcat
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.tomcat.maven.common.run.EmbeddedRegistry.shutdownAll(EmbeddedRegistry.java:110)
at
org.apache.tomcat.maven.common.run.EmbeddedRegistry$1.run(EmbeddedRegistry.java:69)

Caused by: java.lang.NoClassDefFoundError:
   org/apache/tomcat/util/ExceptionUtils
at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:234)
at org.apache.catalina.startup.Tomcat.stop(Tomcat.java:351)

I'm guessing that this is due to the new security constraints with JRE 
1.7.0_51.


(Apologies for ugly mail wrapping)

Any ideas as to how this can be addressed?

Thanks,

Mark
/mde/

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

Re: Manager Doesn't Recognize context = /


Please don't top-post . . .

Comments at the bottom.

On 1/30/2014 1:43 PM, Jerry Malcolm wrote:

ok... I'm going to bite the bullet and move forward... I've set up a
sandbox and downloaded 7.0.50.

As I started comparing my server.xml to the template in the 7.0.50, I
realized that I actually did start from the template for 7.0.27 for
everything except the context blocks.  That's where I hit a brick wall
and just copied all of the contexts from the original
who-knows-how-far-back config.

Here's my main problem that I simply cannot figure out at this
point In my environment, I have the same web app deployed across
several virtual hosts.  With each host I have a different database.
The way I learned to configure things eternities ago was to simply
include all of the context blocks inside the host blocks in
server.xml.  And then I'd define different resource tags referencing
the different databases inside each context block:

host 1
  context 'myApp1'.
  resource database = host1dbForMyApp1.
  /context
/host

host 2
  context 'myApp1'.
  resource database = host2dbForMyApp1.
  /context
/host

That's worked fine.  I have known for a while that the recommendation
is to NOT include context blocks in server.xml and to rather create
context.xml files in META-INF directory.  Fine but here's the wall
I'm hitting if I have one context.xml for myApp1 that now is
common to all hosts, HOW do I tell myApp1 to use one db resource for
host1 and a different db resource for host2?  I've read through tons
of the how-to pages in the docs, and I'm coming up empty.  I would
think it would make sense to define the resource at the host level.
But according to what I can find in the docs, a resource tag is not
legal directly under a host tag.

If you can help me out with this, I'll be well on my way

Thanks.

On Thu, Jan 30, 2014 at 2:02 PM, Christopher Schultz
ch...@christopherschultz.net wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jerry,

On 1/30/14, 2:49 PM, Jerry Malcolm wrote:

The Logger element hasn't been valid in Tomcat for longer
than I can remember.  This config smacks of someone blindly
copying over a very, very old setup into a more recent
installation.  Bad idea.


You're making my point precisely about why I don't upgrade every
time a new release comes out.  Yes. I'm someone who 'blindly
copies' a config file, bad idea or not  I've got a major
environment that works and is in critical business path production
for my client.


All the more reason why you should clean everything up.


I guess I'm supposed to take a blank piece of paper or some canned
  template and re-create my entire configuration from scratch each
time I upgrade the server code.


Not necessarily. It would be good for you to identify how your
(server) configuration differs from the default. For us, the only
differences are in the Connector and Executor elements: everything
else is the same. We keep a server.xml template file under revision
control for every major version of Tomcat on which we expect to deploy
(e.g. 5.5, 6.0, 7.0) and usually point-releases don't require
modification of those files at all. Our build process merges the
template with the required values (port numbers, for instance) and
builds a working Tomcat instance.

If you move your Context configuration out of server.xml, that will
help a lot, too.


But I'm going to have a tough time explaining the down time to my
client while I debug and try to get the brand new config file back
up and running


That's what test environments are for. You can even set one up on a
laptop: they aren't that complicated.


and researching, for example, why logger went away in the new
release and what I need to do to replace the functionality that
worked in an earlier release.


Logger went away in favor of a more standardized logging system
(which has caused a great deal of uproar within the community, I might
add).


This process may work for some users.  But it would put me out of
business.  This is why I'm on 7.0.27 and, sadly, will probably not
be moving soon.

Are there any config file migration tools available?


Not really. Configurations are mostly simple: connector/port, maybe a
Host or two. We use the default configuration for Host (everything
is localhost, i.e. we don't care about formal virtual hosts), and
access logging is configured in our web app's META-INF/context.xml file.

Do you have any idea where your original configuration came from? You
could do a diff against the stock version of that configuration and
then make similar changes to a fresh server.xml from tomcat.apache.org.

I'm sure there are folks on the list who would be available to help
you physically do all this (for a fee, of course) and walk you through
the process (I myself might be such a person). Otherwise, you are free
to post as many questions as you'd like and we'll try to answer them,
explain, etc.

It's really worth putting

Re: Manager Doesn't Recognize context = /

well I thought I had it down.  but now things aren't working.

I have a directory structure: c:\domains\myhost\webapps\aWebApp\

In server.xml, I've defined the host with appRoot of c:\domains\myhost\webapps

I want the url to this webapp to be myHost.com/aaa

So according to the instructions above, I created a context file:

.\conf\Catalina\myHost\aaa.xml   (using the url context path)

In the file aaa.xml I defined the context with path=/aaa and
docBase=aWebApp

When I start TC, I first get this error in the catalina log:

WARNING: A docBase c:\domains\myHost\webapps\aWebApp inside the host
appBase has been specified, and will be ignored

followed by an error saying .myHost\webapps\aaa can't be found or
is not a readable directory.

Well it definitely makes sense that if it's going to ignore the
docBase specification, it isn't going to find the right directory.

What am I doing wrong?

Thx.

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

RE: Manager Doesn't Recognize context = /

 From: Jerry Malcolm [mailto:2ndgenfi...@gmail.com] 
 Subject: Re: Manager Doesn't Recognize context = /

 I have a directory structure: c:\domains\myhost\webapps\aWebApp\

 In server.xml, I've defined the host with appRoot of c:\domains\myhost\webapps

Do you mean appBase?  (Precision counts.)  Assuming that's supposed to be 
appBase, anything under that directory will be automatically deployed (unless 
you've disable that).

 I want the url to this webapp to be myHost.com/aaa

Then name the directory aaa, not aWebApp (or see below).

 So according to the instructions above, I created a context file:
 .\conf\Catalina\myHost\aaa.xml   (using the url context path)

 In the file aaa.xml I defined the context with path=/aaa and
 docBase=aWebApp

The path attribute is not allowed here, and the docBase, if present, must 
either match the name of the .xml file or point to a location outside of 
appBase.  If the latter, put your webapp directory there, not under appBase.

 When I start TC, I first get this error in the catalina log:

 WARNING: A docBase c:\domains\myHost\webapps\aWebApp inside the host
 appBase has been specified, and will be ignored

 followed by an error saying .myHost\webapps\aaa can't be found or
 is not a readable directory.

Both diagnostics are accurate and appropriate.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

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

Re: Manager Doesn't Recognize context = /

Thanks so much for the info and ongoing education.  I think I'm
getting there.  But please bear with me.  I'm still trying to get a
handle on how this all works and what the best practices are.

I now understand that TC will take all folders it finds in the appBase
folder and deploy them, assuming they are all webapps.  I'm assuming
from what you said that the default path for each webapp is the folder
name in appBase.  I realize that this is super easy as long as you
don't have any unique things to specify about the deployment such as a
database resource.

So assuming I need to specify more info about a particular webapp
deployment, I can define a context file that augments the deployment
info for a particular auto-deployed app in appBase.  But from what you
said previously regarding the error I was getting, if the webapp is in
appBase, I have no choice but to use the appBase's folder name as the
context path.  Am I correct so far?

But if I put the webapp anywhere outside of the appBase folder, I can
now create a context file for the app using any desired context path
as the name of the context file and point to the webapp, no matter
what the name or location using docBase, correct?

If my understanding is correct, then fine.  I'm one step closer...  It
does seem strange that I can't alias the context path to get to an
appBase webapp using a desired URL.  But I'm sure there are reasons,
and if that's the way it is, fine.  I just need to understand the
rules.  But all of this did work with path aliasing in 7.0.27 when I
just had all of the context tags directly in server.xml.  So that's
why I'm struggling with the changes to the rules and capabilities.

So the simple answer as far as doing things correctly in TC is to
rename all of my webapps in the appBase folder to match their
associated context paths.  I will likely head that direction.  But I
have a pretty complex automated build process that I will need to go
into and modify things to get this implemented.  Unfortunately, that
can't happen overnight.

In the meantime, I've got lots of webapps from my earlier, currently
working config that use a context path that is different from the
appBase folder name.  I think I know what I can do.  But I want to see
if it violates the rules and how bad.

My proposal is to keep the appBase pointing to the webapps folder.
And any webapps that have matching paths and names can go there and
work fine.

Next, until I can change the build process to create the webapps named
as the context path, can I create a parallel webapps2 folder and NOT
point appBase to it and put all of the 'misnamed' webapps in there?
Then go to the context files for those webapps and fully qualify the
docBase (c:\domains\myHost\webapps2\myWebApp1)?

I realize this is not the recommended design.  But I need a stopgap
solution until I can change the build process.  So, is this solution
at least an acceptable one in the interim?  If not, what is the best
way for me to keep my misnamed webapps that don't match the context
path for a while and still keep the lights on?

Thanks.

Jerry

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

Re: Manager Doesn't Recognize context = /


On 1/30/2014 5:33 PM, Jerry Malcolm wrote:

well I thought I had it down.  but now things aren't working.

I have a directory structure: c:\domains\myhost\webapps\aWebApp\

In server.xml, I've defined the host with appRoot of c:\domains\myhost\webapps

I want the url to this webapp to be myHost.com/aaa

So according to the instructions above, I created a context file:

.\conf\Catalina\myHost\aaa.xml   (using the url context path)

In the file aaa.xml I defined the context with path=/aaa and
docBase=aWebApp



Do NOT define a path. It is taken from the name of the xml file.


When I start TC, I first get this error in the catalina log:

WARNING: A docBase c:\domains\myHost\webapps\aWebApp inside the host
appBase has been specified, and will be ignored

followed by an error saying .myHost\webapps\aaa can't be found or
is not a readable directory.

Well it definitely makes sense that if it's going to ignore the
docBase specification, it isn't going to find the right directory.

What am I doing wrong?

Thx.


Jerry,

A. docBase versus appBase

From the documentation at 
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html:


===
docBase

The Document Base (also known as the Context Root) directory for this 
web application, or the pathname to the web application archive file (if 
this web application is being executed directly from the WAR file). You 
may specify an absolute pathname for this directory or WAR file, or a 
pathname that is relative to the appBase directory of the owning Host.


The value of this field must not be set unless the Context element is 
defined in server.xml or the docBase is not located under the Host's 
appBase.



Let's parse that a bit:

The docBase is relative to the appBase of the owning host.

So in server.xml, if you have a host element like the following:

Host name=myHost.com  appBase=c:\domains\myHost\webapps
  unpackWARs=true autoDeploy=true
/Host

And you have a docBase in your aaa.xml file that looks like the following:

Context docBase=aWebApp
/Context

Then Tomcat is going to look for the application in:

c:\domains\myHost\webapps\aWebApp

And this, according to the documentation that I quoted above is not legal.

Don't do this.

B. path attribute

From the documentation at 
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html:


===
path

The context path of this web application, which is matched against the 
beginning of each request URI to select the appropriate web application 
for processing. All of the context paths within a particular Host must 
be unique. If you specify a context path of an empty string (), you 
are defining the default web application for this Host, which will 
process all requests not assigned to other Contexts.


This attribute must only be used when statically defining a Context in 
server.xml. In all other circumstances, the path will be inferred from 
the filenames used for either the .xml context file or the docBase.


Even when statically defining a Context in server.xml, this attribute 
must not be set unless either the docBase is not located under the 
Host's appBase or both deployOnStartup and autoDeploy are false. If this 
rule is not followed, double deployment is likely to result.

===

Let's parse that a bit:

In short it says the following:

Do NOT define a path element unless the following statements are true.

1. Context element is in server.xml
2. One of the following:
   a. the docBase is NOT in the Host's appBase (see above)
  or
   b. both deployOnStartup and autoDeploy are false (not the default)

In all other cases the path is inferred from either the
conf\Catalina\[hostname]\appName.xml file or the WAR file name or the 
directory name in appBase.


Please also note that ROOT is the special name (case is important, even 
on Windows) reserved for the default web application for the enclosing Host.


You can do this several ways.

1. ROOT.war or the directory ROOT in appBase
2. ROOT.xml in conf\Catalina\[hostname]
   a. no path element
   b. docBase to application MUST be outside of the Host's appBase
3. Context in server.xml
   a. strongly discouraged
   b. several restrictions
  i. docBase MUST be outside of the Host's appBase
 or
  ii. both deployOnStartup and autoDeploy are false (not the
  default)
   c. Then you can define a path=

That's it.



I have written a Wiki article on how to set up virtual hosts using 
Tomcat. It is available here:


http://wiki.apache.org/tomcat/TomcatDevelopmentVirtualHosts

While it is a bit dated and references a development environment, the 
same structure is valid today. We run a variant of the structure 
documented in that wiki article in production and it works well.


/mde/

-
To unsubscribe, e-mail:

Re: Manager Doesn't Recognize context = /


Jerry,

On 1/30/2014 6:39 PM, Jerry Malcolm wrote:

Thanks so much for the info and ongoing education.  I think I'm
getting there.  But please bear with me.  I'm still trying to get a
handle on how this all works and what the best practices are.



It's really not what the best practices are, it's what is documented.


I now understand that TC will take all folders it finds in the appBase
folder and deploy them, assuming they are all webapps.  I'm assuming
from what you said that the default path for each webapp is the folder
name in appBase.  I realize that this is super easy as long as you
don't have any unique things to specify about the deployment such as a
database resource.

So assuming I need to specify more info about a particular webapp
deployment, I can define a context file that augments the deployment
info for a particular auto-deployed app in appBase.  But from what you
said previously regarding the error I was getting, if the webapp is in
appBase, I have no choice but to use the appBase's folder name as the
context path.  Am I correct so far?



Read the following:

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

It goes into great detail concerning how paths are determined.

In short, correct.


But if I put the webapp anywhere outside of the appBase folder, I can
now create a context file for the app using any desired context path
as the name of the context file and point to the webapp, no matter
what the name or location using docBase, correct?



Yes


If my understanding is correct, then fine.  I'm one step closer...  It
does seem strange that I can't alias the context path to get to an
appBase webapp using a desired URL.


This is not Apache HTTPD. Do not think of the directories as you would 
there (Location, Directory, Alias). It's not applicable here.



But I'm sure there are reasons,
and if that's the way it is, fine.  I just need to understand the
rules.  But all of this did work with path aliasing in 7.0.27 when I
just had all of the context tags directly in server.xml.


I suspect that there were lots of error messages, and potentially double 
deployment. So, while your content may have been served from Tomcat, 
working is a relative term.



So that's
why I'm struggling with the changes to the rules and capabilities.



These rules have been in place since at least Tomcat 6.


So the simple answer as far as doing things correctly in TC is to
rename all of my webapps in the appBase folder to match their
associated context paths.  I will likely head that direction.  But I
have a pretty complex automated build process that I will need to go
into and modify things to get this implemented.  Unfortunately, that
can't happen overnight.

In the meantime, I've got lots of webapps from my earlier, currently
working config that use a context path that is different from the
appBase folder name.


You mean docBase (I think).

docBase - the document base for an individual application
appBase - where all of a particular Host's applications live

Again, see the following:

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


I think I know what I can do.  But I want to see
if it violates the rules and how bad.

My proposal is to keep the appBase pointing to the webapps folder.
And any webapps that have matching paths and names can go there and
work fine.

Next, until I can change the build process to create the webapps named
as the context path, can I create a parallel webapps2 folder and NOT
point appBase to it and put all of the 'misnamed' webapps in there?


You would not mention this directory anywhere in server.xml.


Then go to the context files for those webapps and fully qualify the
docBase (c:\domains\myHost\webapps2\myWebApp1)?


Yes.



I realize this is not the recommended design.  But I need a stopgap
solution until I can change the build process.  So, is this solution
at least an acceptable one in the interim?


Lots of people do this. One of the advantages of doing it this way is 
that Tomcat upgrades are easier. You can just do the following:


1. Install a new Tomcat
2. Add the virtual Host elements into the new server.xml
3. Copy over the old conf\Catalina\[hostname]\appName.xml files
4. Shut down the old Tomcat
5. Start the new Tomcat


If not, what is the best
way for me to keep my misnamed webapps that don't match the context
path for a while and still keep the lights on?

Thanks.

Jerry


/mde/


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

RE: Manager Doesn't Recognize context = /

 From: Mark Eggers [mailto:its_toas...@yahoo.com] 
 Subject: Re: Manager Doesn't Recognize context = /

  In the meantime, I've got lots of webapps from my earlier, currently
  working config that use a context path that is different from the
  appBase folder name.

 You mean docBase (I think).

 docBase - the document base for an individual application
 appBase - where all of a particular Host's applications live

Minor niggle: appBase is the _default_ location for a Host's webapps, not 
where all of the Host's webapps live.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

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

Re: Tomcat 8.0.0-RC5: asynchron IO and back pressure with ReadListener