RE: Java Heap Space / Thread Dump Numbers
Christopher Shultz wrote: // Time to upgrade. Tomcat is hideously out of date (probably because you are using RedHat's Tomcat package), at least by version number. I'm not sure what RedHat does (if anything) about security fixes, etc. but a vanilla 6.0.18 is probably vulnerable and has been for a very long time. Java 1.6 is EOL and Java 1.7 is getting close. I strongly advise you to move up to Tomcat 8.0.20 and Java 1.8 and start developing and testing your application against those versions. // Would if I could. Vendor restriction. I can only run what they will support. Christopher Shultz wrote: // Typical startup options looks like this... JAVA_OPTS=-Xms192M -Xmx384M \ -XX:MaxPermSize=128M \ Those seem reasonable, except maybe not PermGen. Are you increasing it or reducing it from the default on your platform? // Increased from default of 64 MB, which ran fine for years until a recent software upgrade. Christopher Shultz wrote: // The memory allocation seems low to you because we run many instances of tomcat on the same server. Although the servers have 32-64GB of RAM, the individual tomcat/java instances are kept fairly low. We ran for years in a 64MiB heap. Then we got enough traffic that sessions required us to expand our heaps. If you can run in a small heap, great. But keep your eye on what's happening with your users; you may find that you have outgrown your old heap settings. // That's what this question is about. We ran 64 MB heaps for years, but with the latest application software version we find that 192-384 is required per instance. Others throw errors unless they get 768. We cannot set them all the same, so we need to configure them very carefully and closely. Christopher Shultz wrote: // We are trying to be proactive by watching the memory usage numbers in the thread dumps. Heap dumps? // What we do is called a thread dump, as far as I know. We use kill -3 on Linux, which dumps the thread activity. The memory data shows up at the bottom of that. See: http://producthelp.sdl.com/WorldServer/10.2/en/GUID-4F09CD10-BC4F-46A8-AE83-599A5C8C7740.html --Eric
Can't set context to / in Tomcat 8.0.20
Hi, I'm in the process of migrating to a embedded tomcat 7.0.59 application to tomcat 8.0.20. In the application i'm setting the context as */* This works fine in tomcat 7 But in Tomcat 8 when I set the context as */*, internally it is set as . Is this a bug in Tomcat 8? Thanks Best Regards /Thusitha -- Thusitha Dayaratne Software Engineer WSO2 Inc. - lean . enterprise . middleware | wso2.com Mobile +94712756809 Blog alokayasoya.blogspot.com Abouthttp://about.me/thusithathilina
Re: Can't set context to / in Tomcat 8.0.20
Hi All,
Prior to Tomcat 7.0.58, we are able to set the context as /. In the code
it will go to else part and set the context without any issues.
public void setPath(String path) {
if (path == null || (!path.equals() !path.startsWith(/))) {
this.path = / + path;
log.warn(sm.getString(
standardContext.pathInvalid, path, this.path));
} else {
this.path = path;
}
encodedPath = urlEncoder.encode(this.path);
if (getName() == null) {
setName(this.path);
}
}
But from 7.0.58, when we trying to set context as /, it will matches
the first of condition as make the path an empty string().
public void setPath(String path) {
boolean invalid = false;
if (path == null || path.equals(/)) {
invalid = true;
this.path = ;
} else if (.equals(path) || path.startsWith(/)) {
this.path = path;
} else {
invalid = true;
this.path = / + path;
}
if (this.path.endsWith(/)) {
invalid = true;
this.path = this.path.substring(0, this.path.length() - 1);
}
if (invalid) {
log.warn(sm.getString(
standardContext.pathInvalid, path, this.path));
}
encodedPath = urlEncoder.encode(this.path);
if (getName() == null) {
setName(this.path);
}
}
Is there a any specific reason for this change?
Why it is not allowing to set the context path as /
Thanks
Best Regards
/Thusitha
On Thu, Mar 19, 2015 at 4:35 PM, Thusitha Thilina Dayaratne
thusit...@wso2.com wrote:
Hi
Thanks for quick response.
Hi,
I'm in the process of migrating to a embedded tomcat 7.0.59 application
to
tomcat 8.0.20. In the application i'm setting the context as */* This
works fine in tomcat 7
But in Tomcat 8 when I set the context as */*, internally it is set as
.
Is this a bug in Tomcat 8?
No.
Why it it is not allowing to set Context as / in tomcat 8?
Thanks
Regards
/Thusitha
On Thu, Mar 19, 2015 at 4:26 PM, Mark Thomas ma...@apache.org wrote:
On 19/03/2015 10:55, Thusitha Thilina Dayaratne wrote:
Hi,
I'm in the process of migrating to a embedded tomcat 7.0.59 application
to
tomcat 8.0.20. In the application i'm setting the context as */* This
works fine in tomcat 7
But in Tomcat 8 when I set the context as */*, internally it is set
as .
Is this a bug in Tomcat 8?
No.
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
--
Thusitha Dayaratne
Software Engineer
WSO2 Inc. - lean . enterprise . middleware | wso2.com
Mobile +94712756809
Blog alokayasoya.blogspot.com
Abouthttp://about.me/thusithathilina
--
Thusitha Dayaratne
Software Engineer
WSO2 Inc. - lean . enterprise . middleware | wso2.com
Mobile +94712756809
Blog alokayasoya.blogspot.com
Abouthttp://about.me/thusithathilina
Re: Can't set context to / in Tomcat 8.0.20
Do NOT cross-post questions to the users list and the dev list. All this does is annoy the very people you are relying on to take time out of whatever else they are doing to help you. If you aren't sure where to ask, user the users list. On 19/03/2015 11:50, Thusitha Thilina Dayaratne wrote: Hi All, Prior to Tomcat 7.0.58, we are able to set the context as /. There are lots of things you can set configuration values to and Tomcat will still start. That doesn't mean that they are sensible settings or even valid ones. While Tomcat will usually catch obviously broken settings, users are expected to RTFM before they start changing things. / has never been a valid value for the context path as has been made clear in the Servlet specification and the Tomcat docs for as long as I can remember (10+ years). snip/ Is there a any specific reason for this change? Why it is not allowing to set the context path as / There is no change. That has never been valid. That it worked in some subset of previous Tomcat versions is nothing more than luck. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Java Heap Space / Thread Dump Numbers
Eric, if you are looking for a reasons and think, what can be done with OOMs, take a look at this page: http://www.oracle.com/technetwork/articles/java/vmoptions-jsp-140102.html There is an options: -XX:-HeapDumpOnOutOfMemoryError - it will make heapdump on OOM. -XX:HeapDumpPath=./java_pidpid.hprof - give it an reasonable path to file. After you get an heapdump - use Eclipse Memory Analyzing Tool, there is an effective Find Leak Suspects report, and also Dominator Tree. https://www.dropbox.com/s/m2kgvel22vjjrzv/screenshot_000122.png?dl=0 - this is an example. This way I've found an memory leak in BoneCP, for example. https://www.dropbox.com/s/3v0tb56b5uu7ub6/screenshot_000123.png?dl=0 - look, 634M of SybConnections (Sybase ASE connection). https://www.dropbox.com/s/64qsm9wd5ls1h5v/screenshot_000124.png?dl=0 - Each SybConnection occupy from 14M to 45M of heap. https://www.dropbox.com/s/p2qpqmn9r65481i/screenshot_000125.png?dl=0 - Dominator Tree will show, what is the reason, in my case it was a bunch of SQLWarnings in each connection. Also you can monitor a server instance with JVisualVM. Use VisualGC plugin to visualize, what's happening with your Tomcat's heap in detail: https://www.dropbox.com/s/za36q46v765gltf/screenshot_000126_cut.png?dl=0 (VisualGC is a downloadable plugin to JVisualVM, JVisualVM can be found in the bin directory of installed JDK). You may also need to launch jstatd with the same user, which launched Tomcat to be able to monitor Tomcat remotely. Good luck! :) 2015-03-19 3:35 GMT+02:00 Caldarale, Charles R chuck.caldar...@unisys.com: From: Eric Robinson [mailto:eric.robin...@psmnv.com] Subject: Java Heap Space / Thread Dump Numbers PSYoungGen total 95808K, used 22323K [0x2aaac377, 0x2aaaca21, 0x2aaaca21) eden space 82432K, 10% used [0x2aaac377,0x2aaac402f7f8,0x2aaac87f) from space 13376K, 99% used [0x2aaac87f,0x2aaac94fd5a8,0x2aaac950) to space 13376K, 0% used [0x2aaac950,0x2aaac950,0x2aaaca21) PSOldGentotal 177792K, used 144800K [0x2aaab621, 0x2aaac0fb, 0x2aaac377) object space 177792K, 81% used [0x2aaab621,0x2aaabef78110,0x2aaac0fb) PSPermGen total 120960K, used 65149K [0x2e21, 0x2aaab583, 0x2aaab621) object space 120960K, 53% used [0x2e21,0x2aaab21af440,0x2aaab583) Which of those lines represents the heap space? Actually, all of them. The JVM's heap is not just a simple collection, but is instead a somewhat complex structure designed to facilitate garbage collection. A brief description of the components: eden space - where most objects are born (and most of them die) from-space - where live objects exist after a minor garbage collection to-space - where objects will be copied to during a minor garbage collection old gen object space - where long-lived objects reside perm gen object space - where instances of java.lang.Class reside Normally sized objects are initially created in eden. When eden fills, a minor GC copies most live objects from eden and the from-space into the to-space; objects that have been around a while are instead put into old gen. At the end of the minor GC, the from- (now empty) and to-spaces swap roles. When things get too full, a major GC is initiated, which squeezes out any dead space from the old gen. One exception to the above is allocation of large objects, which are placed immediately into old gen. Your OOME may be due to attempting to allocate something big. Since you didn't provide any information about the JVM version, GC settings, platform you're running on, or what your applications do, it's hard to say whether or not your heap is sized appropriately. However, your total of around 262M is rather small in this age of 64-bit machines with multiple gigabytes of memory. More information (not all of it up to date): http://www.oracle.com/technetwork/java/javase/tech/index-jsp-140228.html - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Apache Standard Taglib 1.2.5 released
The Apache Tomcat team announces the immediate availability of Apache Standard Taglib 1.2.5. Apache Standard Taglib is an open source software implementation of the JSP Standard Tag Library (JSTL) technology. This release supports JSTL version 1.2 and includes minor bug-fixes to the previous 1.2.3 release. The notable changes include: - Reversion of a change released in 1.2.1 where c:import set the HTTP method to GET when performing a local include - Avoid an AccessControlException if permission has not been granted to read the accessExternalEntity property Please refer to the project website for additional information. http://tomcat.apache.org/taglibs.html Enjoy! - The Apache Tomcat team signature.asc Description: Message signed with OpenPGP using GPGMail
Re: SSL Issue on the 443 port on tomcat7
Thanks Akbar,
It's worked.
Regards,
Vijay S
On Thu, Mar 19, 2015 at 10:31 PM, Akbar Thanakalacheruvu
akb...@sumtotalsystems.com wrote:
-Original Message-
From: Vijay Karthick [mailto:vijaykarthic...@gmail.com]
Sent: Thursday, March 19, 2015 12:11 PM
To: users@tomcat.apache.org
Subject: Fwd: SSL Issue on the 443 port on tomcat7
Hi,
In SAP BO environment, the SSL has been enabled in the Tomcat7 version.
However, the Tomcat is not initializing. Its states that password error.
I've recreated the keystore file. However, we're unable to fix it. Please
refer the Log on the Tomcat folder.
Server.xml :
Connector port=443 protocol=HTTP/1.1 SSLEnabled=true
maxThreads=150 scheme=https secure=true
clientAuth=false sslProtocol=TLS
maxHttpHeaderSize=65536 keystore=D:\SAP
BusinessObjects\Tomcat6\conf\.keystore keypass=Password /
The tomcat logs folder file stderr files give the below log,
2015-03-18 23:10:01 Commons Daemon procrun stderr initialized
Mar 18, 2015 11:10:02 PM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal
performance in production environments was not found on the
java.library.path: C:\Windows\SysWOW64\;D:\SAP BusinessObjects\SAP
BusinessObjects Enterprise XI 4.0\win64_x64\
Mar 18, 2015 11:10:02 PM org.apache.catalina.startup.SetAllPropertiesRule
begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'keystore' to 'D:\SAP BusinessObjects\tomcat\conf\.keystore' did not find a
matching property.
Mar 18, 2015 11:10:02 PM org.apache.catalina.startup.SetAllPropertiesRule
begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'keypass' to 'Password' did not find a matching property.
Mar 18, 2015 11:10:02 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler [http-bio-443]
Mar 18, 2015 11:10:03 PM org.apache.coyote.AbstractProtocol init
SEVERE: Failed to initialize end point associated with ProtocolHandler
[http-bio-443]
java.io.IOException: Keystore was tampered with, or password was incorrect
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:771)
at
sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:38)
at java.security.KeyStore.load(KeyStore.java:1183)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getStore(JSSESocketFactory.java:407)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeystore(JSSESocketFactory.java:306)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:565)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:505)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.init(JSSESocketFactory.java:449)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket(JSSESocketFactory.java:158)
at org.apache.tomcat.util.net.JIoEndpoint.bind(JIoEndpoint.java:393)
at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:610)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:429)
at
org.apache.coyote.http11.AbstractHttp11JsseProtocol.init(AbstractHttp11JsseProtocol.java:119)
at
org.apache.catalina.connector.Connector.initInternal(Connector.java:981)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at
org.apache.catalina.core.StandardService.initInternal(StandardService.java:559)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:814)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at org.apache.catalina.startup.Catalina.load(Catalina.java:633)
at org.apache.catalina.startup.Catalina.load(Catalina.java:658)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:281)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:450)
Caused by: java.security.UnrecoverableKeyException: Password verification
failed
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:769)
... 26 more
--
Vijay
The attributes that you mentioned in the server.xml file should be
corrected as follows
keystore with keystoreFile
keypass with keyPass (P is Capital here)
-Akbar
This message and any attachments thereto contain information that may be
privileged, confidential or otherwise protected from disclosure and is the
property of SumTotal Systems, LLC It is intended only for the person to
whom it is addressed. If
RE: SSL Issue on the 443 port on tomcat7
-Original Message-
From: Vijay Karthick [mailto:vijaykarthic...@gmail.com]
Sent: Thursday, March 19, 2015 12:11 PM
To: users@tomcat.apache.org
Subject: Fwd: SSL Issue on the 443 port on tomcat7
Hi,
In SAP BO environment, the SSL has been enabled in the Tomcat7 version.
However, the Tomcat is not initializing. Its states that password error.
I've recreated the keystore file. However, we're unable to fix it. Please refer
the Log on the Tomcat folder.
Server.xml :
Connector port=443 protocol=HTTP/1.1 SSLEnabled=true
maxThreads=150 scheme=https secure=true
clientAuth=false sslProtocol=TLS
maxHttpHeaderSize=65536 keystore=D:\SAP
BusinessObjects\Tomcat6\conf\.keystore keypass=Password /
The tomcat logs folder file stderr files give the below log,
2015-03-18 23:10:01 Commons Daemon procrun stderr initialized
Mar 18, 2015 11:10:02 PM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal
performance in production environments was not found on the
java.library.path: C:\Windows\SysWOW64\;D:\SAP BusinessObjects\SAP
BusinessObjects Enterprise XI 4.0\win64_x64\
Mar 18, 2015 11:10:02 PM org.apache.catalina.startup.SetAllPropertiesRule
begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'keystore' to 'D:\SAP BusinessObjects\tomcat\conf\.keystore' did not find a
matching property.
Mar 18, 2015 11:10:02 PM org.apache.catalina.startup.SetAllPropertiesRule
begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'keypass' to 'Password' did not find a matching property.
Mar 18, 2015 11:10:02 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler [http-bio-443]
Mar 18, 2015 11:10:03 PM org.apache.coyote.AbstractProtocol init
SEVERE: Failed to initialize end point associated with ProtocolHandler
[http-bio-443]
java.io.IOException: Keystore was tampered with, or password was incorrect
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:771)
at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:38)
at java.security.KeyStore.load(KeyStore.java:1183)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getStore(JSSESocketFactory.java:407)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeystore(JSSESocketFactory.java:306)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:565)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:505)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.init(JSSESocketFactory.java:449)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket(JSSESocketFactory.java:158)
at org.apache.tomcat.util.net.JIoEndpoint.bind(JIoEndpoint.java:393)
at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:610)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:429)
at
org.apache.coyote.http11.AbstractHttp11JsseProtocol.init(AbstractHttp11JsseProtocol.java:119)
at
org.apache.catalina.connector.Connector.initInternal(Connector.java:981)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at
org.apache.catalina.core.StandardService.initInternal(StandardService.java:559)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:814)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at org.apache.catalina.startup.Catalina.load(Catalina.java:633)
at org.apache.catalina.startup.Catalina.load(Catalina.java:658)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:281)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:450)
Caused by: java.security.UnrecoverableKeyException: Password verification failed
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:769)
... 26 more
--
Vijay
The attributes that you mentioned in the server.xml file should be corrected as
follows
keystore with keystoreFile
keypass with keyPass (P is Capital here)
-Akbar
This message and any attachments thereto contain information that may be
privileged, confidential or otherwise protected from disclosure and is the
property of SumTotal Systems, LLC It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message, any
attachments thereto or any part thereof. If you receive this message in error,
please notify
Re: org.apache.jasper.JasperException: The absolute uri: http://tiles.apache.org/tags-tiles cannot be resolved in either web.xml or the jar files deployed with this application
Hi,
2015-03-19 5:34 GMT+02:00 Thusitha Thilina Dayaratne thusit...@wso2.com:
Hi Chris,
Thanks a lot for the quick response. Please find inline answers.
On 3/18/15 5:39 AM, Thusitha Thilina Dayaratne wrote:
I'm in the process of migrating embedded tomcat 7.0.59 application
to Tomcat 8.0.20. Tomcat is been bundle as a OSGI bundle. First I
get a NullPointerException when trying to access the server home
page. I fixed that manually setting an empty TldCache instance in
the context as follows
[snip]
Now it is not throwing the NPE. but instead of that I'm getting
following exception
org.apache.jasper.JasperException: The absolute uri:
http://tiles.apache.org/tags-tiles cannot be resolved in either
web.xml or the jar files deployed with this application at
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:55)
I
looks like you are missing the Tiles JAR. Is it located in your
WEB-INF/lib directory?
These jar files are located in a folder called plugins. We are reading
them
from our JarScanner
I'm also using a extended JarScanner as follows
public class CarbonTomcatJarScanner extends StandardJarScanner{
Without trying to read and understand all this code, can you explain
why you are using your own JarScanner instead of Tomcat's? Perhaps
there is a way to do this where you don't need to write your own
JarScanner.
According the servlet 3.0 spec, tldScanner classes are picked up
during web-app load phase from
the classPath using SPI mechanism. Normal sequence is to scan;
- WEB-INF/lib
- parent URL classPath
However with the BundleClassLoader being the parent classLoader of
Tomcat web-app classLoder, it fails to pick up
TLD scanner references reside in plugins directory. That is why we
have used a our own JarScanner
It seems that this is relate to JarScanner. Can someone tell me
what I have done wrong here? Or a way to fix this? Is this occur
because I set TldCache manually?
I'm curious as to why the TldCache isn't being set up correctly in the
first place. In your other recent thread (NPE in
JspCompilationContext.getTldResourcePath), there were a couple of
questions from the community that it doesn't look like you have
answered. Perhaps answering those might help you solve both problems
at once.
I'm not so quite sure about that. I manually set the TldCache and manually
added the JasperInitializer to the StandardContext
to get rid of the NPE
I will try to answer the an answered questions in other thread.
You may want to have a look at Eclipse Gemini Web (OSGi Web Container
Reference Implementation)
Regards,
Violeta
Thanks
Best Regards
/Thusitha
Re: Fwd: SSL Issue on the 443 port on tomcat7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Vijay, On 3/19/15 12:11 PM, Vijay Karthick wrote: In SAP BO environment, the SSL has been enabled in the Tomcat7 version. However, the Tomcat is not initializing. Its states that password error. I've recreated the keystore file. However, we're unable to fix it. Please refer the Log on the Tomcat folder. If you have recreated your keystore, you have likely lost the original private key you were intending to use. Don't throw out the old keystore file! And, as others have said, you misspelled your configuration directive. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVCxGqAAoJEBzwKT+lPKRYTB0P/3QrG06d3fPQKcOVMbtxvRoS mK7RFe4mBT1GU6T+NxKYeVgOwEusPMoABKQobCwHCFWSiSxbK9LZHlqKZr+L1Kqs BsT3gaAx5KtsmOIeddUN+tGHAf+lw1FuGbWQGeJd7bHLH3QwzjkFDA3MyT3OmAVz Pq09jbjI4kf233eB8qD4O0FXcaO/crGMCepUZYa1bKl8owq8n9Buw8/qDlpY6PrN 0GsWfFetTD2Wk3IDl+10zIDUChsEVMJL48K6rtpYAeQPmgLZeBTjMDVMJ8k6YPh3 4nno6rHXXStEOjrPGplpktRmTQwSCCY051rJccqKoWKvHziLomRXppQKOpUBohwo 3BwDjwc0iv3XZBzyB4g2bffJIpCwQ2MHkxCLn468npWWFqVKvjWxiCa6P6terpzQ x8WsUPG9cSKkin8BjHUcMGqa174Jd8i8viXc6apVKp2fEqD1BFcyWlLglLhDgIDp p6HQnPFiF3Bm2x0v5rfMW88g6ZV3ZDl+UB6ScUjoImRTrM/XXqDS2i/99PfutrM7 GAQXh/VHeXRRbVy8tBGqxhBHShibN+qxDdj9fRTntYEZnNOJPAHCmNv2ZlPesGem RS6270HOru/f5iFz8gIFC20VmyNg524XZGei4vT08EsQgKPSYA9sdTniV8nfed7R xeWfBU/CwjfqZHL6MNCL =mw5F -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: org.apache.jasper.JasperException: The absolute uri: http://tiles.apache.org/tags-tiles cannot be resolved in either web.xml or the jar files deployed with this application
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Thusitha,
On 3/18/15 11:34 PM, Thusitha Thilina Dayaratne wrote:
Hi Chris,
Thanks a lot for the quick response. Please find inline answers.
On 3/18/15 5:39 AM, Thusitha Thilina Dayaratne wrote:
I'm in the process of migrating embedded tomcat 7.0.59
application to Tomcat 8.0.20. Tomcat is been bundle as a OSGI
bundle. First I get a NullPointerException when trying to
access the server home page. I fixed that manually setting an
empty TldCache instance in the context as follows
[snip]
Now it is not throwing the NPE. but instead of that I'm
getting following exception
org.apache.jasper.JasperException: The absolute uri:
http://tiles.apache.org/tags-tiles cannot be resolved in
either web.xml or the jar files deployed with this application
at
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:55)
I
looks like you are missing the Tiles JAR. Is it located in your
WEB-INF/lib directory?
These jar files are located in a folder called plugins. We are
reading them from our JarScanner
I'm also using a extended JarScanner as follows
public class CarbonTomcatJarScanner extends
StandardJarScanner{
Without trying to read and understand all this code, can you
explain why you are using your own JarScanner instead of
Tomcat's? Perhaps there is a way to do this where you don't need
to write your own JarScanner.
According the servlet 3.0 spec, tldScanner classes are picked up
during web-app load phase from the classPath using SPI mechanism.
Normal sequence is to scan; - WEB-INF/lib - parent URL classPath
However with the BundleClassLoader being the parent classLoader of
Tomcat web-app classLoder, it fails to pick up TLD scanner
references reside in plugins directory. That is why we have used a
our own JarScanner
It seems that this is relate to JarScanner. Can someone tell
me what I have done wrong here? Or a way to fix this? Is this
occur because I set TldCache manually?
I'm curious as to why the TldCache isn't being set up correctly
in the first place. In your other recent thread (NPE in
JspCompilationContext.getTldResourcePath), there were a couple
of questions from the community that it doesn't look like you
have answered. Perhaps answering those might help you solve both
problems at once.
I'm not so quite sure about that. I manually set the TldCache and
manually added the JasperInitializer to the StandardContext to get
rid of the NPE I will try to answer the an answered questions in
other thread.
Well, just because you aren't getting an NPE any longer doesn't mean
that you actually solved the root of the problem. The root of the
problem is that your TLDs aren't being loaded. You just ended up
putting a band-aid on the cache, which is still empty.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVCxIkAAoJEBzwKT+lPKRYHkAP/jFYoFQLJXZZ9sf/+UBo9jEx
oDXHloweXQ7T1V8aVu2ksH9mgzPtofSbYTwjeiQimQsAkUW0rFAcBPCrgsnzrrN6
xJss6aFMLC3aac1+linQaWaeSj4WX3lhbe1lghP0yqN18UxsoTuzUg6JqgQ5fs9w
7bAixbQko9GREJbPuT93IvpEcKx6hKwVre2m8VdkDsaNgELHDSqNykcoGLDOobdX
RKG+tggg1bsOnJ/aDcN75faOwKE7dNtLysi/d4UpgMYRzMcxVo8CT1u2ttTbFeBe
iiBYtdPZ1Fcosa8bLKj71LVFQ79+Id13kY0bxXczBM+SL88N5KEOI0fCqd94ysQq
OIY3Ppr2CTNLHl7zZskSTYtqCUe6TeaP6n+YW3VsxKfjlukJRjnVMjwrWQqqPs5n
SxmDRG7iF1YNXltHntK8pslgjQy69oGCsJiqMt3fhRmsF1Nnm/F/JR1oDYVWSJ3y
AKDa+0+pUqFuJRb4KGXAfi6Q6AXEp613LOX1P8psOg3DbE68CCrXXpuoFU9AGkma
XKr8aLf6MKtvj/aeoK/rTRlCVAPXztzfH4iHQq7zSQbJoSv0xORznszgoEXScYsj
Cs/ufky+hb/DEBVb1hhPLIYUMCMx0xuBn7RD7X7OVzyoS1Onv+zu06hfeAK1MVO/
83f4J5mbTh+myhiHwkXA
=i+Iu
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Java Heap Space / Thread Dump Numbers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Eric, On 3/19/15 11:15 AM, Eric Robinson wrote: Thanks for the feedback. We run various versions of RHEL (5.5 to 6.3) x64. Tomcat is mostly 6.0.18. Java is mostly 6u21 x 64. Time to upgrade. Tomcat is hideously out of date (probably because you are using RedHat's Tomcat package), at least by version number. I'm not sure what RedHat does (if anything) about security fixes, etc. but a vanilla 6.0.18 is probably vulnerable and has been for a very long time. Java 1.6 is EOL and Java 1.7 is getting close. I strongly advise you to move up to Tomcat 8.0.20 and Java 1.8 and start developing and testing your application against those versions. Typical startup options looks like this... JAVA_OPTS=-Xms192M -Xmx384M \ -XX:MaxPermSize=128M \ Those seem reasonable, except maybe not PermGen. Are you increasing it or reducing it from the default on your platform? The memory allocation seems low to you because we run many instances of tomcat on the same server. Although the servers have 32-64GB of RAM, the individual tomcat/java instances are kept fairly low. We ran for years in a 64MiB heap. Then we got enough traffic that sessions required us to expand our heaps. If you can run in a small heap, great. But keep your eye on what's happening with your users; you may find that you have outgrown your old heap settings. We are trying to be proactive by watching the memory usage numbers in the thread dumps. Heap dumps? When we see a number that could be getting too close for comfort, we increase the memory allocation slightly and restart the tomcat. (We can get away with this in production because of the way our load balancing works it does not cause any downtime for clients.) Any thoughts on what numbers we should watch closest? The from space is always mostly used, but that does not appear to cause a problem. http://wiki.apache.org/tomcat/FAQ/Monitoring - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVCxEOAAoJEBzwKT+lPKRYqI0P/iIGZ5NfK5yAxdSlSFoIMQcS alKJqPBCPhEe6mECyBN+KB24Ci8YvJDtdWzMe56BgJ0uUvCKmlfRxO4VTyUhJH+X WxkkRoZ2PylZNtwj9mvs/IFat09nBTVCeUy3e4ZSE4bEN30HHe9MgS3bz+Tyvmbt UCONb+JrjHAFvwcSTACdgJHK62TIACLkJkZ534JshPkaTVIpRqGSgx2OimoAk4k8 Z7K7E8uQlJg65XG+uR7bXHZ+mHGdwL6yT574OGb+FreLW5fraF2LmUzlEsP62ynI 50oUXGEoOUM1LLGNDxmKXrCuKXiuxd2yqC+TbHtfdBlfXwvS3AUMldZ3Q+2ZtDUe xF4v5y25OO4pYoGJp7vQNQGmfWTI6DJ+Ru0vnULnqsMLuBKsIfCsbnB9hV2Fx9e4 8rzIgc1YyuIACFi78Pr1Ot95mBw14C/802a2ypJl+6UCvWZfbU+/CkdhcJ44Mnf7 VyD5beBJJy2Dt0m8lcIxI6vw2Pe2msGLHLLPlu3yhewOc4ii1DIE5gJ2IrXxncLY YaZqG7rq8TDR5y88xdBFkM3gLugZR/v30S82dnt+sTlIOMDyA750poKY7L8BFK+z a7dSRTKpJd1GYqKo0pMsq0YV/PwVmODiCQp6XNLkvyj68Cp3N4fRF4fOZLkhPjJ/ aeVTxYJX97p946/DlHMh =p3WY -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Scan custom directory from JarScanner
Hi Thanks for quick response. Hi, I'm having an extended StandardJarScanner to scan for jar files which are located in a custom location. In tomcat 8 Jar scan filters have been introduced. Is i possible to scan my custom location without extending the StandardJarScanner in Tomcat 8? That is not the correct approach. The Jar scanner is not intended (and probably won't work) to be used to add JARs to your classpath. If you have additional JARs they need to be added to the web application and via WebResources the JarScanner will treat them just like any other application JAR. Since I'm using embedded tomcat as an OSGI bundle, I used extended JarScanner to scan for all the required jars in custom location. These Jars will be used by all other applications. In the [1] it say that we can specify comma separated jar files for tldlibraries and pluggable features. Is it possible to specify a directory rather than separate jars? No. That is a list of file names to use for filtering, not a list of locations to scan. Can I specify absolute paths of Jars that need to be scan here? Thanks Regards /Thusitha On Thu, Mar 19, 2015 at 9:37 PM, Mark Thomas ma...@apache.org wrote: On 19/03/2015 16:00, Thusitha Thilina Dayaratne wrote: Hi, I'm having an extended StandardJarScanner to scan for jar files which are located in a custom location. In tomcat 8 Jar scan filters have been introduced. Is i possible to scan my custom location without extending the StandardJarScanner in Tomcat 8? That is not the correct approach. The Jar scanner is not intended (and probably won't work) to be used to add JARs to your classpath. If you have additional JARs they need to be added to the web application and via WebResources the JarScanner will treat them just like any other application JAR. In the [1] it say that we can specify comma separated jar files for tldlibraries and pluggable features. Is it possible to specify a directory rather than separate jars? No. That is a list of file names to use for filtering, not a list of locations to scan. Mark [1] - http://tomcat.apache.org/tomcat-8.0-doc/config/jar-scan-filter.html Thanks Best Regards /Thusitha - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Thusitha Dayaratne Software Engineer WSO2 Inc. - lean . enterprise . middleware | wso2.com Mobile +94712756809 Blog alokayasoya.blogspot.com Abouthttp://about.me/thusithathilina
Re: Fwd: SSL Issue on the 443 port on tomcat7
On 3/19/2015 12:11 PM, Vijay Karthick wrote:
Hi,
In SAP BO environment, the SSL has been enabled in the Tomcat7 version.
However, the Tomcat is not initializing. Its states that password error.
I've recreated the keystore file. However, we're unable to fix it. Please
refer the Log on the Tomcat folder.
Server.xml :
Connector port=443 protocol=HTTP/1.1 SSLEnabled=true
maxThreads=150 scheme=https secure=true
clientAuth=false sslProtocol=TLS
maxHttpHeaderSize=65536 keystore=D:\SAP
BusinessObjects\Tomcat6\conf\.keystore keypass=Password /
The tomcat logs folder file stderr files give the below log,
2015-03-18 23:10:01 Commons Daemon procrun stderr initialized
Mar 18, 2015 11:10:02 PM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal
performance in production environments was not found on the
java.library.path: C:\Windows\SysWOW64\;D:\SAP BusinessObjects\SAP
BusinessObjects Enterprise XI 4.0\win64_x64\
Mar 18, 2015 11:10:02 PM org.apache.catalina.startup.SetAllPropertiesRule
begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'keystore' to 'D:\SAP BusinessObjects\tomcat\conf\.keystore' did not find a
matching property.
did not find a matching property. is the important point here. That
means it doesn't know what to do with the property called 'keystore'. I
believe these property names are case-sensitive...
Mar 18, 2015 11:10:02 PM org.apache.catalina.startup.SetAllPropertiesRule
begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'keypass' to 'Password' did not find a matching property.
Mar 18, 2015 11:10:02 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler [http-bio-443]
Mar 18, 2015 11:10:03 PM org.apache.coyote.AbstractProtocol init
SEVERE: Failed to initialize end point associated with ProtocolHandler
[http-bio-443]
java.io.IOException: Keystore was tampered with, or password was incorrect
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:771)
at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:38)
at java.security.KeyStore.load(KeyStore.java:1183)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getStore(JSSESocketFactory.java:407)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeystore(JSSESocketFactory.java:306)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:565)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:505)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.init(JSSESocketFactory.java:449)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket(JSSESocketFactory.java:158)
at org.apache.tomcat.util.net.JIoEndpoint.bind(JIoEndpoint.java:393)
at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:610)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:429)
at
org.apache.coyote.http11.AbstractHttp11JsseProtocol.init(AbstractHttp11JsseProtocol.java:119)
at
org.apache.catalina.connector.Connector.initInternal(Connector.java:981)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at
org.apache.catalina.core.StandardService.initInternal(StandardService.java:559)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:814)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at org.apache.catalina.startup.Catalina.load(Catalina.java:633)
at org.apache.catalina.startup.Catalina.load(Catalina.java:658)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:281)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:450)
Caused by: java.security.UnrecoverableKeyException: Password verification
failed
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:769)
... 26 more
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: SSL Issue on the 443 port on tomcat7
-Original Message-
From: Vijay Karthick [mailto:vijaykarthic...@gmail.com]
Sent: Thursday, March 19, 2015 11:11 AM
To: users@tomcat.apache.org
Subject: Fwd: SSL Issue on the 443 port on tomcat7
Hi,
In SAP BO environment, the SSL has been enabled in the Tomcat7 version.
However, the Tomcat is not initializing. Its states that password error.
I've recreated the keystore file. However, we're unable to fix it.
Please
refer the Log on the Tomcat folder.
Server.xml :
Connector port=443 protocol=HTTP/1.1 SSLEnabled=true
maxThreads=150 scheme=https secure=true
clientAuth=false sslProtocol=TLS
maxHttpHeaderSize=65536 keystore=D:\SAP
BusinessObjects\Tomcat6\conf\.keystore keypass=Password /
Please review the documentation on proper Connector configuration.
http://tomcat.apache.org/tomcat-7.0-doc/config/http.html
The tomcat logs folder file stderr files give the below log,
2015-03-18 23:10:01 Commons Daemon procrun stderr initialized
Mar 18, 2015 11:10:02 PM org.apache.catalina.core.AprLifecycleListener
init
INFO: The APR based Apache Tomcat Native library which allows optimal
performance in production environments was not found on the
java.library.path: C:\Windows\SysWOW64\;D:\SAP BusinessObjects\SAP
BusinessObjects Enterprise XI 4.0\win64_x64\
Mar 18, 2015 11:10:02 PM
org.apache.catalina.startup.SetAllPropertiesRule
begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting
property
'keystore' to 'D:\SAP BusinessObjects\tomcat\conf\.keystore' did not
find a
matching property.
Mar 18, 2015 11:10:02 PM
org.apache.catalina.startup.SetAllPropertiesRule
begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting
property
'keypass' to 'Password' did not find a matching property.
Mar 18, 2015 11:10:02 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler [http-bio-443]
Mar 18, 2015 11:10:03 PM org.apache.coyote.AbstractProtocol init
SEVERE: Failed to initialize end point associated with ProtocolHandler
[http-bio-443]
java.io.IOException: Keystore was tampered with, or password was
incorrect
at
sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:771)
at
sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:38)
at java.security.KeyStore.load(KeyStore.java:1183)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getStore(JSSESocketFac
tory.java:407)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeystore(JSSESocket
Factory.java:306)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESoc
ketFactory.java:565)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESoc
ketFactory.java:505)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.init(JSSESocketFactory
.java:449)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket(JSSESocke
tFactory.java:158)
at org.apache.tomcat.util.net.JIoEndpoint.bind(JIoEndpoint.java:393)
at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:6
10)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:429)
at
org.apache.coyote.http11.AbstractHttp11JsseProtocol.init(AbstractHttp11J
sseProtocol.java:119)
at
org.apache.catalina.connector.Connector.initInternal(Connector.java:981)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at
org.apache.catalina.core.StandardService.initInternal(StandardService.ja
va:559)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java
:814)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at org.apache.catalina.startup.Catalina.load(Catalina.java:633)
at org.apache.catalina.startup.Catalina.load(Catalina.java:658)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:281)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:450)
Caused by: java.security.UnrecoverableKeyException: Password
verification
failed
at
sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:769)
... 26 more
--
*Regards,*
Vijay Karthick S
--
*Regards,*
Vijay Karthick S
+91-9597957874
Scan custom directory from JarScanner
Hi, I'm having an extended StandardJarScanner to scan for jar files which are located in a custom location. In tomcat 8 Jar scan filters have been introduced. Is i possible to scan my custom location without extending the StandardJarScanner in Tomcat 8? In the [1] it say that we can specify comma separated jar files for tldlibraries and pluggable features. Is it possible to specify a directory rather than separate jars? [1] - http://tomcat.apache.org/tomcat-8.0-doc/config/jar-scan-filter.html Thanks Best Regards /Thusitha -- Thusitha Dayaratne Software Engineer WSO2 Inc. - lean . enterprise . middleware | wso2.com Mobile +94712756809 Blog alokayasoya.blogspot.com Abouthttp://about.me/thusithathilina
Re: Scan custom directory from JarScanner
On 19/03/2015 16:00, Thusitha Thilina Dayaratne wrote: Hi, I'm having an extended StandardJarScanner to scan for jar files which are located in a custom location. In tomcat 8 Jar scan filters have been introduced. Is i possible to scan my custom location without extending the StandardJarScanner in Tomcat 8? That is not the correct approach. The Jar scanner is not intended (and probably won't work) to be used to add JARs to your classpath. If you have additional JARs they need to be added to the web application and via WebResources the JarScanner will treat them just like any other application JAR. In the [1] it say that we can specify comma separated jar files for tldlibraries and pluggable features. Is it possible to specify a directory rather than separate jars? No. That is a list of file names to use for filtering, not a list of locations to scan. Mark [1] - http://tomcat.apache.org/tomcat-8.0-doc/config/jar-scan-filter.html Thanks Best Regards /Thusitha - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Fwd: SSL Issue on the 443 port on tomcat7
Hi,
In SAP BO environment, the SSL has been enabled in the Tomcat7 version.
However, the Tomcat is not initializing. Its states that password error.
I've recreated the keystore file. However, we're unable to fix it. Please
refer the Log on the Tomcat folder.
Server.xml :
Connector port=443 protocol=HTTP/1.1 SSLEnabled=true
maxThreads=150 scheme=https secure=true
clientAuth=false sslProtocol=TLS
maxHttpHeaderSize=65536 keystore=D:\SAP
BusinessObjects\Tomcat6\conf\.keystore keypass=Password /
The tomcat logs folder file stderr files give the below log,
2015-03-18 23:10:01 Commons Daemon procrun stderr initialized
Mar 18, 2015 11:10:02 PM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal
performance in production environments was not found on the
java.library.path: C:\Windows\SysWOW64\;D:\SAP BusinessObjects\SAP
BusinessObjects Enterprise XI 4.0\win64_x64\
Mar 18, 2015 11:10:02 PM org.apache.catalina.startup.SetAllPropertiesRule
begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'keystore' to 'D:\SAP BusinessObjects\tomcat\conf\.keystore' did not find a
matching property.
Mar 18, 2015 11:10:02 PM org.apache.catalina.startup.SetAllPropertiesRule
begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'keypass' to 'Password' did not find a matching property.
Mar 18, 2015 11:10:02 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler [http-bio-443]
Mar 18, 2015 11:10:03 PM org.apache.coyote.AbstractProtocol init
SEVERE: Failed to initialize end point associated with ProtocolHandler
[http-bio-443]
java.io.IOException: Keystore was tampered with, or password was incorrect
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:771)
at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:38)
at java.security.KeyStore.load(KeyStore.java:1183)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getStore(JSSESocketFactory.java:407)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeystore(JSSESocketFactory.java:306)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:565)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:505)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.init(JSSESocketFactory.java:449)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket(JSSESocketFactory.java:158)
at org.apache.tomcat.util.net.JIoEndpoint.bind(JIoEndpoint.java:393)
at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:610)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:429)
at
org.apache.coyote.http11.AbstractHttp11JsseProtocol.init(AbstractHttp11JsseProtocol.java:119)
at
org.apache.catalina.connector.Connector.initInternal(Connector.java:981)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at
org.apache.catalina.core.StandardService.initInternal(StandardService.java:559)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:814)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at org.apache.catalina.startup.Catalina.load(Catalina.java:633)
at org.apache.catalina.startup.Catalina.load(Catalina.java:658)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:281)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:450)
Caused by: java.security.UnrecoverableKeyException: Password verification
failed
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:769)
... 26 more
--
*Regards,*
Vijay Karthick S
--
*Regards,*
Vijay Karthick S
+91-9597957874
RE: Java Heap Space / Thread Dump Numbers
PSYoungGen total 95808K, used 22323K [0x2aaac377, 0x2aaaca21, 0x2aaaca21) eden space 82432K, 10% used [0x2aaac377,0x2aaac402f7f8,0x2aaac87f) from space 13376K, 99% used [0x2aaac87f,0x2aaac94fd5a8,0x2aaac950) to space 13376K, 0% used [0x2aaac950,0x2aaac950,0x2aaaca21) PSOldGentotal 177792K, used 144800K [0x2aaab621, 0x2aaac0fb, 0x2aaac377) object space 177792K, 81% used [0x2aaab621,0x2aaabef78110,0x2aaac0fb) PSPermGen total 120960K, used 65149K [0x2e21, 0x2aaab583, 0x2aaab621) object space 120960K, 53% used [0x2e21,0x2aaab21af440,0x2aaab583) Which of those lines represents the heap space? Chuck Caldarale wrote: // Actually, all of them. The JVM's heap is not just a simple collection, but is instead a somewhat complex structure designed to facilitate garbage collection. A brief description of the components: eden space - where most objects are born (and most of them die) from-space - where live objects exist after a minor garbage collection to-space - where objects will be copied to during a minor garbage collection old gen object space - where long-lived objects reside perm gen object space - where instances of java.lang.Class reside Normally sized objects are initially created in eden. When eden fills, a minor GC copies most live objects from eden and the from-space into the to-space; objects that have been around a while are instead put into old gen. At the end of the minor GC, the from- (now empty) and to-spaces swap roles. When things get too full, a major GC is initiated, which squeezes out any dead space from the old gen. One exception to the above is allocation of large objects, which are placed immediately into old gen. Your OOME may be due to attempting to allocate something big. Since you didn't provide any information about the JVM version, GC settings, platform you're running on, or what your applications do, it's hard to say whether or not your heap is sized appropriately. However, your total of around 262M is rather small in this age of 64-bit machines with multiple gigabytes of memory. More information (not all of it up to date): http://www.oracle.com/technetwork/java/javase/tech/index-jsp-140228.html // Thanks for the feedback. We run various versions of RHEL (5.5 to 6.3) x64. Tomcat is mostly 6.0.18. Java is mostly 6u21 x 64. Typical startup options looks like this... JAVA_OPTS=-Xms192M -Xmx384M \ -XX:MaxPermSize=128M \ -Djvm=$JVM_ID \ -Djava.awt.headless=true \ -Djava.net.preferIPv4Stack=true \ -Duser.timezone=US/Pacific \ -Xloggc:/alley/site214/tomcat6/logs/gc.log -XX:+PrintGCDateStamps -XX:+PrintGCDetails \ $JPDA_OPTS $JMX_OPTS The memory allocation seems low to you because we run many instances of tomcat on the same server. Although the servers have 32-64GB of RAM, the individual tomcat/java instances are kept fairly low. We are trying to be proactive by watching the memory usage numbers in the thread dumps. When we see a number that could be getting too close for comfort, we increase the memory allocation slightly and restart the tomcat. (We can get away with this in production because of the way our load balancing works it does not cause any downtime for clients.) Any thoughts on what numbers we should watch closest? The from space is always mostly used, but that does not appear to cause a problem. --Eric - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
