Re: Allow Customization of service.bat

[Igal @ Lucee.org]

Hi Mark,

On 10/20/2016 1:19 PM, Mark Thomas wrote:



Can I submit a patch for that?

Sure. Got for it.


I'm not very familiar with SVN (hopefully Apache will move to GIT soon), 
so I wasn't sure where to submit the patch.


The Apache Contributors Guide suggests the bug tracking platform. Should 
I create a ticket in Bugzilla and add the patch there?


I also attached the patch file here for convenience.

Thank you,


Igal

Index: bin/service.bat
===
--- bin/service.bat (revision 1765885)
+++ bin/service.bat (working copy)
@@ -142,6 +142,10 @@
 set 
"CLASSPATH=%CATALINA_HOME%\bin\bootstrap.jar;%CATALINA_BASE%\bin\tomcat-juli.jar"
 if not "%CATALINA_HOME%" == "%CATALINA_BASE%" set 
"CLASSPATH=%CLASSPATH%;%CATALINA_HOME%\bin\tomcat-juli.jar"
 
+if "%SERVICE_STARTUP_MODE%" == "" set SERVICE_STARTUP_MODE=manual
+if "%JvmMs%" == "" set JvmMs=128
+if "%JvmMx%" == "" set JvmMx=256
+
 "%EXECUTABLE%" //IS//%SERVICE_NAME% ^
 --Description "Apache Tomcat @VERSION@ Server - http://tomcat.apache.org/; 
^
 --DisplayName "%DISPLAYNAME%" ^
@@ -159,9 +163,11 @@
 --StopClass org.apache.catalina.startup.Bootstrap ^
 --StartParams start ^
 --StopParams stop ^
---JvmOptions 
"-Dcatalina.home=%CATALINA_HOME%;-Dcatalina.base=%CATALINA_BASE%;-Djava.io.tmpdir=%CATALINA_BASE%\temp;-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager;-Djava.util.logging.config.file=%CATALINA_BASE%\conf\logging.properties"
 ^
---JvmMs 128 ^
---JvmMx 256
+--JvmOptions 
"-Dcatalina.home=%CATALINA_HOME%;-Dcatalina.base=%CATALINA_BASE%;-Djava.io.tmpdir=%CATALINA_BASE%\temp;-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager;-Djava.util.logging.config.file=%CATALINA_BASE%\conf\logging.properties;%JvmArgs%"
 ^
+--Startup "%SERVICE_STARTUP_MODE%" ^
+--JvmMs "%JvmMs%" ^
+--JvmMx "%JvmMx%"
+
 if not errorlevel 1 goto installed
 echo Failed installing '%SERVICE_NAME%' service
 goto end

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

Re: Tomcat clustering and FarmDeployer

[Daniel Savard]

2016-10-20 15:16 GMT-04:00 André Warnier (tomcat) :

Maybe naive, and I have never tried any of this myself, but is there a
> reason why you cannot use method 2 in
> http://tomcat.apache.org/tomcat-8.0-doc/deployer-howto.html#
> A_word_on_Contexts
> in that scenario ?
>
>
André,

thanks I will give it a try. I never used method 2 before and I just forgot
about it.

-
Daniel Savard

Re: Allow Customization of service.bat

[Mark Thomas]

On 20/10/2016 21:09, Igal @ Lucee.org wrote:
> service.bat is a great tool to install and remove Tomcat as a Windows
> service, but it has a few hardcoded values that should be
> customize-able, like the heap memory size and JVM args.
> 
> I've modified the script slightly to address these issues.  The first
> part sets default values:
> 
> if "%SERVICE_STARTUP_MODE%" == "" set SERVICE_STARTUP_MODE=manual
> if "%JvmMs%" == "" set JvmMs=128
> if "%JvmMx%" == "" set JvmMx=256
> 
> The second part makes use of those values:
> 
> --Startup "%SERVICE_STARTUP_MODE%" ^
> --JvmOptions
> "%JvmArgs%;-Dcatalina.home=%CATALINA_HOME%;-Dcatalina.base=%CATALINA_BASE%;-Djava.io.tmpdir=%CATALINA_BASE%\temp;-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager;-Djava.util.logging.config.file=%CATALINA_BASE%\conf\logging.properties"
> ^
> --JvmMs "%JvmMs%" ^
> --JvmMx "%JvmMx%"
> 
> It'd be great, however, if these changes were accepted to be part of the
> Tomcat distribution.
> 
> Can I submit a patch for that?

Sure. Got for it.

Thanks,

Mark


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

Allow Customization of service.bat

[Igal @ Lucee.org]

service.bat is a great tool to install and remove Tomcat as a Windows 
service, but it has a few hardcoded values that should be 
customize-able, like the heap memory size and JVM args.


I've modified the script slightly to address these issues.  The first 
part sets default values:


if "%SERVICE_STARTUP_MODE%" == "" set SERVICE_STARTUP_MODE=manual
if "%JvmMs%" == "" set JvmMs=128
if "%JvmMx%" == "" set JvmMx=256

The second part makes use of those values:

--Startup "%SERVICE_STARTUP_MODE%" ^
--JvmOptions 
"%JvmArgs%;-Dcatalina.home=%CATALINA_HOME%;-Dcatalina.base=%CATALINA_BASE%;-Djava.io.tmpdir=%CATALINA_BASE%\temp;-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager;-Djava.util.logging.config.file=%CATALINA_BASE%\conf\logging.properties" 
^

--JvmMs "%JvmMs%" ^
--JvmMx "%JvmMx%"

It'd be great, however, if these changes were accepted to be part of the 
Tomcat distribution.


Can I submit a patch for that?


--

Igal Sapir
Lucee Core Developer
Lucee.org 

Re: Tomcat clustering and FarmDeployer

