Re: Tomcat 5.5: Jre or Jdk?
Hi, AFAIK, Tomcat 5.5 uses the Eclipse compiler, so it does not require a JDK to compile JSPs anymore. However, a JRE comes with only a "client" virtual machine. If you want to run your Tomcat with a "server" virtual machine, you will need a full JDK. The "-server" option usually provides better performance and stability on long running servers, so I would recommend it on a production environment. Cheers, Rodrigo -- --- GRID SYSTEMS, S.A. Rodrigo Ruiz Parc Bit - Edificio 17 Research Coordinator 07121 Palma de Mallorca Baleares - Spain http://www.gridsystems.com/ --- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Server certificate configuration for multiple IP addresses and domain names
Hi all, I have been trying to configure certificates for a server that has several IP addresses, and several domain names, but I think I have reached a limitation on Tomcat security features (or maybe a Java one, I don't know). I think the problem can be experienced even with a server with a single IP address and a single domain address. I would like my server to present a different certificate depending on the address through which it is being invoked. Specifically, I would like my server to present different certificates for the following alternatives: - 127.0.0.1 - host IP address - localhost - host.domain.name - alias.domain.name That is, depending on the address/name the client used to make the request, present an appropriate certificate. I know I can instruct Tomcat to present a different certificate for different IP addresses, but in this case I want it to present different certificates for the same address. I don't know if this is possible with the current Tomcat version, or it is already in the roadmap of Tomcat for a future version, or even if it has been reported. I have searched on this forum archives and into Jira, and found similar questions and bug reports, but not this one. I just wanted to check this subject here before submitting a request for this feature in Bugzilla. Thanks in advance, -- --- GRIDSYSTEMS S.A. Rodrigo Ruiz Parc Bit - Son Espanyol R & D 07120 Palma de Mallorca e-mail : rruiz AT gridsystems DOT com Baleares - España Tel: +34 971 435 085 http://www.gridsystems.com/ Fax: +34 971 435 082 --- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Is it possible to set a timeout for an already open connection?
Hi all, Is there any way to set a timeout for a request that has been already stablished? Currently, I can perform a DoS attack to my tomcat server just by starting enough requests, sending a few bytes in each one, and letting the connections open during a large time. I was wondering if there is any way to prevent such an attack. Regards, Rodrigo Ruiz -- --- GRIDSYSTEMSRodrigo Ruiz Aguayo Parc Bit - Son Espanyol 07120 Palma de Mallorcamailto:[EMAIL PROTECTED] Baleares - España Tel:+34-971435085 Fax:+34-971435082 http://www.gridsystems.com --- -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.2/372 - Release Date: 21/06/2006 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
OT: Are there any alternative keystore implementations out there?
Hi all, I am working on a project that has some feature requirements I have not found in a default Tomcat setup (well, I could be wrong). One of those missing features is the ability to add CA and clientcertificates without restarting the tomcat server. Can APR be configured to search for CA and/or client certificates in a specific path? If APR does not suit, can Coyote be configured to use an custom security provider? Does anybody know about a security provider implementation supporting this feature? Thanks in advance, Rodrigo Ruiz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re:2nd Request: How do you programmatically determine Tomcat Version
Hi Andy, I agree with you. The application version seems to be a relevant information piece. I guess "Catalina/Server" MBean would be a good place. Regards, Rodrigo Ruiz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java.lang.OutOfMemoryError: PermGen space
I guess it does not. Such an action should be considered a responsibility of the web application. Anyway, you could suggest this in the Tomcat bug list as a new feature. Surely, it will not hurt ;-D Regards, Rodrigo Ruiz On 12/23/05, Durfee, Bernard <[EMAIL PROTECTED]> wrote: > > Does Tomcat call releaseAll() when a web-app is undeployed? > > Bernie > >
RE: java.lang.OutOfMemoryError: PermGen space
Mike, The PermGen space is the area where classes, methods and the like are stored. There are two possibilities to the cause of this OutOfMemory: - The best case: the application is simply loading too many classes, and they do not fit in the PermGen space. In this case, it will be enough to increase the PermGen size - The worst case: you are experiencing a problem of class (or classloader) garbage collection. Unfortunately, by your description, it seems to be your case. The problem is that, when you reload the webapp, the JVM is not being able to "garbage collect" the old web-app version. This effect is accumulative, and the more times you reload your webapp, the more space is not being freed in the PermGen space. The cause for this behaviour is that there are strong references that are not being freed when your webapp is stopped. Due to these references, the garbage collector is not able to finalize the referenced classes, or the classloader they where loaded with. This is not really a Tomcat problem, but your webapp's. There are several wide-spread programming patterns that have this effect when used in a webapp. The following are two examples that I usually find in the projects I try to "fix": - The singleton pattern creates a hard reference of the class in the class itself. This makes the class unloadable. I prefer to use the commons-discovery DiscoverSingleton class. By using this class, you can get singleton instances of the classes you need. The advantage is that you can add a ServletContextListener to your webapp, and call its static release() method within contextDestroyed, so all singleton instances are safely released. This library provides more discovery patterns that can be useful in other situations. - It is very common to find a declaration like this: private static final Log log = LogFactory.getLog(MyClass.class); From the commons-logging API documentation: "LogFactory needs to keep a static map of LogFactory objects keyed by context classloader; when the webapp is "undeployed" this means there is still a reference to the undeployed classloader preventing the memory used by all its classes from being reclaimed." If you are using commons-logging, the LogFactory provides the "releaseAll" method, that can be used to release all the internal references, and can also be called from the ServletContextListener.contextDestroyed() method. In fact, the commons-logging documentation itself recommends to use this method in servlet containers ;-) You can also use the org.apache.commons.logging.impl.ServletContextCleaner class. There are other patterns that have the same effects, and they should all be avoided if you want your webapp to be "really" reloadable :-) Perhaps, it would be a good idea to create a section in the Tomcat WIKI to list these patterns, and their workarounds :-) Best Regards (and Happy Christmas!), Rodrigo Ruiz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Singleton memory leak after redeploying.
Hi, I would like to add my two cents :-)
If I know that a class will only be instantiated once or twice, I
usually prefer to declare the logger field as non-static.
I put in this category Stateless Session EJBs, servlets, filters,
listeners, JSPs, and any singleton classes I implement by myself.
Also, on webapps, I tend to use the ServletContext as a singleton
instance container, instead of using the singleton pattern, whenever I
can. The performance is a bit worse, but it can be reduced by storing a
local reference in the classes that access them, and I gain some
benefits too: no need to manually free resources on context
undeployment, and the ability to put those classes on the common or
shared directory of Tomcat, and still have separate instances for each
webapp using them.
I usually create a simple factory class like:
class XXXFactory {
private static XXX singleton = null;
private static Object lock = new Object();
public static XXX getInstance(ServletContext ctx) {
XXX instance;
synchronized (lock) {
if (ctx == null) {
if (singleton == null) singleton = new XXX();
instance = singleton;
} else {
instance = (XXX)ctx.getAttribute(XXX.class.getName());
if (instance == null) {
instance = new XXX();
ctx.setAttribute(XXX.class.getName(), instance);
}
}
}
return instance;
}
}
Another option is to use the commons discovery framework, but sometimes
I just prefer a simpler solution. :-)
HTH,
Rodrigo Ruiz
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
