Re: What is correct for workers.properties.minimal
David Thielen wrote: Hi; First, what use is the load balancing if I have just one server running one instance of Tomcat? Does it load balance within that one instance? Second, what is jkstatus for? Jkstatus is used for displaying and managing load balancers and load balancer members. Since it can manage only the workers that are members of load balancer that simple configuration has been made as an example. If there is a single worker as member of load balancer the performance will be the same, because in that case the entire lb election phases are simply skipped. Of course you have the option to manage your worker at runtime. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK 1.2.15 Release plan?
+0 go for 1.2.15 2005/9/27, Rainer Jung [EMAIL PROTECTED]: I encourage you for voting 1.2.15 as stable. Mladen Turk wrote: Anyhow, I would like that we vote this (1.2.15) version as stable, because it's a bug-fix release over the 1.2.14 stable. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need an option to severe socket connections between mod_jk and ajp connector after request/response cycle.
Please witch over to tomcat-user for discussion. This is not really a developer issue. === My previous comments (bugzilla) === First hints from my side: reduce to equal number of apache and tomcat instances, configure F5 with rule that sends URLs with session cookie or jsessionid in URL to the correct apache. Furthermore configure mod_jk, such that each apache sends requests without sessions to it's preferred tomcat partner. That way almost all apache processes will connect to only one tomcat. If you still need 16K apache processes per instance you are in trouble (maybe upgrade to apache 2), if you manage to handle the workload with 1K apache processes, 1K Threads in Tomcat should be OK. === Additional comments === If you don't want to reuse the connections between apache and tomcat (last ressort solution) switch over to connectors of type ajp12 (they will close the connection after each request-response cycle) or set cachesize to 0 which will use ajp13 protocol, but I think it will close connections after each request too. I hope you don't use HTTP keep alive? Also: I vaguely remember there was an experimental connector/thread pool implementation with asynchroneous features. It might be, that this implementation does not need one fixed thread for each apache connection and I think it is beeing shipped with 5.5.x, but not enabled on default. Concerning this topic tomcat-dev might be the right place to ask. Rainer Remy Gendron wrote: Hi all, Here's the situation as it stands today and what can be done to solve it. I'll try to keep this short. Running configuration: * Running on Linux Red-Hat Ent 3 * 1 X F5 load balancer and hardware SSL box. * 5 X Apache 1.3.33/mod_jk 1.2.14 * 6 X JBoss 4.0.0/Tomcat 5.0.28 using the AJP13 connector. * Oracle 9i Our production environment hosts a number of applications, each with different load and usage patterns. Our problem comes from the fact that it is difficult to find a web farm configuration that will satisfy every application. For reasons I will not explain here, we cannot have a dedicated web farm for each application. This is what we think is happening in our production environment based on tests ran in UAT (User Acceptance Tests) and literature from the Apache and Tomcat products. This is all pretty new to us so if someone can provide hard facts, you are more than welcome. 1. The 1.3 generation of Apache web servers will spawn a child process to handle an HTTP request. Only one HTTP request at a time can be processed by that child. 2. As the load increases on the web server, additional child processes will be spawned to concurrently serve the requests. There is a default limit to how many child processes can be forked. That limit defaults to 256 but has been changed in production to 16384. This is the MaxClients directive. It seems that production really needs the 16384 value instead of the 256 default. With 256, our web servers were rejecting connections and could not support the load generated by all of our clients. 3. To prevent latency, Apache will maintain a maximum of 100 spare child processes alive. Spare means that they are not serving requests. Once reached, that number of spare servers does not seem to decrease. This is the number we see in our tests in UAT where 201 threads remain active in Tomcat. This is the 100 spare children connections * 2 web server plus accept() thread. 4. If a request needs to be forwarded to Tomcat/JBoss (dynamic pages), the child process mod_jk module will instantiate a socket connection to the ajp13 connector in Tomcat. 5. Tomcat will accept the connection and create a thread to serve it. Connections will be accepted up to a concurrent maximum of 1200. This upper value has been set by us. 6. Tomcat will reject connections when the maximum is reached. JBoss 4.0.0 has a known issue where the server will die when the maximum is reached. This has been fixed in 4.0.2. 7. A connection could potentially be recycled in mod_jk (recycle_timeout) if no activity occurs thru the connection. However, any requests to Tomcat from any user session-bound to that Tomcat instance could go thru the connection, thus keeping it active. Recycling does not seem to occur. We use a recycle_timeout value of 300. 8. The fact that the production web servers can potentially serve up to 16384 concurrent requests make it possible for a web server to instantiate an almost infinite number of connections to Tomcat and nuke it. 9. Tomcat can then become overloaded with connections. If a valid HTTP request comes thru Apache and is routed to a child process that has not yet made a connection to Tomcat, the connection could be impossible if Tomcat has already accepted its 1200 limit. 10. In that case, mod_jk could potentially fail over to another Tomcat. The user would however loose his session. 11. The recycle_timeout and cache_size options are of no use to us because too
DO NOT REPLY [Bug 36837] New: - Looking for ProxyHandler implementation of Http request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36837. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36837 Summary: Looking for ProxyHandler implementation of Http request Product: Tomcat 5 Version: Unknown Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Unknown AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] We are looking for the ProxyHandler implementation of HTTP request handler. This will allow us to configure the Tomcat Http server as proxy server and build the application for creating the Http Tunnel This HTTP Tunnel can be used to take over a HTTP connection in order to tunnel another protocol over it -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java
[EMAIL PROTECTED] wrote: +/* + * Clear the IntrospectionUtils cache. + * + * Implementation note: + * Any reference to IntrospectionUtils which may cause the static + * initalizer of that class to be invoked must occur prior to setting + * the started flag to FALSE, because the static initializer of + * IntrospectionUtils makes a call to + * org.apache.commons.logging.LogFactory.getLog(), which ultimately + * calls the loadClass() method of the thread context classloader, + * which is the same as this classloader, whose impl throws a + * ThreadDeath if the started flag has been set to FALSE. + */ +IntrospectionUtils.clear(); + This commit does not make sense to me. The static initializer is called when loading the class, and obviously the webapp CL is not going to load IntrospectionUtils. You should forget that the CVS exists, as we're in the middle of migrating to SVN (of course, losing that commit will not be a problem). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36840] New: - NullPointerException processing Realm in Context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36840. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36840 Summary: NullPointerException processing Realm in Context Product: Tomcat 5 Version: 5.5.9 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I have put a file in $CATALINA_HOME/conf/Catalina/localhost for application context. It reads:- Context Realm classname=org.apache.catalina.realm.JDBCRealm debug=99 driverName=org.postgresql.Driver connectionURL=jdbc:postgresql:authority connectionName=david userTable=users userNameCol=user_name userCredCol=user_pass userRoleTable=roles roleNameCol=role_name /Realm /Context When I try to start Tomcat 5.5.9 (I tried 5.5.12 a well, same result) I get a NullPointerException in Digester, the stack trace from which starts:- 26-Sep-2005 19:20:26 org.apache.tomcat.util.digester.Digester startElement SEVERE: Begin event threw exception java.lang.NullPointerException at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:261) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.apache.tomcat.util.digester.ObjectCreateRule.begin(ObjectCreateRule.java:204) at org.apache.tomcat.util.digester.Rule.begin(Rule.java:152) at org.apache.tomcat.util.digester.Digester.startElement(Digester.java:1275) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:533) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:878) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1693) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242) at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1561) at org.apache.catalina.startup.ContextConfig.processContextConfig(ContextConfig.java:778) at org.apache.catalina.startup.ContextConfig.contextConfig(ContextConfig.java:718) at org.apache.catalina.startup.ContextConfig.init(ContextConfig.java:974) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:273) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.StandardContext.init(StandardContext.java:5015) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3885) If I comment out the Realm bit of the Context it does not crash. Tomcat then complains of an exception processing the default web.xml, which is misleading in the extreem. I have no idea what it is trying to load, but I know that the Realm class is available in a JAR in server/lib and also that the Postgresql driver is in the same directory. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CVS-SVN Schedule
Hi, Any update on the schedule? I have couple of fixes, commits, etc, but IIUC the transition should happen last weekend, so I've postpone all that, but it seems that CVS is still operational. Can somebody make a firm statement on the timings? 1. Until when (Date:Hour:Minute) commits could be done 2. Wen the CVS will be locked for commit (same format) Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java
Remy,
Remy Maucherat wrote On 09/28/05 03:12,:
[EMAIL PROTECTED] wrote:
+/*
+ * Clear the IntrospectionUtils cache.
+ *
+ * Implementation note:
+ * Any reference to IntrospectionUtils which may cause the static
+ * initalizer of that class to be invoked must occur prior to
setting
+ * the started flag to FALSE, because the static initializer of
+ * IntrospectionUtils makes a call to
+ * org.apache.commons.logging.LogFactory.getLog(), which ultimately
+ * calls the loadClass() method of the thread context classloader,
+ * which is the same as this classloader, whose impl throws a
+ * ThreadDeath if the started flag has been set to FALSE.
+ */
+IntrospectionUtils.clear();
+
This commit does not make sense to me. The static initializer is called
when loading the class, and obviously the webapp CL is not going to load
IntrospectionUtils.
This code in IntrospectionUtils.java:
private static org.apache.commons.logging.Log log=
org.apache.commons.logging.LogFactory.getLog(
IntrospectionUtils.class );
will cause LogFactoryImpl.getLogConstructor() to be called, which
in turn will invoke LogFactoryImpl.loadClass(String name), which is
implemented as follows:
private static Class loadClass( final String name )
throws ClassNotFoundException
{
Object result = AccessController.doPrivileged(
new PrivilegedAction() {
public Object run() {
ClassLoader threadCL = getContextClassLoader();
if (threadCL != null) {
try {
return threadCL.loadClass(name);
} catch( ClassNotFoundException ex ) {
// ignore
}
}
try {
return Class.forName( name );
} catch (ClassNotFoundException e) {
return e;
}
}
});
if (result instanceof Class)
return (Class)result;
throw (ClassNotFoundException)result;
}
Notice the use of the thread context classloader (to load the class
with the given name), which is the same as the WebappClassLoader.
WebappClassLoader.loadClass() has this:
// Don't load classes if class loader is stopped
if (!started) {
log.info(sm.getString(webappClassLoader.stopped));
throw new ThreadDeath();
}
We have seen the ThreadDeath in our callstacks, hence this fix.
Jan
You should forget that the CVS exists, as we're in the middle of
migrating to SVN (of course, losing that commit will not be a problem).
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java
Jan Luehe wrote: We have seen the ThreadDeath in our callstacks, hence this fix. Nobody is reading what I am writing anymore ... I wrote: The static initializer is called when loading the class, and obviously the webapp CL is not going to load IntrospectionUtils. IntrospectionUtils will be loaded once, and its static initializer run once. So I am ok with your fix, but I don't understand how it can occur in regular Tomcat. The big comment block is quite pointless, as it tries to be informational, but doesn't correspond to reality (I am personally against this kind of commit message duplication comment). As a reminder, CVS shound't be used anymore. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS-SVN Schedule
Mladen Turk wrote: Hi, Any update on the schedule? I have couple of fixes, commits, etc, but IIUC the transition should happen last weekend, so I've postpone all that, but it seems that CVS is still operational. Can somebody make a firm statement on the timings? 1. Until when (Date:Hour:Minute) commits could be done 2. Wen the CVS will be locked for commit (same format) No, as we are dependent on infrastructure resource to do this. 1 2 will be the same time. The current position is: - we can continue to use CVS - infrastructure will notify us via tomcat-dev when the migration is planned to take place - the first step in the migration will be to lock CVS My advice is to continue to commit to CVS until we find out when the migration will take place. Once we have a time for the migration this gives us our deadline to work to for completing any remaining changes and committing them. Personally, I intend to have any outstanding commits completed well before this time. See the JIRA issue for the full detail (http://issues.apache.org/jira/browse/INFRA-562). Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java
Remy, Remy Maucherat wrote On 09/28/05 10:18,: Jan Luehe wrote: We have seen the ThreadDeath in our callstacks, hence this fix. Nobody is reading what I am writing anymore ... No, I did. I wrote: The static initializer is called when loading the class, and obviously the webapp CL is not going to load IntrospectionUtils. IntrospectionUtils will be loaded once, and its static initializer run once. Yes, but with lazy resolution, it will be loaded when the IntrospectionUtils symbol is first encountered, which may be inside WebappClassLoader.stop(). IntrospectionUtils' static initializer will cause an invocation of loadClass() on the thread's context classloader, which corresponds to the WebappClassLoader, whose loadClass() throws ThreadDeath when its started flag has been set to FALSE. Therefore, we must avoid referencing IntrospectionUtils in WebappClassLoader.stop() after the started flag has been set to FALSE. So I am ok with your fix, but I don't understand how it can occur in regular Tomcat. It's probably not occurring in standalone Tomcat, but only in embedded Tomcat. In standalone Tomcat, IntrospectionUtils is probably getting resolved (and its static initializer invoked) prior to calling WebappClassLoader.stop(), whereas in embedded mode, IntrospectionUtils is first referenced and loaded by WebappClassLoader.stop(). The big comment block is quite pointless, as it tries to be informational, but doesn't correspond to reality (I am personally against this kind of commit message duplication comment). Sure, I just thought this line might be an easy candidate for being moved around if there was no comment. As a reminder, CVS shound't be used anymore. Yes. Jan Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36847] New: - ZipException when using tag in deploy ant task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36847.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36847
Summary: ZipException when using tag in deploy ant task
Product: Tomcat 5
Version: 5.5.9
Platform: Other
OS/Version: other
Status: NEW
Severity: major
Priority: P3
Component: Webapps:Manager
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Exactly similar to bug 34654, I have an identical ZipException when using the
tag attribute while deploying remotely using the ant deploy task. In bug
34654, comment 2, Yoav had mentioned something to the effect that he couldn't
reproduce it and neither could the OP. I don't think the OP in bug 34654 ever
mentioned that he couldn't reproduce it. I don't know why the OP never disputed
that assumption.
I can easily reproduce it by having a deploy ant task with a tag attribute
such as:
deploy url=http://${host}:8080/manager;
username=${tomcat.username}
password=${tomcat.password}
path=/${app.name}
update=true
tag=${tag.war}
war=file:${gen.dir}/war/${webapp.war}/
If I take out the tag attribute, the remote deploy works fine.
This is with tomcat 5.5.9, sun-jdk-1.5.0.03 on a Gentoo Linux machine.
What the OP of bug 34654 was referring to in bug 34654, comment 1 was the fact
that if you look inside the remote hosts' work/Catalina/localhost/manager
directory, you will find a fully intact war file with the properly named
directory (as per the tag). And indeed, the war file in that directory is
complete and does not have any defects and/or corruptions.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36847] - ZipException when using tag in deploy ant task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36847. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36847 --- Additional Comments From [EMAIL PROTECTED] 2005-09-28 22:29 --- (In reply to comment #0) If I take out the tag attribute, the remote deploy works fine. This is with tomcat 5.5.9, sun-jdk-1.5.0.03 on a Gentoo Linux machine. To add some points of reference, this used to work fine in 5.0.28. In addition, I upgraded to 5.5.12 and it is broken in there as well. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java
Jan Luehe wrote: No, I did. Cool, there's one, at least :) Yes, but with lazy resolution, it will be loaded when the IntrospectionUtils symbol is first encountered, which may be inside WebappClassLoader.stop(). Normally, it's used by plenty of things, like the digester. Who knows anyway, I find the classloading behavior to be weird sometimes. So I am ok with your fix, but I don't understand how it can occur in regular Tomcat. It's probably not occurring in standalone Tomcat, but only in embedded Tomcat. In standalone Tomcat, IntrospectionUtils is probably getting resolved (and its static initializer invoked) prior to calling WebappClassLoader.stop(), whereas in embedded mode, IntrospectionUtils is first referenced and loaded by WebappClassLoader.stop(). The big comment block is quite pointless, as it tries to be informational, but doesn't correspond to reality (I am personally against this kind of commit message duplication comment). Sure, I just thought this line might be an easy candidate for being moved around if there was no comment. Stuff won't get moved around for no reason ;) It would actually be good to move the 3 cleanup calls to StandardContext.stop. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36852] New: - Custom Webapp loaders don't correctly honor context's privileged=true attribute
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36852.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36852
Summary: Custom Webapp loaders don't correctly honor context's
privileged=true attribute
Product: Tomcat 5
Version: 5.5.9
Platform: All
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
If you create a context.xml for a webapp and include a nested Loader element
within the Context element and the Context is set to privileged=true, then
the classloaders are not set up correctly and the webapp cannot see any of the
privileged classes (i.e. org.catalina.*) For example, the manager webapp won't
work, giving a NoClassDefFoundError for org.apache.catalina.ContainerServlet
I belive that the XML for the loader element is processed like this in
ContextRuleSet.begin() (around line 251):
// Look up the required parent class loader
ClassLoader parentClassLoader = null;
Object ojb = digester.peek();
if (ojb instanceof Container) {
parentClassLoader = ((Container)ojb).getParentClassLoader();
}
// Instantiate a new Loader implementation object
String className = loaderClass;
if (attributeName != null) {
String value = attributes.getValue(attributeName);
if (value != null)
className = value;
}
Class clazz = Class.forName(className);
Class types[] = { ClassLoader.class };
Object args[] = { parentClassLoader };
Constructor constructor = clazz.getDeclaredConstructor(types);
Loader loader = (Loader) constructor.newInstance(args);
However, this is not retrieving the correct parent classloader for privileged
webapps. See the following code in StandardContext.start() (around line 3950):
if (getLoader() == null) {
ClassLoader parent = null;
if (getPrivileged()) {
if (log.isDebugEnabled())
log.debug(Configuring privileged default Loader);
parent = this.getClass().getClassLoader();
} else {
if (log.isDebugEnabled())
log.debug(Configuring non-privileged default Loader);
parent = getParentClassLoader();
}
WebappLoader webappLoader = new WebappLoader(parent);
webappLoader.setDelegate(getDelegate());
setLoader(webappLoader);
}
In the case where the Loader element was specified, getLoader() will return
non-null and this block will never be entered. However, when that loader was
created in ContextRuleSet, only the non-privileged parent class was used (i.e.
StandardContext.getParentClassLoader()) rather than the privileged classloader
at the appropriate times (i.e. StandardContext.getClass().getClassLoader())
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36853] New: - https
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36853. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36853 Summary: https Product: Tomcat 5 Version: Nightly Build Platform: PC OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Connector:HTTP AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] https connector doesn't work form tomcat5.5.11 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36853] - https
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36853. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36853 --- Additional Comments From [EMAIL PROTECTED] 2005-09-29 03:58 --- Created an attachment (id=16548) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16548action=view) my server config file tomcat 5.5.11 Https connector fails work with this config file,but http://127.0.0.1:449 works correctly! suprising! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup Catalina.java CatalinaProperties.java ContextConfig.java Embedded.java
costin 2005/09/28 22:52:49
Modified:catalina/src/share/org/apache/catalina/startup Catalina.java
CatalinaProperties.java ContextConfig.java
Embedded.java
Log:
Another small commit dealing with the 'single-jar'/minimal case, where we
don't have all the dir structure or fancy startup script.
It defaults catalina.home to user.dir, reads default server.xml and web.xml
out of resources, set the properties to avoid NPE.
Let me know if there is a problem with this - easy to roll back, but
shouldn't hurt any of the existing functionality.
Revision ChangesPath
1.39 +16 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Catalina.java
Index: Catalina.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -r1.38 -r1.39
--- Catalina.java 31 Aug 2005 14:06:40 - 1.38
+++ Catalina.java 29 Sep 2005 05:52:47 - 1.39
@@ -463,6 +463,21 @@
}
}
+// This should be included in catalina.jar
+// Alternative: don't bother with xml, just create it manually.
+if( inputStream==null ) {
+try {
+inputStream = getClass().getClassLoader()
+.getResourceAsStream(server-embed.xml);
+inputSource = new InputSource
+(getClass().getClassLoader()
+.getResource(server-embed.xml).toString());
+} catch (Exception e) {
+;
+}
+}
+
+
if ((inputStream == null) (file != null)) {
log.warn(Can't load server.xml from + file.getAbsolutePath());
return;
1.9 +5 -3
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaProperties.java
Index: CatalinaProperties.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaProperties.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- CatalinaProperties.java 16 Sep 2004 23:19:54 - 1.8
+++ CatalinaProperties.java 29 Sep 2005 05:52:47 - 1.9
@@ -57,7 +57,7 @@
* Return specified property value.
*/
public static String getProperty(String name) {
-
+
return properties.getProperty(name);
}
@@ -126,10 +126,12 @@
if ((is == null) || (error != null)) {
// Do something
log.warn(Failed to load catalina.properties, error);
+ // That's fine - we have reasonable defaults.
+ properties=new Properties();
}
// Register the properties as system properties
-Enumeration enumeration = properties.propertyNames();
+ Enumeration enumeration = properties.propertyNames();
while (enumeration.hasMoreElements()) {
String name = (String) enumeration.nextElement();
String value = properties.getProperty(name);
1.66 +14 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java
Index: ContextConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
retrieving revision 1.65
retrieving revision 1.66
diff -u -r1.65 -r1.66
--- ContextConfig.java21 Jul 2005 21:40:56 - 1.65
+++ ContextConfig.java29 Sep 2005 05:52:47 - 1.66
@@ -589,7 +589,19 @@
source = new InputSource
(getClass().getClassLoader()
.getResource(defaultWebXml).toString());
-} else {
+}
+if( stream== null ) {
+// maybe embedded
+stream = getClass().getClassLoader()
+.getResourceAsStream(web-embed.xml);
+if( stream != null ) {
+source = new InputSource
+(getClass().getClassLoader()
+.getResource(web-embed.xml).toString());
+}
+}
+
+if( stream== null ) {
log.info(No default web.xml);
}
} else {
1.29 +6 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Embedded.java
Index:
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util StringManager.java
costin 2005/09/28 22:55:15
Modified:catalina/src/share/org/apache/catalina/core
AprLifecycleListener.java
catalina/src/share/org/apache/catalina/startup
Bootstrap.java WebRuleSet.java
catalina/src/share/org/apache/catalina/util
StringManager.java
Log:
Remove annoying warnings when compiling with JDK1.5 ( without source=1.3 ),
just casts to the normal params to avoid
conflict with the vararg variants.
Revision ChangesPath
1.4 +3 -3
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/AprLifecycleListener.java
Index: AprLifecycleListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/AprLifecycleListener.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- AprLifecycleListener.java 1 Aug 2005 12:13:59 - 1.3
+++ AprLifecycleListener.java 29 Sep 2005 05:55:14 - 1.4
@@ -101,8 +101,8 @@
try {
String methodName = terminate;
Method method =
Class.forName(org.apache.tomcat.jni.Library)
-.getMethod(methodName, null);
-method.invoke(null, null);
+.getMethod(methodName, (Class [])null);
+method.invoke(null, (Object []) null);
} catch (Throwable t) {
if (!log.isDebugEnabled()) {
log.info(sm.getString(aprListener.aprDestroy));
1.24 +7 -7
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Bootstrap.java
Index: Bootstrap.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- Bootstrap.java15 Sep 2005 06:04:01 - 1.23
+++ Bootstrap.java29 Sep 2005 05:55:14 - 1.24
@@ -271,8 +271,8 @@
throws Exception {
if( catalinaDaemon==null ) init();
-Method method = catalinaDaemon.getClass().getMethod(start, null);
-method.invoke(catalinaDaemon, null);
+Method method = catalinaDaemon.getClass().getMethod(start, (Class
[] )null);
+method.invoke(catalinaDaemon, (Object [])null);
}
@@ -283,8 +283,8 @@
public void stop()
throws Exception {
-Method method = catalinaDaemon.getClass().getMethod(stop, null);
-method.invoke(catalinaDaemon, null);
+Method method = catalinaDaemon.getClass().getMethod(stop, (Class
[] ) null);
+method.invoke(catalinaDaemon, (Object [] ) null);
}
@@ -296,8 +296,8 @@
throws Exception {
Method method =
-catalinaDaemon.getClass().getMethod(stopServer, null);
-method.invoke(catalinaDaemon, null);
+catalinaDaemon.getClass().getMethod(stopServer, (Class [])
null);
+method.invoke(catalinaDaemon, (Object []) null);
}
1.15 +2 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/WebRuleSet.java
Index: WebRuleSet.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/WebRuleSet.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- WebRuleSet.java 26 Jul 2004 16:04:01 - 1.14
+++ WebRuleSet.java 29 Sep 2005 05:55:14 - 1.15
@@ -576,7 +576,7 @@
return;
}
-m.invoke(top, paramValues);
+m.invoke(top, (Object [])paramValues);
if (digester.getLogger().isDebugEnabled())
digester.getLogger().debug( + top.getClass().getName() + .
+ method + ( + paramValues[0] +
));
1.8 +1 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/StringManager.java
Index: StringManager.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/StringManager.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- StringManager.java16 Sep 2004 23:19:54 - 1.7
+++ StringManager.java29 Sep 2005 05:55:15 - 1.8
@@ -101,7 +101,7 @@
* @param key The resource name
*/
public String getString(String key) {
-return MessageFormat.format(getStringInternal(key), null);
+return MessageFormat.format(getStringInternal(key),