[tomcat]

On 20.10.2016 20:50, Daniel Savard wrote:

Hi everyone,

I am testing the FarmDeployer in a Tomcat cluster environment and it seems
it cannot do what I would like it to do.

So far, it works fine to deploy the web application on all cluster members.
However, the way they are deployed is the plain war file drop into the
appBase directory. I didn't find any way to make it working with a context
specific to the application configured in the ${ENGINE}/${HOST}/appName.xml
file for example for the appName web application.

Anyone knows if there is a trick to do that? Or is there a reason it is not
possible to associate a context specific to the web application?

BTW, if it is of any use, I am running Tomcat 8.0.36 and Oracle JDK
1.8.0_92.



Maybe naive, and I have never tried any of this myself, but is there a reason why you 
cannot use method 2 in

http://tomcat.apache.org/tomcat-8.0-doc/deployer-howto.html#A_word_on_Contexts
in that scenario ?



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

Tomcat clustering and FarmDeployer

[Daniel Savard]

Hi everyone,

I am testing the FarmDeployer in a Tomcat cluster environment and it seems
it cannot do what I would like it to do.

So far, it works fine to deploy the web application on all cluster members.
However, the way they are deployed is the plain war file drop into the
appBase directory. I didn't find any way to make it working with a context
specific to the application configured in the ${ENGINE}/${HOST}/appName.xml
file for example for the appName web application.

Anyone knows if there is a trick to do that? Or is there a reason it is not
possible to associate a context specific to the web application?

BTW, if it is of any use, I am running Tomcat 8.0.36 and Oracle JDK
1.8.0_92.

Regards,
-
Daniel Savard

Re: Question about ServletOutputStream.setWriteListener

[Mark Thomas]

On 20/10/2016 14:08, Violeta Georgieva wrote:
> Hi,
> 
> I have a question about ServletOutputStream.setWriteListener.
> 
> I have the following scenario:
> - Request 1 - in the servlet service method it starts async operation and
> starts waiting for a particular notification
> - Request 2  - in the servlet service method it starts async operation and
> notifies the Request 1 to write to the response
> - During this notification Request 1 sets WriteListener. This happens while
> we are still in the service method of the servlet for Request 2 i.e. this
> happens in the thread that processes Request 2.
> - Request 1 starts waiting for onWritePossible but the event is never sent.
> 
> So the question is whether it is allowed to set the WriteListener from the
> thread that is processing another request?

Yes, but we don't handle that very well. That looks like a bug to me.

> I can see that when setWriteListener is invoked [1] we add to the
> dispatches - NON_BLOCKING_WRITE - this is a result of the DISPATCH_WRITE
> action.
> But I think that we have to invoke DISPATCH_EXECUTE.
> 
> I tried to extract one very simple example [2] that shows the scenario.

Can you turn that into a unit test for the AsyncContext?

Mark


> 
> What do you think?
> 
> Thanks,
> Violeta
> 
> [1]
> https://github.com/apache/tomcat/blob/trunk/java/org/apache/coyote/Response.java#L607
> [2] https://github.com/violetagg/test-write-listener
> 


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

Re: Apache mod_jk connector question about alias

[tomcat]

On 20.10.2016 18:23, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Marc,

On 10/20/16 11:34 AM, Marc Chamberlin wrote:

On 10/20/2016 3:19 AM, André Warnier (tomcat) wrote:

On 20.10.2016 01:58, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256

Marc,

On 10/18/16 7:59 PM, Marc Chamberlin wrote:

On 10/17/2016 10:36 AM, Rainer Jung wrote:


Alias maps URIs to local file system directories. JkMount
maps URIs to remote back end requests.

You can not change JkMount forwarding using Alias (except
that if you have a comflict between Alias and JkMount only
one of them wins).

As far as I understand you are not really trying to map
requests to the local web server file system, but instead
want to forward to a Tomcat back end but change the URI
path which is used when accessing Apache to something else
being used to acces Tomcat. E.g. the URI
/jsp-examples/something gets used when accessing Apache and
mod_jk should send this request as /examples/jsp/something
to the Tomcat back end.

If you really need to change URIs, then often mod_proxy is
much easier to set up, because it has specific directives
for this (ProxyPass etc.).

With mod_jk you would first need to use mod_rewrite
RewriteRules to change the URI, and then JkMount to forward
them. More details can be found at

http://tomcat.apache.org/connectors-doc/common_howto/proxy.html#UR

L%2





0Rewriting






The rest of this docs page might be useful as well.


Regards,

Rainer


Thanks a million Rainer, you got me over that hump! I have
it working now but have another question - When the response
is generated for a request, that used the alias in the URL,
is there a way to keep the client browser from displaying
what the alias got mapped to?

So for example, if I use the alias in the URL -
http://www.mydomain.com/jsp-examples  that I send to the
Apache server, and it in turn forwards that request to Tomcat
as http://www.mydomain.com/examples/jsp, I would prefer that
the response, sent back to the user, contains the original,
aliased or unaliased, version of the URL that he/she typed,
and not just the resolved version. As it stands I am always
getting the response URL of
http://www.mydomain.com/examples/jsp displayed in the client
browser.

What follows is my current version of the config file that I
am using for the jsp-examples. Seems to be working mostly OK,
so hopefully I am on the right track. FYI - I intend to
include these config files in various virtual hosts
configurations each of which have their own document root,
hence the reason for the Alias commands at the beginning of
this config file.

Thanks again in advance for any and all offers of help,
thoughts, and replies...


Your best bet is to name the context in Tomcat to be whatever
you really want the URL path to be. This will remove all kinds
of problems you are likely to see in the future because of your
decision to try to rewrite URLs.

I never understand why people would rather spend a great deal
of time configuring around the fact that this simple command
will get everything working without any other issues:

