Re: Direct url access to protected page: /docs*
Chris, thank you for your reply. Are you saying that you normally rename the catalina folder to catalina_base and then create empty catalina_home folder. So, when i unc to server:8080, do i go to the catalina\webapps folder? Thanks, again. On May 27, 2016 12:47 PM, "Christopher Schultz" < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Robert, > > On 5/27/16 1:16 PM, Robert Youngblood wrote: > > I was recently cited for these pages not being locked down. Is > > there a way to remove or lockdown the default pages? > > What default pages? Do you mean the "docs" web application? > > $ rm -rf webapps/docs > > You might want to remove the other stock applications as well... you > should only be deploying those on a test/dev server. > > I always recommend a split CATALINA_HOME/CATALINA_BASE where > CATALINA_HOME has a stock Tomcat deployment (including all of the > optional web applications in CATALINA_HOME/webapps) and then only my > own web applications in CATALINA_BASE/webapps. > > That way, you don't have to remember to remove the sample applications. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJXSIfyAAoJEBzwKT+lPKRYjoIQAKVOs1VgP9zLXtog763TfVjq > 4Wgy/oVpkWkqh/JfTFX9UyN1c5er0VZ9bTD+T8qyD74OY22hIh88Fm63CgMzTKUa > ffesrlz6u8jtW2Xn9JEgkVqV4dVHwh7oibuJSp172Z9PhTCS+EYkpp2krXe+7Otx > pKwBL1eCEB1dRDJdzwfQOHAuJRGqEzoKPvbs5Zh6xiNamcW0gygP1rBJTAj9T1aR > CSbcG1979mOJ/j2JdKh1LF7nvyDdyHa9IcjOvvLlFnUQKNESG1MIxuHlMuO9VfCu > /6u9fpCHuN+CXvEgNmeNtzzr8+mn/eP7K+J+hy3ahD3KMzt2WwzT/RGqh759s26S > rvr8W3d5fESD9SHrzjGe5iLPWWZlc8MiZU2vsUkyGNJqbDaOB+KB5qkhYTpnhcU7 > A1hmFQDxghEwNpHluEjT9Ob9iR4FsFkimohcUcg0SfDmtRCMo9Yl068kPj44tFnF > M8En57BF30EkZl9Gg5smALu+EycfYanSnjiU4rZLMLUwaR+YOBMHejY+9MooBrvm > xf1zK7V+1WMnfg8fVxGTXeqC5fN+7UKLr+8XID05ATyAKJSSGciz3B8gWbzfGuzY > rkB+0s8akFFnMgXVHIIVdZyLFel0+ebFIeyZov6a37Tv3h9jEtcJEeqDtL4NmBa+ > Ja0S62rO+Ssm/kBp3h1/ > =KDFO > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: minSpareThreads for AJP connector
On Fri, May 27, 2016 at 7:34 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Tony, > > On 5/26/16 4:22 PM, Anthony Biacco wrote: > > On Thu, May 26, 2016 at 2:19 PM, Anthony Biacco > > wrote: > > > >> I have this property set under 8.0.35, but it only hits the value > >> I set when i make that many requests. Should it not allocate > >> threads of the value I set on startup? > >> > >> > > btw, i'm using org.apache.coyote.ajp.AjpNioProtocol > > Can you post your complete Connector configuration? > > Sure.. > How are you testing (applying load)? How are you measuring the number > of allocated threads? > > 1 request at a time with apache ab->apache->mod_proxy_ajp/balancer->tomcat, then checking JMX (get=Catalina:type=ThreadPool,name="ajp-nio-8009"&att=currentThreadCount) it increases +1 with every request, then when i get to 25, it'll stay there (that part is right). is it maybe that tomcat won't open a thread without a connection (mod_proxy_ajp) attached to it first?? If it helps, members in my mod_proxy_ajp config look like this: BalancerMember ajp://app-01.local:8009 route=app-01 loadfactor=1 max=200 acquire=2000 connectiontimeout=1500ms disablereuse=off keepalive=off ping=1500ms timeout=30 retry=60 ttl=120 flushpackets=on -Tony > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJXSEz3AAoJEBzwKT+lPKRYxlIQAJVil7ttuuOMkQm3TFqrTIej > rKj2/rLyvo5x0UGE2POsWbAKNBq48eUPEOtSAJ1KvYmSaJ02q/nMDO/Uvf5aNIyA > Ms2DJpn6L6uqM7GZO5dPXWtcNdughEOI2uMqFFJUBtNpjaBEeofNnv+LthGYzVjy > 0MkZ2CLiSD54rrdTiZzCa7Q9bkc/y7sRzQN0G8ChKiYJumON2aYK+16iLH8XVHCs > QFTe5I988mRnFP8c2r2G0gPVGxtBRdqXPPLIsJRUpxDmoYuo9/JGL0jI3GaCAX4H > 4zrQqZmur5JfjqzsL8ehCGpQrEHzy8yseU8XhgLxZzWyUWWta04zwQn5noOUVEAf > kcPQa72+RwNUd6i8446Pi8HdY+N1S3BFbjh/WQ8/jAk8AzzQtKye7UYBm3OxaHLw > k+J+C+E7V4p+4GZDKR707+vE2q7//WEFYnor47WGwITxxRI+KP8z9jHkoBithdq1 > kMNlQyz/nsB4tIjRrTTSnp8N27HPFcFWdRL43m0dOnV+xCkwBs7F1aeUaQy9XonN > 6hm67eIEx7nQ0BLnEziu9TO2fqRioOkFjuhnB2NURo+A6vebjwI9BLv3kJhAIpUu > dmss7t+Ht8u5Nv+FTF/ntOm51MaNtp0HPjvGrjS1UJnD/seWef7sk8UPlB4EC3vb > 56K0Na1fQVOzGYqtXcfg > =sGAr > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Direct url access to protected page: /docs*
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Robert, On 5/27/16 1:16 PM, Robert Youngblood wrote: > I was recently cited for these pages not being locked down. Is > there a way to remove or lockdown the default pages? What default pages? Do you mean the "docs" web application? $ rm -rf webapps/docs You might want to remove the other stock applications as well... you should only be deploying those on a test/dev server. I always recommend a split CATALINA_HOME/CATALINA_BASE where CATALINA_HOME has a stock Tomcat deployment (including all of the optional web applications in CATALINA_HOME/webapps) and then only my own web applications in CATALINA_BASE/webapps. That way, you don't have to remember to remove the sample applications. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJXSIfyAAoJEBzwKT+lPKRYjoIQAKVOs1VgP9zLXtog763TfVjq 4Wgy/oVpkWkqh/JfTFX9UyN1c5er0VZ9bTD+T8qyD74OY22hIh88Fm63CgMzTKUa ffesrlz6u8jtW2Xn9JEgkVqV4dVHwh7oibuJSp172Z9PhTCS+EYkpp2krXe+7Otx pKwBL1eCEB1dRDJdzwfQOHAuJRGqEzoKPvbs5Zh6xiNamcW0gygP1rBJTAj9T1aR CSbcG1979mOJ/j2JdKh1LF7nvyDdyHa9IcjOvvLlFnUQKNESG1MIxuHlMuO9VfCu /6u9fpCHuN+CXvEgNmeNtzzr8+mn/eP7K+J+hy3ahD3KMzt2WwzT/RGqh759s26S rvr8W3d5fESD9SHrzjGe5iLPWWZlc8MiZU2vsUkyGNJqbDaOB+KB5qkhYTpnhcU7 A1hmFQDxghEwNpHluEjT9Ob9iR4FsFkimohcUcg0SfDmtRCMo9Yl068kPj44tFnF M8En57BF30EkZl9Gg5smALu+EycfYanSnjiU4rZLMLUwaR+YOBMHejY+9MooBrvm xf1zK7V+1WMnfg8fVxGTXeqC5fN+7UKLr+8XID05ATyAKJSSGciz3B8gWbzfGuzY rkB+0s8akFFnMgXVHIIVdZyLFel0+ebFIeyZov6a37Tv3h9jEtcJEeqDtL4NmBa+ Ja0S62rO+Ssm/kBp3h1/ =KDFO -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat8.0.33 classpath/classloader issues
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Sanka,
On 5/27/16 1:07 PM, Sanka, Ambica wrote:
> Do you need to add for your case? Please
> check
> http://tomcat.apache.org/tomcat-8.0-doc/class-loader-howto.html
This is almost never the right solution to a problem.
- -chris
> -Original Message- From: Venkata Reddy P
> [mailto:venkata.re...@trianz.com] Sent: Friday, May 27, 2016 1:02
> PM To: Tomcat Users List Subject: RE:
> tomcat8.0.33 classpath/classloader issues
>
> Many thanks Ambica for the detailed information. Its not working
> some reason for me, when I was debugging the Bootstrap.java class I
> could clearly see that creating common, shared,and catlina loaders
> as I expected.
>
> While loading the server.xml protocol classes are trying to load
> then it gets failed.I have customized by extending the
> Http11Protocol but unfortunately unable to load the tomcat/lib
> class(Http11Protocol).
>
>
> -Original Message- From: Sanka, Ambica
> [mailto:asa...@atpco.net] Sent: 27 May 2016 21:04 To: Tomcat Users
> List Subject: RE: tomcat8.0.33 classpath/classloader issues
>
> We use Tomcat 8.0.9 for our applications. Tomcat server package, we
> created required directories at the same level as conf. We create
> db2 folder and put db2 client jars. Created mq folder and put mq
> client jars. We also use some property files(name-value pair) and
> place those files under properties folder. Refer that in
> catalina.properties as below
>
> Then updated catalina.properties as below
> common.loader="${catalina.base}/lib","${catalina.base}/lib/*.jar","${c
atalina.home}/lib","${catalina.home}/lib/*.jar","${catalina.home}/db2/*.
jar","${catalina.home}/mq/*.jar","${catalina.home}/wasejb/*.jar","${cata
lina.home}/conf","${catalina.home}/properties"
>
> Our applications work fine. Not sure if this got changed in next
> versions.
>
> Ambica.
>
> -Original Message- From: Venkata Reddy P
> [mailto:venkata.re...@trianz.com] Sent: Friday, May 27, 2016 8:06
> AM To: Tomcat Users List Subject: RE:
> tomcat8.0.33 classpath/classloader issues
>
> Hi,
>
>
>
> As Ambica suggested, I have tried by setting different properties
> "common.loader, shared.loader, server.loader" in
> catalina.properties but no luck. I have tried generating the logs
> using -Djava.security.debug=all.
>
> Will this security (scl: getPermissions ProtectionDomain
> (file:/C:/tomcat8.0.33/lib/tomcat-coyote.jar certificates>) cause any problem for class loading while loading
> the jars?
>
>
>
> log4j:WARN No appenders could be found for logger
> (org.apache.tomcat.util.digester.Digester).
>
> log4j:WARN Please initialize the log4j system properly.
>
> log4j:WARN See
> http://logging.apache.org/log4j/1.2/faq.html#noconfig for more
> info.
>
> java.lang.NoClassDefFoundError:
> org/apache/coyote/http11/AbstractHttp11JsseProtocol
>
> at java.lang.ClassLoader.defineClass1(Native Method)
>
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
>
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142
)
>
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
>
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
>
> at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
>
> at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
>
> at java.security.AccessController.doPrivileged(Native Method)
>
> at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
>
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
>
> at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
>
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>
> at java.lang.Class.forName0(Native Method)
>
> at java.lang.Class.forName(Class.java:264)
>
> at
> org.apache.catalina.connector.Connector.(Connector.java:70)
>
> at
> org.apache.catalina.startup.ConnectorCreateRule.begin(ConnectorCreateR
ule.java:62)
>
> at
> org.apache.tomcat.util.digester.Digester.startElement(Digester.java:11
78)
>
> at
> org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown
> Source)
>
> at
> org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unkno
wn
> Source)
>
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement
(Unknown
> Source)
>
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentD
ispatcher.dispatch(Unknown
> Source)
>
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unk
nown
> Source)
>
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
>
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source)
>
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
>
> at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
> Source)
>
> at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown
> Source)
>
> at
> org.apache.tomcat.util.digester.D
Re: JSON Logging of Tomcat Access Log.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Abhijit,
On 5/25/16 4:03 PM, Abhijit Das wrote:
> I am wanting to change the access logging format to JSON (for
> easier parsing with logstash)
>
> I currently have the following config in my server.xml … How would
> i change this to JSON formatted?
>
> internalProxies="1\.1\.1\.1" trustedProxies="1\.1\.1\.1"
> remoteIpHeader="X-Forwarded-For" proxiesHeader="x-forwarded-by"
> requestAttributesEnabled="true"/>
>
> directory="logs" prefix="localhost_access_log" suffix=".txt"
> pattern="%t %h %{X-AUSERNAME}o %{Referer}i %l %S %{User-Agent}i %U
> %s %r %q %A %v %p %b %I %D" requestAttributesEnabled="true"
> resolveHosts="false"/>
AccessLogValve was written to conform to the age-old httpd log file
format, subject to whatever "pattern" you want to apply.
You could sprinkle your pattern full of JSON stuff, but then
JSON-escaping wouldn't actually occur, etc.
If you want JSON logging, you are going to have to write your own valve.
If you want to extend + override the existing AccessLogValve to create
a JSONAccessLogValve, consider contributing that code back to the
community.
- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJXSIa4AAoJEBzwKT+lPKRYkNUP/jYOb0raLI5etOIq8ulWbMvV
C4OdMfQuftNEB1HnZLcdekDAQpYLHC+iNf5dvsau/JaA9BBvS8kBaD9/va/FgXIk
rvG5AX8AceO2ynYujnjXNXTVCDaue8CX+jgHF55neQxbW8SaTTB1ZmluJnpTZfK9
MhPLNrZ75nShFb5dAkWsTJhv4LHdwZTdlT8IrDPm4cNDmQbzgsmg5bPl5YJuRCk7
7vpYeS6B4zasD9JKxRtpVPgItQbPGOY6xzHmr+9wvz48QQJsIgbnB96CunEvbwce
QdLshOsOePX9Sd137al3DzVp5Xum2VgezriOq33uwoDWYFPCvICSh7KDidMNm07Z
heq8kjfcVY60lD5PFaiC9arYoRDntNdwKuhBkfSNeRhQCg2EQdN2RRYXWR+CpXT0
2MRRLPhZHcTcw23e3l2h2QohbD7nzkQUs3ZQLF5gEnWk0Ldr/wz78C9aYJEkX00h
DM6kNtVUZ3A1INKPVj+KfU+qX8obwmrWeHpV8eWjhQEoZHQhFqUUW+g7XTXt/ecl
rgtjGBT3UdEwC9pVBd1/yIpKOzQj28q9xjVnOsIuKZgDdX++UyZNAURWOU3tZUS+
0+netcVdDQorH4LQVUGL27I+6jzE6zFIkImS6T+oQ11a+qEFhyOTCQNdFKqcWisc
3doWobqkvGtMOttNNS6f
=njcz
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat 8.0.35 available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David, On 5/25/16 2:05 PM, David Wall wrote: > Does anybody know if the AES+GCM bug that causes a JVM Crash (I > believe only under JDK 8) when running TLS in Tomcat using Java's > JSSE has been fixed? I doubt this is a Tomcat issue, but since the > bug likely only appears for uses of TLS's AES+GCM in Tomcat, I hope > someone here may know the details. I can't seem to track the fix > (it's a rather old bug considering the severity of a JVM crash just > using TLS) in Java. Do you have a reference for such a crash? Are you talking about this one ? https://bugs.openjdk.java.net/browse/JDK-8068663 I don't have an OpenJDK account, so I can't (currently) see the status of the bug that one claims to duplicate. Since you are using JSSE, Tomcat is using 100% Java code, so the crash is squarely a JVM bug. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJXSIY2AAoJEBzwKT+lPKRYHOYQAMChD3vcLWQEvZiEYKk6tFBL MghQZlk+DVDnKg4kZGzYq5t5ru4fqwB/sKkfY/Hv2KfJNf6ENpXUM5bAB327JIXY fuYyqSGgbJLSzFlxxoQAg9HsFm2DPFFoY6YMKt2E0whi1DlGZ10noTrwFnvWsiCb NgV2b2A7vJUNA9/V3sRTxp9bNyRhP9jTZNy8L/4MkruHXeh7tbZZsnqO/BzSn10T yRU06uLTyPnPUv/1egvmXiD8Qxjd14ubasxep/D9xv3e4Vi5YRXdD36unsZB5gVr 1iQaZ6uPm5h0kfgDKf3FMImWJ+o78Ls+bBWfNJf+PqBaS3/jexDv39MxPeAWUK/J 8z1D6FOTOZCv9UwCZUr0zCvS3UyJMdJThiicwGQmeGzSaYCiHFu7ExJOB9X43zzu HlmUd0iRZw2eL8nemkaktFHVJpCMC4YE3WRP1wzv20uGrp97gnvzEdA73eYL6v4l 71BEsyfRrOK+f/atYf5w5fw75kbF+rjCj8QYFWnU0qUwgBBkSoCbYSvF7uUG4Y4N LMAo+eIRkKGIGBEnr/UlXyVF+dvM4nU2sWElt0qVVJzQhLTXWPvhwUAIC54aAYvF OoE7sQwIc98/jzJ1wKfB9kYTQ2BtL+lcqUNKGb4IvUXMOgtCzDUogBKZ47R6l/yH FCAn6FhtrcqeEj9mwupe =DjPU -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Direct url access to protected page: /docs*
I was recently cited for these pages not being locked down. Is there a way to remove or lockdown the default pages? Bobby
RE: tomcat8.0.33 classpath/classloader issues
Do you need to add for your case? Please check
http://tomcat.apache.org/tomcat-8.0-doc/class-loader-howto.html
-Original Message-
From: Venkata Reddy P [mailto:venkata.re...@trianz.com]
Sent: Friday, May 27, 2016 1:02 PM
To: Tomcat Users List
Subject: RE: tomcat8.0.33 classpath/classloader issues
Many thanks Ambica for the detailed information. Its not working some reason
for me, when I was debugging the Bootstrap.java class I could clearly see that
creating common, shared,and catlina loaders as I expected.
While loading the server.xml protocol classes are trying to load then it gets
failed.I have customized by extending the Http11Protocol but unfortunately
unable to load the tomcat/lib class(Http11Protocol).
-Original Message-
From: Sanka, Ambica [mailto:asa...@atpco.net]
Sent: 27 May 2016 21:04
To: Tomcat Users List
Subject: RE: tomcat8.0.33 classpath/classloader issues
We use Tomcat 8.0.9 for our applications. Tomcat server package, we created
required directories at the same level as conf. We create db2 folder and put
db2 client jars. Created mq folder and put mq client jars. We also use some
property files(name-value pair) and place those files under properties folder.
Refer that in catalina.properties as below
Then updated catalina.properties as below
common.loader="${catalina.base}/lib","${catalina.base}/lib/*.jar","${catalina.home}/lib","${catalina.home}/lib/*.jar","${catalina.home}/db2/*.jar","${catalina.home}/mq/*.jar","${catalina.home}/wasejb/*.jar","${catalina.home}/conf","${catalina.home}/properties"
Our applications work fine. Not sure if this got changed in next versions.
Ambica.
-Original Message-
From: Venkata Reddy P [mailto:venkata.re...@trianz.com]
Sent: Friday, May 27, 2016 8:06 AM
To: Tomcat Users List
Subject: RE: tomcat8.0.33 classpath/classloader issues
Hi,
As Ambica suggested, I have tried by setting different properties
"common.loader, shared.loader, server.loader" in catalina.properties but no
luck. I have tried generating the logs using -Djava.security.debug=all.
Will this security (scl: getPermissions ProtectionDomain
(file:/C:/tomcat8.0.33/lib/tomcat-coyote.jar ) cause
any problem for class loading while loading the jars?
log4j:WARN No appenders could be found for logger
(org.apache.tomcat.util.digester.Digester).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more
info.
java.lang.NoClassDefFoundError:
org/apache/coyote/http11/AbstractHttp11JsseProtocol
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at org.apache.catalina.connector.Connector.(Connector.java:70)
at
org.apache.catalina.startup.ConnectorCreateRule.begin(ConnectorCreateRule.java:62)
at
org.apache.tomcat.util.digester.Digester.startElement(Digester.java:1178)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown
Source)
at
org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown
Source)
at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1451)
at org.apache.catalina.startup.Catalina.load(Catalina.java:552)
at org.apache.catalina.startup.Catalina.load(Catalina.java:603)
at sun.reflect.NativeMethodAc
RE: tomcat8.0.33 classpath/classloader issues
Many thanks Ambica for the detailed information. Its not working some reason
for me, when I was debugging the Bootstrap.java class I could clearly see that
creating common, shared,and catlina loaders as I expected.
While loading the server.xml protocol classes are trying to load then it gets
failed.I have customized by extending the Http11Protocol but unfortunately
unable to load the tomcat/lib class(Http11Protocol).
-Original Message-
From: Sanka, Ambica [mailto:asa...@atpco.net]
Sent: 27 May 2016 21:04
To: Tomcat Users List
Subject: RE: tomcat8.0.33 classpath/classloader issues
We use Tomcat 8.0.9 for our applications. Tomcat server package, we created
required directories at the same level as conf. We create db2 folder and put
db2 client jars. Created mq folder and put mq client jars. We also use some
property files(name-value pair) and place those files under properties folder.
Refer that in catalina.properties as below
Then updated catalina.properties as below
common.loader="${catalina.base}/lib","${catalina.base}/lib/*.jar","${catalina.home}/lib","${catalina.home}/lib/*.jar","${catalina.home}/db2/*.jar","${catalina.home}/mq/*.jar","${catalina.home}/wasejb/*.jar","${catalina.home}/conf","${catalina.home}/properties"
Our applications work fine. Not sure if this got changed in next versions.
Ambica.
-Original Message-
From: Venkata Reddy P [mailto:venkata.re...@trianz.com]
Sent: Friday, May 27, 2016 8:06 AM
To: Tomcat Users List
Subject: RE: tomcat8.0.33 classpath/classloader issues
Hi,
As Ambica suggested, I have tried by setting different properties
"common.loader, shared.loader, server.loader" in catalina.properties but no
luck. I have tried generating the logs using -Djava.security.debug=all.
Will this security (scl: getPermissions ProtectionDomain
(file:/C:/tomcat8.0.33/lib/tomcat-coyote.jar ) cause
any problem for class loading while loading the jars?
log4j:WARN No appenders could be found for logger
(org.apache.tomcat.util.digester.Digester).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more
info.
java.lang.NoClassDefFoundError:
org/apache/coyote/http11/AbstractHttp11JsseProtocol
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at org.apache.catalina.connector.Connector.(Connector.java:70)
at
org.apache.catalina.startup.ConnectorCreateRule.begin(ConnectorCreateRule.java:62)
at
org.apache.tomcat.util.digester.Digester.startElement(Digester.java:1178)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown
Source)
at
org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown
Source)
at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1451)
at org.apache.catalina.startup.Catalina.load(Catalina.java:552)
at org.apache.catalina.startup.Catalina.load(Catalina.java:603)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.ca
RE: Webapp in the same thread context
Hi, Thanks again for replying and thanks for the advice. Yes, you are right. I was able to put it work with the structure that I had in Tomcat 6.0.I just had to edit the "context.xml" from each servlet and add the following element inside the Context: This property makes the web application class loader change its order:https://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html Thanks again,Best regards,Daniel Rocha > Subject: Re: Webapp in the same thread context > To: users@tomcat.apache.org > From: ch...@christopherschultz.net > Date: Fri, 27 May 2016 09:33:46 -0400 > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Daniel, > > On 5/27/16 4:53 AM, Daniel Rocha wrote: > > The application that starts the servlets and initializes the > > static objects:/home/project/lib/app.jar The tomcat temporary > > folder "this.embedded.setBaseDir(getPath());" is located > > under:/home/project/temp_tomcat/ The servlets are located > > under:/home/project/webapps/servletname/ In the "servletname" > > directory I have what the compiler (I am using Netbeans as the > > IDE) generates under build/web directory. This means I have the > > WEB-INF, META-INF and the web pages inside the directory. The > > .class are inside the WEB-INF. > > > > Under the WEB-INF/lib of the servlets directory I have the > > "app.jar" in each of them. > > > > So, I tried to do something and it worked. > > > > I put the "app.jar" inside the tomcat temporary folder > > "/home/project/temp_tomcat/lib" (as a shared library) and I > > deleted the "app.jar" from each servlet (WEB-INF/lib/app.jar) and > > it worked. > > > > Can you please explain to me what really happened to start > > working? Is there another way (some tomcat option) to do this > > without having to put the "app.jar" inside the tomcat temporary > > folder? > > You app.jar contains both the classes required to boot the enbedded > system *and* the classes that run your web applications? > > If you have the web application classes referring to the "main app" > classes (specifically, fetching a static value), then you will always > have this problem. > > I recommend splitting your application into separate JAR files: one for > the launcher and a second one for the web application. You might even > want another one for the shared stuff. The launcher can live on its own, > the shared-library can live in Tomcat's lib/ directory, and the webapp > JAR can be in the WEB-INF/lib directory of the application. > > Any other layout will cause problems, unless you are okay with the > application being one big JAR (app.jar) in Tomcat's lib/ directory. > > The reason for this is how Java defines classes at runtime. A > (capital-C) Class is defined by the fully-qualified class name (e.g. > foo.bar.MyClass) *plus* the ClassLoader that loaded it. So if you have a > class available in different ClassLoaders (e.g. in both the webapp > ClassLoader and the shared ClassLoader), then objects of those two > Classes aren't always compatible with each other. The webapp ClassLoader > is defined to perform a local-load *first*, then delegate to the parent. > In the usual delegate-first class loading model, this issue wouldn't > happen because the parent loader would always be preferred. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJXSEy6AAoJEBzwKT+lPKRYa7MQAKbsGpfWP4lVUU0d16fFACi1 > LCPj1Es9s/Z/i3bWvClyqIjzIgI8t016nLp7i444cXR2xl2rUgEy9KLbRryyV7qI > 4H91dbb9Xvef/hYesq/T1FWK30VfkQAnQrDqdtoht9pKyYbXFhn8HUr+hBYIkxUb > GOfT/Ge7zgekYBx+hhEtDzsXTFL0b/FGMDLAYAAq+qQbfjJEiFuA5iG4/3hrQAUa > LtkmS1NDWoNSxyey4AijpomdCUrY1IrrloZayGQF+p/1Vi2Xq6gt6vEsheP+Go7M > if7ub2SA47moIXUSRvPj73IK/88/OBbMbWxzA9WXkriH7fa5ZeDa1jJDrKzVk9Tx > aPsqOcHrzc7RbkoJhOU9v8tXmdmTtlM+dWqpS/PPqxS/d7xWf+irzkKy+nWI1wau > xWNgt7uT6TG0N/sdPC0fSBujwlyz8RRndVyVIKGHTvUr4lWK8ec8YidKdaimaJyy > MmAGoZIgRUs1uP+bctBoIJN+PV+0AzXBdSu2Xqd4S5q6sfWMEM1f4p9Kg0ezewg8 > puyHKdzctkdEdJDDE5oWLZh9j2lj66u9OcjgXbEF1pjMjQyfNZI2fkTzLArAqkeV > JjDOJ0S6Avn4u1gEL8QmOLOZlnO18HI7bWBhsXUVDQZh+MAgtHFNlxkW5SXy4M5F > CBUlKxFop9HdAwEfRDjq > =vuj5 > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
RE: tomcat8.0.33 classpath/classloader issues
We use Tomcat 8.0.9 for our applications. Tomcat server package, we created
required directories at the same level as conf. We create db2 folder and put
db2 client jars. Created mq folder and put mq client jars. We also use some
property files(name-value pair) and place those files under properties folder.
Refer that in catalina.properties as below
Then updated catalina.properties as below
common.loader="${catalina.base}/lib","${catalina.base}/lib/*.jar","${catalina.home}/lib","${catalina.home}/lib/*.jar","${catalina.home}/db2/*.jar","${catalina.home}/mq/*.jar","${catalina.home}/wasejb/*.jar","${catalina.home}/conf","${catalina.home}/properties"
Our applications work fine. Not sure if this got changed in next versions.
Ambica.
-Original Message-
From: Venkata Reddy P [mailto:venkata.re...@trianz.com]
Sent: Friday, May 27, 2016 8:06 AM
To: Tomcat Users List
Subject: RE: tomcat8.0.33 classpath/classloader issues
Hi,
As Ambica suggested, I have tried by setting different properties
"common.loader, shared.loader, server.loader" in catalina.properties but no
luck. I have tried generating the logs using -Djava.security.debug=all.
Will this security (scl: getPermissions ProtectionDomain
(file:/C:/tomcat8.0.33/lib/tomcat-coyote.jar ) cause
any problem for class loading while loading the jars?
log4j:WARN No appenders could be found for logger
(org.apache.tomcat.util.digester.Digester).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more
info.
java.lang.NoClassDefFoundError:
org/apache/coyote/http11/AbstractHttp11JsseProtocol
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at org.apache.catalina.connector.Connector.(Connector.java:70)
at
org.apache.catalina.startup.ConnectorCreateRule.begin(ConnectorCreateRule.java:62)
at
org.apache.tomcat.util.digester.Digester.startElement(Digester.java:1178)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown
Source)
at
org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown
Source)
at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1451)
at org.apache.catalina.startup.Catalina.load(Catalina.java:552)
at org.apache.catalina.startup.Catalina.load(Catalina.java:603)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:310)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:484)
Caused by: java.lang.ClassNotFoundException:
org.apache.coyote.http11.AbstractHttp11JsseProtocol
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 37 more
jar: beginEntry META-INF/MANIFEST.MF
jar: done with meta!
jar: nothing to ver
Re: Tomcat 8.0.33 not seeing JSP extracted from zip during context deploy.
Hi, 2016-05-27 13:21 GMT+03:00 Gavin Donald : > > Hello, > > I recently upgraded from */Tomcat 8.0.9/***to */8.0.33/*. > > I have a zip file that contains JSPs. When the context starts a custom /ThemeManager /class looks at a /theme.jar/ file and extracts some SiteMesh decorators to /WEB-INF/decorator-template/. > > Since I upgraded to 8.0.33, Tomcat does not seem to be able to detect that those files have been extracted. The error I am seeing in the console is: > > */javax.servlet.ServletException: File [/WEB-INF/decorator-template/decorator-default.jsp] not found/* > > The error is quite obviously not finding the file, but it is in that location. No changes have been made to the ThemeManager class and everything still works fine in 8.0.9. > > Currently I need to restart Tomcat 8.0.33 a second time to see the extracted files. After that I can happily make changes to the /theme.jar/, the /ThemeManager /will redeploy it and Tomcat will serve the new version of the file. It is as if Tomcat 8.0.33 does not know those files have been extracted from the /theme.zip/ and requires a restart before it will recognise they exist. *Does anyone know why this may be (has there been a change in the way Tomcat manages JSPs recently?), and better yet - does anyone have a solution?* > > I tried to set */development/* to */true/* in */conf/web.xml/*//but it didn't help and I'm not sure that would be suitable for live/./ I have checked my web-apps log files between 8.0.9 and 8.0.33 and can't see any differences. It seems that Tomcat 8.0.33 is behaving differently to 8.0.9. > / I made very basic app based on your description but I do not observe such behaviour. Can you provide some simple example that shows the problem? (e.g. on github) Regards, Violeta > /Thanks > > Gavin./ > /
Re: minSpareThreads for AJP connector
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Tony, On 5/26/16 4:22 PM, Anthony Biacco wrote: > On Thu, May 26, 2016 at 2:19 PM, Anthony Biacco > wrote: > >> I have this property set under 8.0.35, but it only hits the value >> I set when i make that many requests. Should it not allocate >> threads of the value I set on startup? >> >> > btw, i'm using org.apache.coyote.ajp.AjpNioProtocol Can you post your complete Connector configuration? How are you testing (applying load)? How are you measuring the number of allocated threads? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJXSEz3AAoJEBzwKT+lPKRYxlIQAJVil7ttuuOMkQm3TFqrTIej rKj2/rLyvo5x0UGE2POsWbAKNBq48eUPEOtSAJ1KvYmSaJ02q/nMDO/Uvf5aNIyA Ms2DJpn6L6uqM7GZO5dPXWtcNdughEOI2uMqFFJUBtNpjaBEeofNnv+LthGYzVjy 0MkZ2CLiSD54rrdTiZzCa7Q9bkc/y7sRzQN0G8ChKiYJumON2aYK+16iLH8XVHCs QFTe5I988mRnFP8c2r2G0gPVGxtBRdqXPPLIsJRUpxDmoYuo9/JGL0jI3GaCAX4H 4zrQqZmur5JfjqzsL8ehCGpQrEHzy8yseU8XhgLxZzWyUWWta04zwQn5noOUVEAf kcPQa72+RwNUd6i8446Pi8HdY+N1S3BFbjh/WQ8/jAk8AzzQtKye7UYBm3OxaHLw k+J+C+E7V4p+4GZDKR707+vE2q7//WEFYnor47WGwITxxRI+KP8z9jHkoBithdq1 kMNlQyz/nsB4tIjRrTTSnp8N27HPFcFWdRL43m0dOnV+xCkwBs7F1aeUaQy9XonN 6hm67eIEx7nQ0BLnEziu9TO2fqRioOkFjuhnB2NURo+A6vebjwI9BLv3kJhAIpUu dmss7t+Ht8u5Nv+FTF/ntOm51MaNtp0HPjvGrjS1UJnD/seWef7sk8UPlB4EC3vb 56K0Na1fQVOzGYqtXcfg =sGAr -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapp in the same thread context
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Daniel, On 5/27/16 4:53 AM, Daniel Rocha wrote: > The application that starts the servlets and initializes the > static objects:/home/project/lib/app.jar The tomcat temporary > folder "this.embedded.setBaseDir(getPath());" is located > under:/home/project/temp_tomcat/ The servlets are located > under:/home/project/webapps/servletname/ In the "servletname" > directory I have what the compiler (I am using Netbeans as the > IDE) generates under build/web directory. This means I have the > WEB-INF, META-INF and the web pages inside the directory. The > .class are inside the WEB-INF. > > Under the WEB-INF/lib of the servlets directory I have the > "app.jar" in each of them. > > So, I tried to do something and it worked. > > I put the "app.jar" inside the tomcat temporary folder > "/home/project/temp_tomcat/lib" (as a shared library) and I > deleted the "app.jar" from each servlet (WEB-INF/lib/app.jar) and > it worked. > > Can you please explain to me what really happened to start > working? Is there another way (some tomcat option) to do this > without having to put the "app.jar" inside the tomcat temporary > folder? You app.jar contains both the classes required to boot the enbedded system *and* the classes that run your web applications? If you have the web application classes referring to the "main app" classes (specifically, fetching a static value), then you will always have this problem. I recommend splitting your application into separate JAR files: one for the launcher and a second one for the web application. You might even want another one for the shared stuff. The launcher can live on its own, the shared-library can live in Tomcat's lib/ directory, and the webapp JAR can be in the WEB-INF/lib directory of the application. Any other layout will cause problems, unless you are okay with the application being one big JAR (app.jar) in Tomcat's lib/ directory. The reason for this is how Java defines classes at runtime. A (capital-C) Class is defined by the fully-qualified class name (e.g. foo.bar.MyClass) *plus* the ClassLoader that loaded it. So if you have a class available in different ClassLoaders (e.g. in both the webapp ClassLoader and the shared ClassLoader), then objects of those two Classes aren't always compatible with each other. The webapp ClassLoader is defined to perform a local-load *first*, then delegate to the parent. In the usual delegate-first class loading model, this issue wouldn't happen because the parent loader would always be preferred. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJXSEy6AAoJEBzwKT+lPKRYa7MQAKbsGpfWP4lVUU0d16fFACi1 LCPj1Es9s/Z/i3bWvClyqIjzIgI8t016nLp7i444cXR2xl2rUgEy9KLbRryyV7qI 4H91dbb9Xvef/hYesq/T1FWK30VfkQAnQrDqdtoht9pKyYbXFhn8HUr+hBYIkxUb GOfT/Ge7zgekYBx+hhEtDzsXTFL0b/FGMDLAYAAq+qQbfjJEiFuA5iG4/3hrQAUa LtkmS1NDWoNSxyey4AijpomdCUrY1IrrloZayGQF+p/1Vi2Xq6gt6vEsheP+Go7M if7ub2SA47moIXUSRvPj73IK/88/OBbMbWxzA9WXkriH7fa5ZeDa1jJDrKzVk9Tx aPsqOcHrzc7RbkoJhOU9v8tXmdmTtlM+dWqpS/PPqxS/d7xWf+irzkKy+nWI1wau xWNgt7uT6TG0N/sdPC0fSBujwlyz8RRndVyVIKGHTvUr4lWK8ec8YidKdaimaJyy MmAGoZIgRUs1uP+bctBoIJN+PV+0AzXBdSu2Xqd4S5q6sfWMEM1f4p9Kg0ezewg8 puyHKdzctkdEdJDDE5oWLZh9j2lj66u9OcjgXbEF1pjMjQyfNZI2fkTzLArAqkeV JjDOJ0S6Avn4u1gEL8QmOLOZlnO18HI7bWBhsXUVDQZh+MAgtHFNlxkW5SXy4M5F CBUlKxFop9HdAwEfRDjq =vuj5 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Secured connection between Apache Httpd and Tomcat over AJP protocol
Hi All, Thank you very much for the solution. Best Regards, Mohan On Wed, May 25, 2016 at 9:00 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Mohanavelu, > > On 5/25/16 10:21 AM, Mohanavelu Subramanian wrote: > > I have Httpd process and Tomcat instances both running on 2 > > different machines. The communication between them happens through > > AJP protocol (mod_jk) which doesn't support encryption. But we are > > using some features of mod_jk like automatic passing of security > > information like SSL certificate to tomcat which in turn is > > accessed in our application, validated and verified. > > > > Now, we have requirement to make the communication between them as > > Secured. Since AJP doesn't support encryption, I came to know that > > we need to use SSH, IPSec. But I could not find any proper document > > to configure SSH or IPSec for AJP. Could please share if you any. > > > > I have considered mod_proxy_http as well for supporting security > > which is easy to configure as well. But as I mentioned above we are > > already making use mod_jk features. Again it will require more > > efforts to migrate from mod_jk to mod_proxy_http. > > It's not so bad switching from mod_jk to mod_proxy_http, but you are > right that it does require re-configuration. > > IPsec and SSH tunnels (using the ssh binary) are a total pain. We use > stunnel, and it's fairly simple to set up. stunnel uses SSL/TLS to > tunnel other protocols. It does *not* use the SSH protocol, which is > critical to understanding how it works. > > stunnel is a little more complicated than a normal protocol because it > can be used in a number of different ways. I'll give some contrived > examples to see how you can set it up in different ways, depending > upon the support for encryption of the underlying protocol. > > Let's say that you have an HTTPS server, but your client can't speak > HTTPS for some reason. If you set up stunnel on the *client* side, you > can connect locally to the stunnel server and have it establish a > secure-connection to the remote server running HTTPS. Like this: > > client -> localhost:12345 stunnel > stunnel -> remote_host:443 > > As far as the client is concerned, it's using HTTP to talk to > localhost. But really it's talking to remove_host:443, so everyone is > happy. (Yes, there are issues with URLs and redirects produced by the > server, but that's out of scope for this discussion). > > Let's take another example: you have clients that are HTTPS-capable, > but the service you are running can only support HTTP for some reason, > and you want to secure it. Set up stunnel on the *server*, then have > your remote clients connect to *it* and tunnel to localhost. Like this: > > client -> remote_host:443 > stunnel localhost:8080 > > As far as the client is concerned, it's using HTTPS to communicate > with remote_host:443, but really it's connecting to remote_host:8080. > (Yes, there are some issues with URLs and redirects but that's out of > scope for this discussion.) > > So what if the underling protocol doesn't support TLS at all? Well, > then you have to set up stunnel on *both sides* of the tunnel, like this > : > > client (mod_jk) -> localhost:12345 > stunnel -> remote_host:12345 > stunnel -> localhost:8009 > > The setup for stunnel looks like this for the client (on the web server) > : > > sslVersion = all > options = NO_SSLv2 > options = NO_SSLv3 > client = yes > [ajp13s] > accept=localhost:8009 > connect=remote_host:8010 > > On the server, it looks like this: > > sslVersion = all > options = NO_SSLv2 > options = NO_SSLv3 > client = no > [ajp13s] > accept=8010 > connect=localhost:8009 > > On the web server, set your worker's host to "localhost" and port to > 8009. mod_jk will connect to localhost:8009 which stunnel will accept > and forward over the network to remote_host:8010 which will be > accepted by stunnel on the server and forwarded to localhost:8009 on > the server. > > stunnel is great because it will auto-reconnect if the connection is > dropped for some reason. Remember a few things with stunnel: > > 1. Depending upon the version, you might only be able to use TLSv1 > (and not e.g. TLSv1.2) > 2. stunnel generally ignores certificate issues, such as expiration, > etc. You might want to configure it with a little more care than the > default. THIS ALSO MEANS IT DOES NOT AUTHENTICATE THE SERVER BY > DEFAULT. You could accidentally connect to a malicious server. > > Hope that helps, > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAldFxP8ACgkQ9CaO5/Lv0PBskQCfUnXqw5wGSTo+Tr9wk6ZvxJCq > NPsAoJaPHHhvHCkI8TnAMaCrQ5q3y9x9 > =h4AI > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional comma
RE: tomcat8.0.33 classpath/classloader issues
Hi,
As Ambica suggested, I have tried by setting different properties
"common.loader, shared.loader, server.loader" in catalina.properties but no
luck. I have tried generating the logs using -Djava.security.debug=all.
Will this security (scl: getPermissions ProtectionDomain
(file:/C:/tomcat8.0.33/lib/tomcat-coyote.jar ) cause
any problem for class loading while loading the jars?
log4j:WARN No appenders could be found for logger
(org.apache.tomcat.util.digester.Digester).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more
info.
java.lang.NoClassDefFoundError:
org/apache/coyote/http11/AbstractHttp11JsseProtocol
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at org.apache.catalina.connector.Connector.(Connector.java:70)
at
org.apache.catalina.startup.ConnectorCreateRule.begin(ConnectorCreateRule.java:62)
at
org.apache.tomcat.util.digester.Digester.startElement(Digester.java:1178)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown
Source)
at
org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown
Source)
at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1451)
at org.apache.catalina.startup.Catalina.load(Catalina.java:552)
at org.apache.catalina.startup.Catalina.load(Catalina.java:603)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:310)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:484)
Caused by: java.lang.ClassNotFoundException:
org.apache.coyote.http11.AbstractHttp11JsseProtocol
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 37 more
jar: beginEntry META-INF/MANIFEST.MF
jar: done with meta!
jar: nothing to verify!
scl: getPermissions ProtectionDomain (file:/C:/tomcat8.0.33/bin/bootstrap.jar
)
sun.misc.Launcher$AppClassLoader@18b4aac2
java.security.Permissions@387c703b (
("java.lang.RuntimePermission" "exitVM")
("java.io.FilePermission" "\C:\tomcat8.0.33\bin\bootstrap.jar" "read")
)
scl:
jar: beginEntry META-INF/MANIFEST.MF
jar: done with meta!
jar: nothing to verify!
scl: getPermissions ProtectionDomain (file:/jre8/lib/ext/tomcat-juli.jar )
sun.misc.Launcher$ExtClassLoader@3ecf72fd
java.security.Permissions@483bf400 (
("java.io.FilePermission" "\C:\jre8\lib\ext\tomcat-juli.jar" "read")
)
scl:
jar: beginEntry META-INF/MANIFEST.MF
jar: done with meta!
jar: nothing to verify!
scl: getPermissions ProtectionDomain
(file:/C:/jre8/lib/ext/tomcat-juli-adapters.jar )
sun.misc.Launcher$ExtClassLoader@3ecf72fd
java.security.Permissions@1fbc7afb (
("java.io.FilePermission" "\C:\jre8\lib\ext\tomcat-juli-adapter
Tomcat 8.0.33 not seeing JSP extracted from zip during context deploy.
Hello, I recently upgraded from */Tomcat 8.0.9/***to */8.0.33/*. I have a zip file that contains JSPs. When the context starts a custom /ThemeManager /class looks at a /theme.jar/ file and extracts some SiteMesh decorators to /WEB-INF/decorator-template/. Since I upgraded to 8.0.33, Tomcat does not seem to be able to detect that those files have been extracted. The error I am seeing in the console is: */javax.servlet.ServletException: File [/WEB-INF/decorator-template/decorator-default.jsp] not found/* The error is quite obviously not finding the file, but it is in that location. No changes have been made to the ThemeManager class and everything still works fine in 8.0.9. Currently I need to restart Tomcat 8.0.33 a second time to see the extracted files. After that I can happily make changes to the /theme.jar/, the /ThemeManager /will redeploy it and Tomcat will serve the new version of the file. It is as if Tomcat 8.0.33 does not know those files have been extracted from the /theme.zip/ and requires a restart before it will recognise they exist. *Does anyone know why this may be (has there been a change in the way Tomcat manages JSPs recently?), and better yet - does anyone have a solution?* I tried to set */development/* to */true/* in */conf/web.xml/*//but it didn't help and I'm not sure that would be suitable for live/./ I have checked my web-apps log files between 8.0.9 and 8.0.33 and can't see any differences. It seems that Tomcat 8.0.33 is behaving differently to 8.0.9. / /Thanks Gavin./ /
Spring's WebApplicationInitializer not working
Hi, I post my issue here http://stackoverflow.com/questions/37284249/springs-webapplicationinitializer-servlet-registration-doesnt-work-on-apache but nobody replied yet so I am trying my luck here. Let me just add that when I configure JSF the usual way (web.xml) everything works fine. Thanks for any pointers, Zbynek
RE: Webapp in the same thread context
Hi,
Thanks for replying.
I have the following structure:
The application that starts the servlets and initializes the static
objects:/home/project/lib/app.jar
The tomcat temporary folder "this.embedded.setBaseDir(getPath());" is located
under:/home/project/temp_tomcat/
The servlets are located under:/home/project/webapps/servletname/
In the "servletname" directory I have what the compiler (I am using Netbeans as
the IDE) generates under build/web directory. This means I have the WEB-INF,
META-INF and the web pages inside the directory. The .class are inside the
WEB-INF.
Under the WEB-INF/lib of the servlets directory I have the "app.jar" in each of
them.
So, I tried to do something and it worked.
I put the "app.jar" inside the tomcat temporary folder
"/home/project/temp_tomcat/lib" (as a shared library) and I deleted the
"app.jar" from each servlet (WEB-INF/lib/app.jar) and it worked.
Can you please explain to me what really happened to start working?Is there
another way (some tomcat option) to do this without having to put the "app.jar"
inside the tomcat temporary folder?
Thank you in advance,Best regards,Daniel Rocha
> Subject: Re: Webapp in the same thread context
> To: users@tomcat.apache.org
> From: ch...@christopherschultz.net
> Date: Wed, 25 May 2016 14:19:22 -0400
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Daniel,
>
> On 5/25/16 11:03 AM, Daniel Rocha wrote:
> > I have a java application that was running with "Embedded" class
> > from Tomcat 6.0.Now I am trying to upgrade it to run with Tomcat
> > 7.0.69.
> >
> > The current java application is initializing some static objects
> > and then starts the "Embedded" class with some Servlets.The
> > Servlets that were initialized access to the static objects from
> > the application that started them. This works fine with Tomcat
> > 6.0.
> >
> > Now, I am using the "Tomcat" class from Tomcat 7.0 to start the
> > same Servlets.The servlets are initialized and I can access to
> > their context path.
> >
> > The problem is when I try to access from the Servlet to a static
> > initialized object from the application that started them.The
> > object is null here.
>
> Where is the .class file located for the servlet? Where is the .class
> file located for the "static initialized object" reference? You need
> to be very specific about what's going on, here, because lack of
> precision can cause all kinds of missteps.
>
> > I do not know if this is related to the context class loader.
>
> It's almost certainly related to the ClassLoader... probably the
> WebappClassLoader.
>
> > The code looks something like this:
> >
> > // Port number int port = 8080; // Create an embedded
> > serverthis.embedded = new Tomcat();
> > this.embedded.setBaseDir(getPath()); this.embedded.setPort(port);
> > // Set default virtual hostthis.host = this.embedded.getHost();
> > this.host.setAppBase(getPath() + "/webapps"); // Create the ROOT
> > contextthis.rootcontext = this.embedded.addWebapp(this.host, "",
> > getPath() + "/webapps/ROOT");
> > this.rootcontext.setReloadable(false);
> > this.rootcontext.addWelcomeFile("index.jsp"); // Create servlet
> > context this.rootcontext = this.embedded.addWebapp(this.host,
> > "/context",
> "/home/path/to/app");
> > this.rootcontext.setReloadable(false);context.setPrivileged(true);
> >
> > // Set connector propertiesConnector connector =
> > this.embedded.getConnector(); connector.setSecure(false);
> > connector.setProperty("maxThreads", "10");
> > connector.setProperty("acceptCount", "20");
> > connector.setProperty("asyncTimeout", "3");
> > connector.setProperty("connectionTimeout", "3");
> > connector.setProperty("socket.soTimeout", "3");
> > connector.setEnableLookups(false);
> >
> > this.embedded.setConnector(connector); // Start the embedded
> > server this.embedded.start();
>
> There is nothing in that code that is going to cause any problem like
> you describe. Tell us how the code that fails interacts with the code
> that is (likely) loaded from the wrong ClassLoader.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJXReyqAAoJEBzwKT+lPKRYyREP/iFMdNtenVwqDSw3u7senlVs
> UUQ4QrdiHa1CYtl3DZMNnxq47EnK8oKbHEsR4ELN4K1fJ2MzDC+gCL33AhFF8b1+
> bNRczRdj9aq3SbHqWR7Cb06CRj3qZ6FKexlHaHVgAVBuo0o7+Vp1+P843qWjDLCt
> ZrWQ9gdsMI/9spKXn11QnP/q0yW3SiMoTOTTob5ByEKfhZMFupuhCBZnhqQC2fZh
> D0iivElIaJer4Q5OXDblo4lBfwFSJtT2Xlkqx4B2xMNVf1obrYai4tGlXNtXVlwI
> wgsLvmaRT9tOCf/6uSnuTNKlxX5P3FKQYbyecsYUCmHysJ+f6kGIxY3PdwuL4Arq
> 4OlyfsYX6wDtcHGEw+T9gtG+Z+QQw1RKLwtYv6sasEjQIusVNJGwZbsWgi+TYNS5
> C2Ini934fDWJwc9DljEjvr3cYQMEt5ysMKNMVAG0d4SLsL9ug1iBiuv/ZH4LcG0m
> +PWq6kGOmlpUHq/j7ySvKadg/YvXzr5OTagr7hCn88Z3WU0K+oJcKgE9QA9qDHGc
> 9a+ZyNFRbdfh4yW5zmCbK+0EYH6BZ9mjKU/tOVjjaiqEU/AJOb9itLVHXz6yek5e
> LlHXomL1w1tJGQ9zYiJx3/oBHC1px05n0hqfKKkfbRjsUI44Mjuyqo0SpymWxQi/
> XuI+yXCgM4Vi