$ mv webapps/name-you-have webapps/name-you-want


+10 Because once you start playing with Aliases and RewriteRules,
you are setting yourself up for a lot of future additional
complications in terms of Redirects, Authentication, etc.. most
of which you cannot even imagine right now.


Thanks Christopher, Andre for your comments and I will certainly
take them under consideration. If I were working in a simple
environment where all I had to do was to focus on Tomcat and Apache
I would certainly agree with you. Your simplistic solution of
renaming directories would indeed be the correct choice.

The problem is, is that the real world is not quite so
accommodating. I am trying to support a team of users who are using
other third party applications and also using cross-sectional tools
that require multiple resources/directories in the Tomcat/Apache
web directories, that all need to be coordinated. Some of this can
be solved with directory renaming or links, but in some cases it
becomes a question of whether the dog is wagging the tail or the
tail is wagging the dog in terms of the amount of work involved to
solve a problem; such as a simple Tomcat/Apache alone related
answer (directory renaming) implies. So I am exploring the choices
I have within the Tomcat/Apache tool space in order to determine
what choice is best. If indeed the tools available within Tomcat
and Apache are so odious to use, then yes I will also have to
explore the option of changing other tools, software, and
configurations in order to accommodate Tomcat and Apache.


It's not a question of whether of not the tools are odious, it's the
fact that a highly-complicated environment is going to require
highly-complicated configuration. I'm suggesting that you simplify
things. You will quickly find that you will need to start re-writing
entire pages of content to 

Re: Tomcat 8, AJP 1.3 UTF-8/ISO-8859-1 conversion problem

[tomcat]

On 20.10.2016 15:55, Mark Juszczec wrote:

On Thu, Oct 20, 2016 at 4:21 AM, André Warnier (tomcat) 
wrote:



Can you tell us (or remind us) exactly how the browser is sending this
request for the parameter "JOEL" (with dieraesis on the E) to the server ?
Is it a part of the query-string of the URL, or is it in the body of a
POST request ?

The following on-line documentation describes precisely how this should
work :
http://tomcat.apache.org/tomcat-8.0-doc/config/ajp.html#Attributes
(See "URIEncoding", but also "useBodyEncodingForURI", and follow the link
provided to the same attributes in the HTTP Connector :
http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#Common_Attributes
)

So check exactly what you are doing, and if that matches these rules
somehow.

Personal rant :
Unfortunately, this is is still a big mess in the HTTP protocol.
And the people in charge of the design of the protocol missed a golden
opportunity of cleaning this up in HTTP 2.x and making Unicode/UTF-8 the
default, instead of clinging to iso-8859-1. Thus condemning all web
programmers worldwide to another 20 years of obscure bugs and clunky
work-arounds.

(s) Andr%C3%A9



The data is being returned by Shibboleth and passed to Tomcat in the body
of an HTTP GET request.


Nitpick : that is a contradiction in terms. A GET request, per RFC, has no 
"body".
See : https://tools.ietf.org/html/rfc7231#section-4  4.3.1 GET

I don't know Shibboleth, and I do not know how it works exactly, but based on what you 
seem to imply here, I will assume that the "joel" in question is being passed as part of 
the GET request URL (like "..?givenName=joel=xxx..").

(Technically, that part is the "query-string" part of the URI).

Based on what else you indicate below about Shibbolet, I would also assume that the "e 
with dieresis" (sorry, can't type it on my German keyboard), is passed in that 
query-string, as iso-8859-1, perhaps percent-encoded as %CB or %EB.


Receiving this, recent Tomcats would decode this either as iso-8859-1 (latin-1) (if 
STRICT_SERVLET_COMPLIANCE is enforced), or as UTF-8 (by default), or according to what you 
set as "URIEncoding" and/or "useBodyEncodingForURI".
If it tries UTF-8, that may or may not generate a valid Java Unicode character, but it 
would in any case not be the character that you expect.
If you set it to decode the URIs using iso-8859-1, then it would decode this correctly 
(and generate the correct java Unicode character in your application), but it would decode 
*all* further request URIs using iso-8859-1, which would most probably have adverse 
effects on the rest of your application.


So it would seem that you are stuck somewhere in-between.
But it is not a Tomcat issue, it is a Shibbolet issue.
(Or rather, a Shibbolet-and-HTTP-defaulting-to-iso-8859-1 issue).



This is by design of the application and there's nothing I can do about it.



Neither can we.


As such, my only options for enforcing UTF-8 are by using "URIEncoding"
and/or "useBodyEncodingForURI" as described in the links.

I've done this and it has not had any impact on the problem.

Last night, I found these bits of information:

https://issues.shibboleth.net/jira/browse/SSPCPP-2

My interpretation (and PLEASE tell me if I'm wrong) is, since at least
2007, headers have been locked in to the ISO-8859-1 charset due to specs
that govern how the world wide web is going to work.



Well yes, see my previous rant.
See : https://tools.ietf.org/html/rfc7230#section-3.2
3.2.4.  Field Parsing (at the end)


This:

https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAttributeAccess


I am sorry, but I do not really have the time right now (nor the setup) to investigate 
further into what Shibbolet is doing, or what they are really explaining in that article.
But while reading this "in diagonal", I have a suspicion that maybe the following may help 
you, in the case of a mod_jk Connector to Tomcat :


http://tomcat.apache.org/connectors-doc/reference/apache.html

JkEnvVar

"Adds a name and an optional default value of environment variable that should be sent to 
servlet-engine as a request attribute. If the default value is not given explicitly, the 
variable will only be send, if it is set during runtime.

The default is empty, so no additional variables will be sent.
This directive can be used multiple times per virtual server. The settings will be merged 
between the global server and any virtual server.
You can retrieve the variables on Tomcat as request attributes via 
request.getAttribute(attributeName). Note that the variables send via JkEnvVar will not be 
listed in request.getAttributeNames().
Empty default values are supported since version 1.2.20. Not sending variables with empty 
defaults and empty runtime value has been introduced in version 1.2.21. "


In other words : if Shibbolet can send this value in the form of a HTTP header, and you 
can configure the Apache httpd front-end to pick up the 

Re: java.lang.OutOfMemoryError: PermGen space

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jon,

On 10/20/16 6:00 AM, Moore, Jon, Vodafone UK wrote:
> I have a problem where our customers application server stops
> working intermittently and when we check the Tomcat logs we get the
> message " java.lang.OutOfMemoryError: PermGen space" but the Tomcat
> service is still running, and we have to restart the Tomcat
> service. I am a complete novice when it comes to Tomcat but am
> expected to resolve this issue as this server is part of the Avaya
> telephony solution.
> 
> I have 2 questions please.
> 
> 1 - What would be causing this.

Are you also a Java novice as well? No judgement... I just want to
adjust my level of snark appropriately :)

Java has a special heap space called the "permanent generation" (a
term which becomes less descriptive as time goes on) but basically all
java.lang.Class objects loaded by the JVM go there. The more libraries
and other stuff that gets loaded, the more space in permgen is used.
The defaults for the size of permgen are often fairly small, and you
may have to raise them. This is especially true for applications that
use large frameworks like Spring.

Raising the permgen space is almost always the right decision under
normal circumstances when you get an OOME:permgen error. I would
double whatever its current value is and monitor the application for a
while to see if that improves things.

The only situation I know of where raising the permgen size is not the
right move is when there is a "classloader-pinning leak". That happens
when you hot-deploy an application many times, but the old versions of
the application are not undeploying cleanly. This situation is quite
the rabbit-hole, so I'll stop there unless you can confirm that you do
hot-deployments without restarting Tomcat and the JVM.

If you instead get OOME for other reasons, it's frequently NOT the
right decision to increase the heap size because it usually indicates
that there is a memory leak in the application and giving it more heap
just means you'll wait longer between failures. Instead, the
application should be fixed to not leak memory :)

> 2 - What are the default Java memory settings for Initial memory 
> pool, maximum memory pool size and thread stack size when the
> fields are blank when you use the "Configure Tomcat" interface on
> Windows. I was wondering if changing one or more of these settings
> would help ?

The default depends upon the JVM and the OS.

> We are running Tomcat 6.0.26 on Windows Server 2008 R2 standard
> and JVM version is 1.6.0_20-b02

Best way to find out for sure[1] is:

C:\> java -XX:+PrintFlagsFinal -version 2>&1 | findstr HeapSize

The two settings you are looking for are MaxHeapSize and
InitialHeapSize. Those values are in bytes, so you'll probably have to
divide by 1024 a couple of times to get at the "real" value in
human-readable terms.

The best way to find the default permgen size is:

C:\> java -XX:+PrintFlagsFinal -version 2>&1  | findstr PermSize

Hope that helps,
- -chris

[1]
http://stackoverflow.com/questions/2915276/what-is-the-default-maximum-h
eap-size-for-suns-jvm-from-java-se-6
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYCPN3AAoJEBzwKT+lPKRYCXEQAK3AKioa7kRPTvs24yj+1vq6
SFo20WtjFhBrqyhSRdcvcwUjoDAIS6d6wqjDQ13v919jFRTsqCrDh9FQg1MeCWVB
UJVmcV33XjTQUmqEY03YUPwOVjgQe6RJM+FJAE60werkHEEirg85gL/WamQ+QtfW
C39sp2NO6kHpD7VWnBKPhToNmcy7lz2EK6Ye8aEXkn2mk2PZhJFRysgTqeJ/CChA
KnUzWAqrDBM3OtHerivHuIEHhJB7+43bD9kiX7JZXDlcVkubAz6bep3m2sXO3T9O
VYZs0ACKvnzuc6kqkStMcsGUeLWvYc5+xhCDNcxGhYXjrIWOaW5aS9QipZmAXze7
IoY2UC4vxyajRNuFmLeUWaeICDtYZaf/5d3wrlsbCIWF/vf2C+NpuynEidq6N6Yv
pFvTqRd+ZsNEbsKaQwaHSHsfQVxtQbPlFfUlYWvu7vz+Y5xCyTSFoct2UqDcBedi
Bo+vdHVoih/i9+4Zhg+Bieh5lygcoE9VS0KX2yu+4kwaaSohFoxwHcHXoD1SjXTU
FDq2H+GXV/3bS/hAek+5WzQuPJC5etsqcMUfIcf8YjrDmR6BabEvQFk5p9APYV+x
7lcODhWFlF3tEOvKiIRmPuQz/d4/hR5ETo6h12g2UMsfY9ogEZF7I8SP1uNK3bpO
cH97Lssd2MS5qj/Kd/m5
=JBc2
-END PGP SIGNATURE-

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

Re: Apache mod_jk connector question about alias

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Marc,

On 10/20/16 11:34 AM, Marc Chamberlin wrote:
> On 10/20/2016 3:19 AM, André Warnier (tomcat) wrote:
>> On 20.10.2016 01:58, Christopher Schultz wrote:
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>> 
>>> Marc,
>>> 
>>> On 10/18/16 7:59 PM, Marc Chamberlin wrote:
 On 10/17/2016 10:36 AM, Rainer Jung wrote:
> 
> Alias maps URIs to local file system directories. JkMount
> maps URIs to remote back end requests.
> 
> You can not change JkMount forwarding using Alias (except
> that if you have a comflict between Alias and JkMount only
> one of them wins).
> 
> As far as I understand you are not really trying to map
> requests to the local web server file system, but instead
> want to forward to a Tomcat back end but change the URI
> path which is used when accessing Apache to something else
> being used to acces Tomcat. E.g. the URI
> /jsp-examples/something gets used when accessing Apache and
> mod_jk should send this request as /examples/jsp/something
> to the Tomcat back end.
> 
> If you really need to change URIs, then often mod_proxy is
> much easier to set up, because it has specific directives
> for this (ProxyPass etc.).
> 
> With mod_jk you would first need to use mod_rewrite
> RewriteRules to change the URI, and then JkMount to forward
> them. More details can be found at
> 
> http://tomcat.apache.org/connectors-doc/common_howto/proxy.html#UR
L%2
>>>
> 
0Rewriting
> 
> 
> 
> 
>>> The rest of this docs page might be useful as well.
> 
> Regards,
> 
> Rainer
> 
 Thanks a million Rainer, you got me over that hump! I have
 it working now but have another question - When the response
 is generated for a request, that used the alias in the URL,
 is there a way to keep the client browser from displaying
 what the alias got mapped to?
 
 So for example, if I use the alias in the URL - 
 http://www.mydomain.com/jsp-examples  that I send to the
 Apache server, and it in turn forwards that request to Tomcat
 as http://www.mydomain.com/examples/jsp, I would prefer that
 the response, sent back to the user, contains the original,
 aliased or unaliased, version of the URL that he/she typed,
 and not just the resolved version. As it stands I am always
 getting the response URL of
 http://www.mydomain.com/examples/jsp displayed in the client 
 browser.
 
 What follows is my current version of the config file that I
 am using for the jsp-examples. Seems to be working mostly OK,
 so hopefully I am on the right track. FYI - I intend to
 include these config files in various virtual hosts
 configurations each of which have their own document root,
 hence the reason for the Alias commands at the beginning of
 this config file.
 
 Thanks again in advance for any and all offers of help,
 thoughts, and replies...
>>> 
>>> Your best bet is to name the context in Tomcat to be whatever
>>> you really want the URL path to be. This will remove all kinds
>>> of problems you are likely to see in the future because of your
>>> decision to try to rewrite URLs.
>>> 
>>> I never understand why people would rather spend a great deal
>>> of time configuring around the fact that this simple command
>>> will get everything working without any other issues:
>>> 
>>> $ mv webapps/name-you-have webapps/name-you-want
>>> 
>> +10 Because once you start playing with Aliases and RewriteRules,
>> you are setting yourself up for a lot of future additional
>> complications in terms of Redirects, Authentication, etc.. most
>> of which you cannot even imagine right now.
>> 
> Thanks Christopher, Andre for your comments and I will certainly
> take them under consideration. If I were working in a simple
> environment where all I had to do was to focus on Tomcat and Apache
> I would certainly agree with you. Your simplistic solution of
> renaming directories would indeed be the correct choice.
> 
> The problem is, is that the real world is not quite so
> accommodating. I am trying to support a team of users who are using
> other third party applications and also using cross-sectional tools
> that require multiple resources/directories in the Tomcat/Apache
> web directories, that all need to be coordinated. Some of this can
> be solved with directory renaming or links, but in some cases it
> becomes a question of whether the dog is wagging the tail or the
> tail is wagging the dog in terms of the amount of work involved to
> solve a problem; such as a simple Tomcat/Apache alone related
> answer (directory renaming) implies. So I am exploring the choices
> I have within the Tomcat/Apache tool space in order to determine
> what choice is best. If indeed the tools available within Tomcat
> and Apache are so odious to use, then yes I will also 

Re: Apache mod_jk connector question about alias

[Marc Chamberlin]

On 10/20/2016 3:19 AM, André Warnier (tomcat) wrote:

On 20.10.2016 01:58, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Marc,

On 10/18/16 7:59 PM, Marc Chamberlin wrote:

On 10/17/2016 10:36 AM, Rainer Jung wrote:


Alias maps URIs to local file system directories. JkMount maps
URIs to remote back end requests.

You can not change JkMount forwarding using Alias (except that if
you have a comflict between Alias and JkMount only one of them
wins).

As far as I understand you are not really trying to map requests
to the local web server file system, but instead want to forward
to a Tomcat back end but change the URI path which is used when
accessing Apache to something else being used to acces Tomcat.
E.g. the URI /jsp-examples/something gets used when accessing
Apache and mod_jk should send this request as
/examples/jsp/something to the Tomcat back end.

If you really need to change URIs, then often mod_proxy is much
easier to set up, because it has specific directives for this
(ProxyPass etc.).

With mod_jk you would first need to use mod_rewrite RewriteRules
to change the URI, and then JkMount to forward them. More details
can be found at

http://tomcat.apache.org/connectors-doc/common_howto/proxy.html#URL%2

0Rewriting






The rest of this docs page might be useful as well.


Regards,

Rainer


Thanks a million Rainer, you got me over that hump! I have it
working now but have another question - When the response is
generated for a request, that used the alias in the URL, is there a
way to keep the client browser from displaying what the alias got
mapped to?

So for example, if I use the alias in the URL -
http://www.mydomain.com/jsp-examples  that I send to the Apache
server, and it in turn forwards that request to Tomcat as
http://www.mydomain.com/examples/jsp, I would prefer that the
response, sent back to the user, contains the original, aliased or
unaliased, version of the URL that he/she typed, and not just the
resolved version. As it stands I am always getting the response URL
of http://www.mydomain.com/examples/jsp displayed in the client
browser.

What follows is my current version of the config file that I am
using for the jsp-examples. Seems to be working mostly OK, so
hopefully I am on the right track. FYI - I intend to include these
config files in various virtual hosts configurations each of which
have their own document root, hence the reason for the Alias
commands at the beginning of this config file.

Thanks again in advance for any and all offers of help, thoughts,
and replies...


Your best bet is to name the context in Tomcat to be whatever you
really want the URL path to be. This will remove all kinds of problems
you are likely to see in the future because of your decision to try to
rewrite URLs.

I never understand why people would rather spend a great deal of time
configuring around the fact that this simple command will get
everything working without any other issues:

$ mv webapps/name-you-have webapps/name-you-want


+10
Because once you start playing with Aliases and RewriteRules, you are 
setting yourself up for a lot of future additional complications in 
terms of Redirects, Authentication, etc..

most of which you cannot even imagine right now.

Thanks Christopher, Andre for your comments and I will certainly take 
them under consideration. If I were working in a simple environment 
where all I had to do was to focus on Tomcat and Apache I would 
certainly agree with you. Your simplistic solution of renaming 
directories would indeed be the correct choice.


The problem is, is that the real world is not quite so accommodating. I 
am trying to support a team of users who are using other third party 
applications and also using cross-sectional tools that require multiple 
resources/directories in the Tomcat/Apache web directories, that all 
need to be coordinated. Some of this can be solved with directory 
renaming or links, but in some cases it becomes a question of whether 
the dog is wagging the tail or the tail is wagging the dog in terms of 
the amount of work involved to solve a problem; such as a simple 
Tomcat/Apache alone related answer (directory renaming) implies. So I am 
exploring the choices I have within the Tomcat/Apache tool space in 
order to determine what choice is best. If indeed the tools available 
within Tomcat and Apache are so odious to use, then yes I will also have 
to explore the option of changing other tools, software, and 
configurations in order to accommodate Tomcat and Apache.


My understanding of Tomcat and Apache is that they are supposedly robust 
enterprise grade tools, designed to work in complex environments. So my 
hope is that issues like this have been already addressed with elegant 
solutions. ;-) FYI I am using the jsp and servlet examples here as just 
a simple model of what I want to accomplish. I could really care less 
about those particular web applications.


 Marc...

Re: Tomcat 8, AJP 1.3 UTF-8/ISO-8859-1 conversion problem

[Mark Juszczec]

On Thu, Oct 20, 2016 at 4:21 AM, André Warnier (tomcat) 
wrote:

>
> Can you tell us (or remind us) exactly how the browser is sending this
> request for the parameter "JOEL" (with dieraesis on the E) to the server ?
> Is it a part of the query-string of the URL, or is it in the body of a
> POST request ?
>
> The following on-line documentation describes precisely how this should
> work :
> http://tomcat.apache.org/tomcat-8.0-doc/config/ajp.html#Attributes
> (See "URIEncoding", but also "useBodyEncodingForURI", and follow the link
> provided to the same attributes in the HTTP Connector :
> http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#Common_Attributes
> )
>
> So check exactly what you are doing, and if that matches these rules
> somehow.
>
> Personal rant :
> Unfortunately, this is is still a big mess in the HTTP protocol.
> And the people in charge of the design of the protocol missed a golden
> opportunity of cleaning this up in HTTP 2.x and making Unicode/UTF-8 the
> default, instead of clinging to iso-8859-1. Thus condemning all web
> programmers worldwide to another 20 years of obscure bugs and clunky
> work-arounds.
>
> (s) Andr%C3%A9
>
>
The data is being returned by Shibboleth and passed to Tomcat in the body
of an HTTP GET request.

This is by design of the application and there's nothing I can do about it.

As such, my only options for enforcing UTF-8 are by using "URIEncoding"
and/or "useBodyEncodingForURI" as described in the links.

I've done this and it has not had any impact on the problem.

Last night, I found these bits of information:

https://issues.shibboleth.net/jira/browse/SSPCPP-2

My interpretation (and PLEASE tell me if I'm wrong) is, since at least
2007, headers have been locked in to the ISO-8859-1 charset due to specs
that govern how the world wide web is going to work.

This:

https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAttributeAccess

goes on to reiterate what the first link says and propose a workaround (see
the Java link at the end of the page)

"Shibboleth attributes are by default UTF-8 encoded. However, depending on
the servlet contaner configuration they are interpreted as ISO-8859-1
values. This causes problems with non-ASCII characters. The solution is to
re-encode attributes, e.g. with:

String value= request.getHeader("givenName");
value= new String( value.getBytes("ISO-8859-1"), "UTF-8");"


Although MY data is delivered as attributes (so I have to use
request.getAttribute("FirstName") )  this works

ISO-8859-1 is the default used by ByteChunk and I've verified it is not
reset/changed to UTF-8 despite having specified it in server.xml per Tomcat
documentation.

I found this:

https://issues.shibboleth.net/jira/browse/SSPCPP-2

which says this problem has been around since at least 2007

Then I found this:

https://wiki.shibboleth.net/confluence/plugins/servlet/mobil
e#content/view/4358180

which suggests the following solution:

String value= request.getHeader("givenName");
value= new String( value.getBytes("ISO-8859-1"), "UTF-8");

I have to get my data via request.getAttribute("key")

Is the solution appropriate for data delivered as attributes?
I have read the information that says its a dangerous hack and is the main
reason I have not implemented it.

However, given the Shibboleth forum posts and what I've discovered about
ByteChunk seems to cast this in a different light.

Any thoughts, comments would be greatly appreciated.

Question about ServletOutputStream.setWriteListener

[Violeta Georgieva]

Hi,

I have a question about ServletOutputStream.setWriteListener.

I have the following scenario:
- Request 1 - in the servlet service method it starts async operation and
starts waiting for a particular notification
- Request 2  - in the servlet service method it starts async operation and
notifies the Request 1 to write to the response
- During this notification Request 1 sets WriteListener. This happens while
we are still in the service method of the servlet for Request 2 i.e. this
happens in the thread that processes Request 2.
- Request 1 starts waiting for onWritePossible but the event is never sent.

So the question is whether it is allowed to set the WriteListener from the
thread that is processing another request?

I can see that when setWriteListener is invoked [1] we add to the
dispatches - NON_BLOCKING_WRITE - this is a result of the DISPATCH_WRITE
action.
But I think that we have to invoke DISPATCH_EXECUTE.

I tried to extract one very simple example [2] that shows the scenario.

What do you think?

Thanks,
Violeta

[1]
https://github.com/apache/tomcat/blob/trunk/java/org/apache/coyote/Response.java#L607
[2] https://github.com/violetagg/test-write-listener

Re: java.lang.OutOfMemoryError: PermGen space

[tomcat]

On 20.10.2016 12:00, Moore, Jon, Vodafone UK wrote:

I have a problem where our customers application server stops working intermittently and 
when we check the Tomcat logs we get the message " java.lang.OutOfMemoryError: 
PermGen space" but the Tomcat service is still running, and we have to restart the 
Tomcat service. I am a complete novice when it comes to Tomcat but am expected to resolve 
this issue as this server is part of the Avaya telephony solution.

I have 2 questions please.

1 - What would be causing this.

2 - What are the default Java memory settings for Initial memory pool, maximum memory 
pool size and thread stack size when the fields are blank when you use the 
"Configure Tomcat" interface on Windows. I was wondering if changing one or 
more of these settings would help ?

We are running Tomcat 6.0.26 on Windows Server 2008 R2 standard and JVM version 
is 1.6.0_20-b02



Not a real answer to your question, but one important aspect as a start : these "default 
settings" are the settings of the JVM, not of Tomcat. There are no parameters in Tomcat 
itself which control those; Tomcat just "lives" in the JVM that runs it.


At a second level : these default settings (and the non-default ones), vary according to 
the JVM which you are using, its version, the host it is running on etc.
So you need to look up the values and parameters in the configuration documentation of the 
JVM vendor (e.g. Oracle, IBM, ..), not on the Tomcat site.


As for your question # 1 :
this would be a good start : http://lmgtfy.com/?q=java+permgen+space

Another answer would be : your application
(Note: I'm not kidding; it really depends on your applications.  Tomcat itself runs 
happily with the default JVM settings)






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

Re: java.lang.OutOfMemoryError: PermGen space

[Román Valoria]

1. Bad memory settings or a java class having a memory leak.

2. The place to setup the values will depend if you run Tomcat as a Windows
Service, from the tomcat7.exe or from the startup.bat.

BTW, those are super outdated releases of OS, Java and Tomcat.

On Thu, Oct 20, 2016 at 6:00 PM, Moore, Jon, Vodafone UK <
jon.mo...@vodafone.com> wrote:

> I have a problem where our customers application server stops working
> intermittently and when we check the Tomcat logs we get the message "
> java.lang.OutOfMemoryError: PermGen space" but the Tomcat service is still
> running, and we have to restart the Tomcat service. I am a complete novice
> when it comes to Tomcat but am expected to resolve this issue as this
> server is part of the Avaya telephony solution.
>
> I have 2 questions please.
>
> 1 - What would be causing this.
>
> 2 - What are the default Java memory settings for Initial memory pool,
> maximum memory pool size and thread stack size when the fields are blank
> when you use the "Configure Tomcat" interface on Windows. I was wondering
> if changing one or more of these settings would help ?
>
> We are running Tomcat 6.0.26 on Windows Server 2008 R2 standard and JVM
> version is 1.6.0_20-b02
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Apache mod_jk connector question about alias

[tomcat]

On 20.10.2016 01:58, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Marc,

On 10/18/16 7:59 PM, Marc Chamberlin wrote:

On 10/17/2016 10:36 AM, Rainer Jung wrote:


Alias maps URIs to local file system directories. JkMount maps
URIs to remote back end requests.

You can not change JkMount forwarding using Alias (except that if
you have a comflict between Alias and JkMount only one of them
wins).

As far as I understand you are not really trying to map requests
to the local web server file system, but instead want to forward
to a Tomcat back end but change the URI path which is used when
accessing Apache to something else being used to acces Tomcat.
E.g. the URI /jsp-examples/something gets used when accessing
Apache and mod_jk should send this request as
/examples/jsp/something to the Tomcat back end.

If you really need to change URIs, then often mod_proxy is much
easier to set up, because it has specific directives for this
(ProxyPass etc.).

With mod_jk you would first need to use mod_rewrite RewriteRules
to change the URI, and then JkMount to forward them. More details
can be found at

http://tomcat.apache.org/connectors-doc/common_howto/proxy.html#URL%2

0Rewriting






The rest of this docs page might be useful as well.


Regards,

Rainer


Thanks a million Rainer, you got me over that hump! I have it
working now but have another question - When the response is
generated for a request, that used the alias in the URL, is there a
way to keep the client browser from displaying what the alias got
mapped to?

So for example, if I use the alias in the URL -
http://www.mydomain.com/jsp-examples  that I send to the Apache
server, and it in turn forwards that request to Tomcat as
http://www.mydomain.com/examples/jsp, I would prefer that the
response, sent back to the user, contains the original, aliased or
unaliased, version of the URL that he/she typed, and not just the
resolved version. As it stands I am always getting the response URL
of http://www.mydomain.com/examples/jsp displayed in the client
browser.

What follows is my current version of the config file that I am
using for the jsp-examples. Seems to be working mostly OK, so
hopefully I am on the right track. FYI - I intend to include these
config files in various virtual hosts configurations each of which
have their own document root, hence the reason for the Alias
commands at the beginning of this config file.

Thanks again in advance for any and all offers of help, thoughts,
and replies...


Your best bet is to name the context in Tomcat to be whatever you
really want the URL path to be. This will remove all kinds of problems
you are likely to see in the future because of your decision to try to
rewrite URLs.

I never understand why people would rather spend a great deal of time
configuring around the fact that this simple command will get
everything working without any other issues:

$ mv webapps/name-you-have webapps/name-you-want


+10
Because once you start playing with Aliases and RewriteRules, you are setting yourself up 
for a lot of future additional complications in terms of Redirects, Authentication, etc..

most of which you cannot even imagine right now.



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

java.lang.OutOfMemoryError: PermGen space

[Moore, Jon, Vodafone UK]

I have a problem where our customers application server stops working 
intermittently and when we check the Tomcat logs we get the message " 
java.lang.OutOfMemoryError: PermGen space" but the Tomcat service is still 
running, and we have to restart the Tomcat service. I am a complete novice when 
it comes to Tomcat but am expected to resolve this issue as this server is part 
of the Avaya telephony solution.

I have 2 questions please.

1 - What would be causing this.

2 - What are the default Java memory settings for Initial memory pool, maximum 
memory pool size and thread stack size when the fields are blank when you use 
the "Configure Tomcat" interface on Windows. I was wondering if changing one or 
more of these settings would help ?

We are running Tomcat 6.0.26 on Windows Server 2008 R2 standard and JVM version 
is 1.6.0_20-b02

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

Re: Tomcat 8, AJP 1.3 UTF-8/ISO-8859-1 conversion problem

[tomcat]

On 19.10.2016 20:42, Mark Juszczec wrote:

On Tue, Oct 18, 2016 at 4:45 PM, Mark Juszczec 
wrote:




On Tue, Oct 18, 2016 at 2:58 PM, Mark Juszczec 
wrote:



Some questions (if these are not relevant, please disregard):

I'm loading a whole bunch of modules.  Could some of them be incompatible?

DocumentRoot refers to a directory that does not exist.  Is that a
problem?

What does AddLanguage do?

Is AddDefaultCharset redundant?

Are +ForwardKeySize and -ForwardDirectories somehow disabling what
+ForwardURIEscaped does?

I have verified the data coming out of Shibboleth is what we expect.



I think I've found where the byte data is coming in.

AjpAprProcessor.java's method:

protected boolean read(byte[] buf, int pos, int n, boolean block) throws
IOException

This ultimately gives me a great big buffer of bytes. Spring Tool Suite
shows me the relevant ones:

74 79 -61 -117 76



I think I have found where these bytes are interpreted improperly and my
problems start.

In AbstractAjpProcessor.java there is a method named  protected void
prepareRequest()

 // Decode extra attributes
 boolean secret = false;
 byte attributeCode;
 while ((attributeCode = requestHeaderMessage.getByte())
 != Constants.SC_A_ARE_DONE) {

 switch (attributeCode) {

 case Constants.SC_A_REQ_ATTRIBUTE :
 requestHeaderMessage.getBytes(tmpMB);
 String n = tmpMB.toString();
 requestHeaderMessage.getBytes(tmpMB);
 String v = tmpMB.toString();

I have debugged and gotten to the point where n="FirstName" - the bit of
data giving me fits

After  requestHeaderMessage.getBytes(tmpMB); (the one after String n =
) tmpMB shows "JOËL"

tmpMB is a MessageByte.  It contains a ByteChunk.which is the array of
bytes I posted yesterday.

The ByteChunk has a start=1049 and an end=1054.  That is bytes

1049: 5
1050: 74J
1051: 79O
1052: -610xFC3
1053: -117  0xF8B
1054: 76   L

The ByteChunk has a charset and it is set to ISO-8859-1

So, that explains - at least to me - where things go wrong.

Now, the question is why.

Looking at ByteChunk.java, I see it has the following:

 /** Default encoding used to convert to strings. It should be UTF8,
 as most standards seem to converge, but the servlet API requires
 8859_1, and this object is used mostly for servlets.
 */
 public static final Charset DEFAULT_CHARSET =
StandardCharsets.ISO_8859_1;

 private Charset charset;

 public void setCharset(Charset charset) {
 this.charset = charset;
 }

 public Charset getCharset() {
 if (charset == null) {
 charset = DEFAULT_CHARSET;
 }
 return charset;
 }

I set a breakpoint on ByteChunk.setCharset(Charset) and it is never
executed.

ByteChunk.getCharset() is called from MessageBytes.toBytes() which is
called from AjpMessage.appendBytes(MessageBytes)

So, I think this explains why my data is being interpreted incorrectly.

Now, the question becomes why isn't this line in server.xml:

  

enough to cause ByteChunk.charset to be set to "UTF-8"

Does anyone have any thoughts as to how to proceed?



Can you tell us (or remind us) exactly how the browser is sending this request for the 
parameter "JOEL" (with dieraesis on the E) to the server ?

Is it a part of the query-string of the URL, or is it in the body of a POST 
request ?

The following on-line documentation describes precisely how this should work :
http://tomcat.apache.org/tomcat-8.0-doc/config/ajp.html#Attributes
(See "URIEncoding", but also "useBodyEncodingForURI", and follow the link provided to the 
same attributes in the HTTP Connector : 
http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#Common_Attributes)


So check exactly what you are doing, and if that matches these rules somehow.

Personal rant :
Unfortunately, this is is still a big mess in the HTTP protocol.
And the people in charge of the design of the protocol missed a golden opportunity of 
cleaning this up in HTTP 2.x and making Unicode/UTF-8 the default, instead of clinging to 
iso-8859-1. Thus condemning all web programmers worldwide to another 20 years of obscure 
bugs and clunky work-arounds.


(s) Andr%C3%A9




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