DO NOT REPLY [Bug 41463] - Exception report with IE but not firefox!
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=41463. 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=41463 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |NEEDINFO --- Additional Comments From [EMAIL PROTECTED] 2007-03-27 00:00 --- Could you provide a better test case, ie, a war file or something that will allow us to reproduce it easily? thanks -- 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 41864] - Wrong link on default home page
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=41864. 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=41864 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2007-03-27 00:02 --- This works for me for the index.jsp page -- 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 41530] - stopping a connector produces intermittent SocketException
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=41530. 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=41530 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- 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]
6.0.11 anyone
Any thoughts on a 6.0.11 release? Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41786] - bin/catalina.sh inconsistently references CATALINA_HOME and CATALINA_BASE for logging configuration
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=41786. 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=41786 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- 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 40593] - HttpSessionListener#sessionDestroyed is not called though the manager's pathname is emply.
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=40593. 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=40593 --- Additional Comments From [EMAIL PROTECTED] 2007-03-27 00:29 --- Created an attachment (id=19810) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=19810action=view) tomcat5 patch for StandardContext calling listenerStop() after manager.stop() -- 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 40593] - HttpSessionListener#sessionDestroyed is not called though the manager's pathname is emply.
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=40593. 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=40593 --- Additional Comments From [EMAIL PROTECTED] 2007-03-27 00:31 --- Thanks Peter. I don't have good idea besides calling listenerStop() after manager.stop() same as Tomcat6. It is so simple, but I attached the patch. yuichiro -- 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 39530] - Tomcat 5.5.17 generates incorrect code with trimSpaces turned on.
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=39530. 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=39530 --- Additional Comments From [EMAIL PROTECTED] 2007-03-27 00:48 --- Perhaps no-one's too worried about tuning the output of their JSP's so that network traffic is reduced? Ah...bandwidth -- 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]
Reload web application from web application
I'm searching for a method to reload my web application from within the web app. Like a html-button that trigger something that reloads my web app when the user clicks it. Annyone know a good way to do this? -- View this message in context: http://www.nabble.com/Reload-web-application-from-web-application-tf3471584.html#a9688007 Sent from the Tomcat - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41956] New: - New HTTP connector - The ip address not saved within server.xml
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=41956. 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=41956 Summary: New HTTP connector - The ip address not saved within server.xml Product: Tomcat 5 Version: 5.5.20 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Connector:HTTP AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I can create a new HTTP connector through the administration console but the committing changes do not work - the ip attribute is not save within the server.xml file -- 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 41939] - NPE in Logging due to classloading
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=41939. 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=41939 --- Additional Comments From [EMAIL PROTECTED] 2007-03-27 02:34 --- I have no additional threads running in this application. Besides that, in all applications we manage, the running threads are stopped on destroy(). But neverthelesse: I have started to move JARs around and have now the following situation: Like Robert Weber, I have no Log4J and no commons-logging in the commons/lib or in shared/lib. I have a logging.properties in commons/classes. I have commons-loggings and log4j only ONCE in the webapplication this is tested with. UNloading works fine, as soon as reloading starts, the NPE is thrown. This time it is not even inside the application, but in Tomcat Manager. I guess, that the class in log4j is already distorted. Could it be that tomcat or commons-logging thinks it should use log4j because the classes are found inside the application? -- 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 41849] - Blank page after login on static html page (form authentication)
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=41849. 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=41849 --- Additional Comments From [EMAIL PROTECTED] 2007-03-27 03:10 --- Created an attachment (id=19811) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=19811action=view) White page test case Simple test case (Eclipse project) (the TomcatAthenticator class should be placed in CATALINA_HOME/server/classes/whitepage). -- 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]
svn commit: r522854 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/valves/ExtendedAccessLogValve.java
Author: pero
Date: Tue Mar 27 03:10:45 2007
New Revision: 522854
URL: http://svn.apache.org/viewvc?view=revrev=522854
Log:
Fix that pattern with subtokens ended, are print out subtoken
Example cs(Host) date time cs-uri sc-status x-C(JSESSIONID) time-taken
prints 'localhost:30014' 2007-03-27 10:02:47 /test/ 200
'336C8E8300402846604650DFCE9A6059.tomcat6' 0.001taken
instead 'localhost:30014' 2007-03-27 10:02:47 /test/ 200
'336C8E8300402846604650DFCE9A6059.tomcat6' 0.001
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/valves/ExtendedAccessLogValve.java
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/valves/ExtendedAccessLogValve.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/valves/ExtendedAccessLogValve.java?view=diffrev=522854r1=522853r2=522854
==
---
tomcat/tc6.0.x/trunk/java/org/apache/catalina/valves/ExtendedAccessLogValve.java
(original)
+++
tomcat/tc6.0.x/trunk/java/org/apache/catalina/valves/ExtendedAccessLogValve.java
Tue Mar 27 03:10:45 2007
@@ -403,6 +403,9 @@
}
public String getToken() throws IOException {
+if(ended)
+return null ;
+
String result = null;
subToken = false;
parameter = false;
@@ -462,6 +465,8 @@
}
public String getWhiteSpaces() throws IOException {
+if(isEnded())
+return ;
StringBuffer whiteSpaces = new StringBuffer();
if (buf.length() 0) {
whiteSpaces.append(buf);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41849] - Blank page after login on static html page (form authentication)
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=41849. 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=41849 --- Additional Comments From [EMAIL PROTECTED] 2007-03-27 03:32 --- Created an attachment (id=19812) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=19812action=view) server.xml server.xml used for previous test case -- 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 40593] - HttpSessionListener#sessionDestroyed is not called though the manager's pathname is emply.
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=40593. 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=40593 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2007-03-27 04:39 --- Fix with revision 522870 at tomcat 5.5 trunk. Thanks for your patch. Peter -- 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: 6.0.11 anyone
Filip Hanik - Dev Lists wrote: Any thoughts on a 6.0.11 release? What would be the main motivation for a new release ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41093] - publish 6.0.2 beta jars in a maven repository
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=41093. 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=41093 --- Additional Comments From [EMAIL PROTECTED] 2007-03-27 06:11 --- I opened this bug to facilitate a conversation with Wendy about maven repos before you started publishing to tomcat.apache.org. Now that the jars are available to maven I agree that what you have already provided supersedes what is provided in the patch so this bug can be closed. I'm not sure how to get around the problem you mentioned about PGP signatures. I'll ask our local maven guru and route his feedback to dev @ tomcat. Thanks. -- 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 41530] - stopping a connector produces intermittent SocketException
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=41530. 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=41530 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|VERIFIED -- 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: Annotation processing - Geronimo injection
On Mar 25, 2007, at 7:40 PM, Remy Maucherat wrote: David Jencks wrote: I personally think the AnnotationProcessor is a very questionable idea and hope no one uses it. However, it is pretty common now. The point of the adapter is to show that tomcat can still support people who want to integrate via something like AnnotationProcessor. I certainly don't think tomcat should be using a AnnotationProcessor wrapped in a LifecycleProvider. I was basically trying to show that tomcat could work through an interface like LifecycleProvider, and that it would provide uniformity that is currently lacking, not trying to show a great new implementation of the interface. -- a little history and context -- I work on geronimo, and I started by getting annotation/injection support to work on our app client container and jetty integration, using some ideas I cribbed from OpenEjb and Xbean. With all of these projects it was a really natural fit to have an object creation service that, when given a class name, handed you back a fully baked object. The code tended to get simpler and more straightforward. Then I looked at MyFaces and realized that they could also simplify their code by using an object creation service where you say getLifecycleProvider().newInstance(className); rather than continual repetition of Object o = clazz.newInstance(); getAnnotationProcessor().inject(o); getAnnotationProcessor().postConstruct(o); At this point, I don't like the patch much either. I am not convinced by the proposed API (and the idea of an API change in 6.0.x) which is a bit more intrusive (a LifecycleProvider now would have to be given to Jasper for it to work), and how it is better than the continual (but explicit; quotes because it doesn't exactly happen that often) repetition where it does matter (as far as I can tell, not all the objects that may be instantiated may be annotated). AFAICT the objects that can be annotated are servlets, filters, listeners, and tags. The objects that AFAICT can't be annotated at present (unless jasper annotates some of its base classes, such as with postConstruct methods) are compiled jsps and some kind of object that jasper compiles out of tld files. I'm pretty sure that someone who had more than my 2 days acquaintance with jasper could in a couple of minutes point out how to avoid using LifecycleProvider or AnnotationProcessor on generated classes. I might be mistaken but I'm pretty sure the current code happily does call the AnnotationProcessor on such classes. It's easy enough for jasper to create its own LifecycleProvider if none is supplied, although my current patch has null checks and alternate code for this circumstance. At least one RI in JEE land (JSF) has independently adopted the same AnnotationProcessor interface that is in use in Tomcat. I see you like the LifecycleProvider API better, but are there really things you cannot do (or are hard to do) with the AnnotationProcessor API ? That would be the bar that would have to be cleared IMO to justify a change. Umm, could you explain how the jsf RI is independent? Of what? To me that would mean they had come up with an interface with the same three methods without having seen any examples of it. If you want to count projects on either side of the fence, I got the idea from OpenEjb, geronimo uses this idea, jetty is compatiible with it, and MyFaces has adopted it after starting with the AnnotationProcessor style interface. The AnnotationProcessor style can't support constructor dependency injection or factory methods. These are not envisioned by the specs but there's nothing preventing their support through additional metadata. An object creation service can. However, the main benefit I can see for tomcat is that by swapping which implementation you use at startup, you can specify the policy for object instantiation (such as security sensitve, annotation sensitive, neither, custom.) without any runtime cost. They agreed. Then I looked at Tomcat. I found that there was a lot of attention paid to all sorts of things such as security settings and whether the class was in tomcat for servlets, but no such attention paid for filters or listeners. I wondered if this was an oversight I guess I should Tomcat does not ship security sensitive filters and listeners, but has some funny servlets. For sure I will not want to be performing all these expensive checks for all instantiations, such as tags. That certainly makes sense, but I don't see how it relates to the current code in tomcat. From my reading the code that decides whether to perform the extra security stuff (SecurityUtil.isPackageProtectionEnabled()) doesn't depend on whether the object being instantiated is from the tomcat classloader. Therefore I thought it was reasonable to apply the same checks to all
Re: 6.0.11 anyone
Will it be a 6.0.11 beta or a release ? 2007/3/27, Peter Rossbach [EMAIL PROTECTED]: +1 the NIO Memory leak fix is very important :-) Peter Am 27.03.2007 um 15:45 schrieb Filip Hanik - Dev Lists: Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: Any thoughts on a 6.0.11 release? What would be the main motivation for a new release ? The new Executor Bug fixes Filip 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] - 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: 6.0.11 anyone
Filip Hanik - Dev Lists wrote: The new Executor It's a nice feature, but it's not urgent IMO. I'm not that happy about it since it's slow, too. Bug fixes Ok, but with the latest round of changes you made, I'd rather wait something like one week for some stabilization (the last I've seen is a round of experimental session repl optimizations). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r522931 - /tomcat/connectors/trunk/jni/native/src/network.c
Author: mturk
Date: Tue Mar 27 07:30:06 2007
New Revision: 522931
URL: http://svn.apache.org/viewvc?view=revrev=522931
Log:
On Socket.create create a local pool, because the
Socket.destroy destroys that pool, so the Pool.destroy
fails with crushing VM.
Modified:
tomcat/connectors/trunk/jni/native/src/network.c
Modified: tomcat/connectors/trunk/jni/native/src/network.c
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jni/native/src/network.c?view=diffrev=522931r1=522930r2=522931
==
--- tomcat/connectors/trunk/jni/native/src/network.c (original)
+++ tomcat/connectors/trunk/jni/native/src/network.c Tue Mar 27 07:30:06 2007
@@ -173,6 +173,7 @@
jlong pool)
{
apr_pool_t *p = J2P(pool, apr_pool_t *);
+apr_pool_t *c = NULL;
apr_socket_t *s = NULL;
tcn_socket_t *a = NULL;
apr_int32_t f, t;
@@ -182,19 +183,22 @@
GET_S_FAMILY(f, family);
GET_S_TYPE(t, type);
-a = (tcn_socket_t *)apr_pcalloc(p, sizeof(tcn_socket_t));
+TCN_THROW_IF_ERR(apr_pool_create(c, p), c);
+
+a = (tcn_socket_t *)apr_pcalloc(c, sizeof(tcn_socket_t));
TCN_CHECK_ALLOCATED(a);
-a-pool = p;
-if (family = 0)
-a-net = apr_socket_layer;
-apr_pool_cleanup_register(p, (const void *)a,
- sp_socket_cleanup,
- apr_pool_cleanup_null);
+TCN_THROW_IF_ERR(apr_pool_create(a-child, c), a-child);
+a-pool = c;
if (family = 0) {
+a-net = apr_socket_layer;
TCN_THROW_IF_ERR(apr_socket_create(s,
- f, t, protocol, p), a);
+ f, t, protocol, c), a);
}
+apr_pool_cleanup_register(c, (const void *)a,
+ sp_socket_cleanup,
+ apr_pool_cleanup_null);
+
#ifdef TCN_DO_STATISTICS
sp_created++;
#endif
@@ -202,10 +206,11 @@
if (family = 0)
a-net = apr_socket_layer;
a-opaque = s;
-apr_pool_create(a-child, a-pool);
return P2J(a);
cleanup:
+if (c)
+apr_pool_destroy(c);
return 0;
}
@@ -375,17 +380,18 @@
UNREFERENCED(o);
TCN_ASSERT(sock != 0);
-TCN_THROW_IF_ERR(apr_pool_create(p, s-pool), p);
+TCN_THROW_IF_ERR(apr_pool_create(p, s-child), p);
if (s-net-type == TCN_SOCKET_APR) {
TCN_ASSERT(s-sock != NULL);
a = (tcn_socket_t *)apr_pcalloc(p, sizeof(tcn_socket_t));
TCN_CHECK_ALLOCATED(a);
-a-pool = p;
+TCN_THROW_IF_ERR(apr_socket_accept(n, s-sock, p), n);
+
+a-pool = p;
apr_pool_cleanup_register(s-child, (const void *)a,
sp_socket_cleanup,
apr_pool_cleanup_null);
-TCN_THROW_IF_ERR(apr_socket_accept(n, s-sock, p), n);
}
else {
tcn_ThrowAPRException(e, APR_ENOTIMPL);
@@ -401,6 +407,8 @@
}
return P2J(a);
cleanup:
+if (p)
+apr_pool_destory(p);
return 0;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
David Jencks wrote: compiled jsps If you read the spec literally, they can't be annotated, but this is quite arbitrary IMO (as soon as they're mapped in web.xml, they can). I'm pretty sure that someone who had more than my 2 days acquaintance with jasper could in a couple of minutes point out how to avoid using LifecycleProvider or AnnotationProcessor on generated classes. Hem, that does look difficult to me. Umm, could you explain how the jsf RI is independent? Of what? I meant they came up with the same interface without talking to us. The AnnotationProcessor style can't support constructor dependency injection or factory methods. These are not envisioned by the specs but there's nothing preventing their support through additional metadata. An object creation service can. However, the main benefit I can see for tomcat is that by swapping which implementation you use at startup, you can specify the policy for object instantiation (such as security sensitve, annotation sensitive, neither, custom.) without any runtime cost. Ok. I note the constructor dependency injection (as well as the future proof destructor dependency injection :D). As I said in my email, I am not in favor of the unification of all instantiation checks, as the said checks have a cost and may not be needed (in particular for tags). obvious win-win choice for both tomcat and geronimo. Right now, it's mostly pita-win (it's a significant refactoring) :D You should IMO offer some incentive as part of this to justify the refactoring, such as support for web.xml annotation overrides in standalone Tomcat (as you can see, there's full support for annotations, but not overriding). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41949] - mod_jk 1.2.21 POST JSP Page SSI JSP sub request does not complete
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=41949. 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=41949 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2007-03-27 07:42 --- I checked out mod_jk HEAD from svn, built, installed and tested this bug. I can reproduce this bug using mod_jk HEAD from svn. For me this is a big issue. We had to downgrade production servers back to version 1.2.19 which still contains the recent security vulnerability. -- 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]
svn commit: r522954 - /tomcat/connectors/trunk/jni/native/src/network.c
Author: mturk Date: Tue Mar 27 08:23:27 2007 New Revision: 522954 URL: http://svn.apache.org/viewvc?view=revrev=522954 Log: Fix typo Modified: tomcat/connectors/trunk/jni/native/src/network.c Modified: tomcat/connectors/trunk/jni/native/src/network.c URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jni/native/src/network.c?view=diffrev=522954r1=522953r2=522954 == --- tomcat/connectors/trunk/jni/native/src/network.c (original) +++ tomcat/connectors/trunk/jni/native/src/network.c Tue Mar 27 08:23:27 2007 @@ -408,7 +408,7 @@ return P2J(a); cleanup: if (p) -apr_pool_destory(p); +apr_pool_destroy(p); return 0; } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41949] - mod_jk 1.2.21 POST JSP Page SSI JSP sub request does not complete
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=41949. 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=41949 --- Additional Comments From [EMAIL PROTECTED] 2007-03-27 08:46 --- Created an attachment (id=19817) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=19817action=view) mod_jk debug output Debug output from mod_jk exhibiting this bug. Not that mod_jk hangs, the last line in the debug output is where it hangs. I have sanitized the debug output to obfuscate hostnames and IP addresses. -- 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]
svn commit: r522964 - in /tomcat/tc6.0.x/trunk/java/org/apache/jasper: compiler/JspUtil.java compiler/ParserController.java xmlparser/XMLEncodingDetector.java
Author: remm
Date: Tue Mar 27 08:53:15 2007
New Revision: 522964
URL: http://svn.apache.org/viewvc?view=revrev=522964
Log:
- Skip BOM when reading a JSP.
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/JspUtil.java
tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/ParserController.java
tomcat/tc6.0.x/trunk/java/org/apache/jasper/xmlparser/XMLEncodingDetector.java
Modified: tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/JspUtil.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/JspUtil.java?view=diffrev=522964r1=522963r2=522964
==
--- tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/JspUtil.java (original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/JspUtil.java Tue Mar
27 08:53:15 2007
@@ -1034,21 +1034,32 @@
}
static InputStreamReader getReader(String fname, String encoding,
- JarFile jarFile,
- JspCompilationContext ctxt,
- ErrorDispatcher err)
-throws JasperException, IOException {
+JarFile jarFile,
+JspCompilationContext ctxt,
+ErrorDispatcher err)
+throws JasperException, IOException {
-InputStreamReader reader = null;
-InputStream in = getInputStream(fname, jarFile, ctxt, err);
+return getReader(fname, encoding, jarFile, ctxt, err, 0);
+}
+
+static InputStreamReader getReader(String fname, String encoding,
+JarFile jarFile,
+JspCompilationContext ctxt,
+ErrorDispatcher err, int skip)
+throws JasperException, IOException {
-try {
+InputStreamReader reader = null;
+InputStream in = getInputStream(fname, jarFile, ctxt, err);
+for (int i = 0; i skip; i++) {
+in.read();
+}
+try {
reader = new InputStreamReader(in, encoding);
-} catch (UnsupportedEncodingException ex) {
-err.jspError(jsp.error.unsupported.encoding, encoding);
-}
+} catch (UnsupportedEncodingException ex) {
+err.jspError(jsp.error.unsupported.encoding, encoding);
+}
-return reader;
+return reader;
}
/**
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/ParserController.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/ParserController.java?view=diffrev=522964r1=522963r2=522964
==
--- tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/ParserController.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/ParserController.java
Tue Mar 27 08:53:15 2007
@@ -62,6 +62,7 @@
private boolean isEncodingSpecifiedInProlog;
private boolean isBomPresent;
+private int skip;
private String sourceEnc;
@@ -208,7 +209,7 @@
InputStreamReader inStreamReader = null;
try {
inStreamReader = JspUtil.getReader(absFileName, sourceEnc,
-jarFile, ctxt, err);
+jarFile, ctxt, err, skip);
JspReader jspReader = new JspReader(ctxt, absFileName,
sourceEnc, inStreamReader,
err);
@@ -314,6 +315,7 @@
if (((Boolean) ret[2]).booleanValue()) {
isBomPresent = true;
}
+skip = ((Integer) ret[3]).intValue();
if (!isXml sourceEnc.equals(UTF-8)) {
/*
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/jasper/xmlparser/XMLEncodingDetector.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/jasper/xmlparser/XMLEncodingDetector.java?view=diffrev=522964r1=522963r2=522964
==
---
tomcat/tc6.0.x/trunk/java/org/apache/jasper/xmlparser/XMLEncodingDetector.java
(original)
+++
tomcat/tc6.0.x/trunk/java/org/apache/jasper/xmlparser/XMLEncodingDetector.java
Tue Mar 27 08:53:15 2007
@@ -44,6 +44,7 @@
private String encoding;
private boolean isEncodingSetInProlog;
private boolean isBomPresent;
+private int skip;
private Boolean isBigEndian;
private Reader reader;
@@ -122,8 +123,9 @@
scanXMLDecl();
return new Object[] { this.encoding,
- new Boolean(this.isEncodingSetInProlog),
- new Boolean(this.isBomPresent) };
+ Boolean.valueOf(this.isEncodingSetInProlog),
+ Boolean.valueOf(this.isBomPresent),
+ Integer.valueOf(this.skip) };
}
// stub method
@@ -149,10 +151,13 @@
Object [] encodingDesc = getEncodingName(b4, count);
DO NOT REPLY [Bug 41949] - mod_jk 1.2.21 POST JSP Page SSI JSP sub request does not complete
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=41949. 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=41949 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2007-03-27 08:55 --- It works for me. Please do not reopen the issue unless you give the reproducale case. I used your files, and it simply works! ApacheRoot/test/html: html head titleTest POST/title /head body p mod_jk JSP Post Test /p form method=post action=/test1.jsp input type=submit name=test /form /body /html /ROOT/test1.jsp: %@ page session=false % pThis is test1.jsp/p !--#include virtual=/test2.jsp -- /ROOT/test2.jsp %@ page session=false % p This is test2.jsp /p JkMount /*.jsp ajp13w Mod_jk.log: [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (868): Connected socket 740 to (127.0.0.1:8009) [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (914): sending to ajp13 pos=4 len=476 max=8192 [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (914): 12 34 01 D8 02 02 00 08 49 4E 43 4C 55 44 45 44 - .4..INCLUDED [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (914): 001000 00 0A 2F 74 65 73 74 32 2E 6A 73 70 00 00 09 - .../test2.jsp... [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (914): 002031 32 37 2E 30 2E 30 2E 31 00 FF FF 00 09 6C 6F - 127.0.0.1.lo [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (914): 003063 61 6C 68 6F 73 74 00 1F 90 00 00 0B A0 0B 00 - calhost. [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (914): 00400E 6C 6F 63 61 6C 68 6F 73 74 3A 38 30 30 30 00 - .localhost:8000. [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (914): 0050A0 0E 00 5A 4D 6F 7A 69 6C 6C 61 2F 35 2E 30 20 - ...ZMozilla/5.0. [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (914): 006028 57 69 6E 64 6F 77 73 3B 20 55 3B 20 57 69 6E - (Windows;.U;.Win [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (914): 007064 6F 77 73 20 4E 54 20 35 2E 31 3B 20 65 6E 2D - dows.NT.5.1;.en- [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (914): 008047 42 3B 20 72 76 3A 31 2E 38 2E 31 2E 33 29 20 - GB;.rv:1.8.1.3). [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (914): 009047 65 63 6B 6F 2F 32 30 30 37 30 33 30 39 20 46 - Gecko/20070309.F [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (914): 00a069 72 65 66 6F 78 2F 32 2E 30 2E 30 2E 33 00 A0 - irefox/2.0.0.3.. [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (914): 00b001 00 63 74 65 78 74 2F 78 6D 6C 2C 61 70 70 6C - ..ctext/xml,appl [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (914): 00c069 63 61 74 69 6F 6E 2F 78 6D 6C 2C 61 70 70 6C - ication/xml,appl [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (914): 00d069 63 61 74 69 6F 6E 2F 78 68 74 6D 6C 2B 78 6D - ication/xhtml+xm [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (914): 00e06C 2C 74 65 78 74 2F 68 74 6D 6C 3B 71 3D 30 2E - l,text/html;q=0. [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (914): 00f039 2C 74 65 78 74 2F 70 6C 61 69 6E 3B 71 3D 30 - 9,text/plain;q=0 [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (914): 01002E 38 2C 69 6D 61 67 65 2F 70 6E 67 2C 2A 2F 2A - .8,image/png,*/* [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (914): 01103B 71 3D 30 2E 35 00 A0 04 00 0E 65 6E 2D 67 62 - ;q=0.5.en-gb [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (914): 01202C 65 6E 3B 71 3D 30 2E 35 00 A0 03 00 0C 67 7A - ,en;q=0.5.gz [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (914): 013069 70 2C 64 65 66 6C 61 74 65 00 A0 02 00 1E 49 - ip,deflate.I [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (914): 014053 4F 2D 38 38 35 39 2D 31 2C 75 74 66 2D 38 3B - SO-8859-1,utf-8; [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (914): 015071 3D 30 2E 37 2C 2A 3B 71 3D 30 2E 37 00 00 0A - q=0.7,*;q=0.7... [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (914): 01604B 65 65 70 2D 41 6C 69 76 65 00 00 03 33 30 30 - Keep-Alive...300 [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (914): 017000 A0 06 00 0A 6B 65 65 70 2D 61 6C 69 76 65 00 - .keep-alive. [Tue Mar 27 07:10:13 2007] [2404:3512] [debug] jk_ajp_common.c (914): 0180A0 0D 00 1F 68 74
Maximum 8K packet size in mod_jk
Hi list, I'm not sure if you'd prefer this to go to the user list, but I think it probably belongs here, so I'll start here. We have an application that is occasionally bumping into the 8K max packet size of mod_jk, which causes our users to get a Request Entity Too Large page. I find the following in the logs: Mon Mar 26 11:27:54 2007] [9849:] [error ajp_marshal_into_msgb::jk_ajp_common.c (441): failed appending the auth type The exact thing that it fails to append differs at times, but it's obvious that the reason is because the browser is sending more than 8K of data in the request. I started to look at the mod_jk code and it seems that the 8K limit ends up being governed by the DEF_BUFFER_SZ constant which is (8 * 1024). 6 bytes are used for non-payload protocol stuff, so that ends up meaning that the protocol allows for 8186 bytes of payload in a given request. I gathered that the protocol defines the bytes at index 2 and 3 of the packet as a length specifier. This value is stored as two unsigned char values, so the true protocol limit of a given packet should be 65536 bytes (65530 bytes of payload). I'm wondering why the 8K limit was implemented, and I'm also wondering if there's any reason it can't be changed. A quick glance makes it look like this would be as simple as redifining DEF_BUFFER_SZ. I'm going to spend more time looking at the code today so I can get a better understanding of how it works overall, but I'd like to get an expert opinion on the matter. Thoughts? Thanks, Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41949] - mod_jk 1.2.21 POST JSP Page SSI JSP sub request does not complete
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=41949. 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=41949 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2007-03-27 09:30 --- Yes it works for you. But you do not even list what OS/apache/tomcat versions you are using. Just because you have not been able to reproduce it yet does not mean that there is not a bug with mod_jk on the OS/apache/Tomcat I am using. Closing the bug as works for me seems a bit premature. You may recall that I was the release manager for mod_jk several years ago. I wouldn't have posted this bug report unless I was really seeing a bug. The reason I posted it was so that those who have been working on mod_jk since version 1.2.19 might consider what changes they made which would cause this bug in 1.2.21. -- 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 41949] - mod_jk 1.2.21 POST JSP Page SSI JSP sub request does not complete
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=41949. 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=41949 --- Additional Comments From [EMAIL PROTECTED] 2007-03-27 10:12 --- Well, you should then know as well that the pure fact that you said 'it doesn't work' doesn't qualify as a legitimate bug. I tried, and it works (Apache 2.0.59, Tomcat 5.5.20), so you can turn on JkLogLevel to debug, hit the page and send the log file. Without that it might be Tomcat 4.1, Apache, what ever... I won't mark again this as 'WORKFORSOME', but if you don't provide a log files, how can anyone detect the problem? Regards. -- 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: 6.0.11 anyone
Remy Maucherat wrote: The new Executor It's a nice feature, but it's not urgent IMO. I'm not that happy about it since it's slow, too. Bug fixes Ok, but with the latest round of changes you made, I'd rather wait something like one week for some stabilization (the last I've seen is a round of experimental session repl optimizations). Sure, a week or so would be good. I just wanted to put 6.0.11 on the timetable, and yes, I forgot the NIO memory leak, big one. Filip 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 41949] - mod_jk 1.2.21 POST JSP Page SSI JSP sub request does not complete
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=41949. 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=41949 --- Additional Comments From [EMAIL PROTECTED] 2007-03-27 11:16 --- The mod_jk log debug output was attached to this bug earlier today, see comment #3 for this bug report. Here is a link to the debug output: See http://issues.apache.org/bugzilla/attachment.cgi?id=19817 The first thing I listed in my initial bug report was the software versions being used. I will repost: FreeBSD 6.0-RELEASE-p4 apache-2.0.59 mod_jk 1.2.21 Tomcat 4.1.30 -- 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: Maximum 8K packet size in mod_jk
This is no longer the case, get the latest version and you should be able to configure the packet size Filip Dave McMurtrie wrote: Hi list, I'm not sure if you'd prefer this to go to the user list, but I think it probably belongs here, so I'll start here. We have an application that is occasionally bumping into the 8K max packet size of mod_jk, which causes our users to get a Request Entity Too Large page. I find the following in the logs: Mon Mar 26 11:27:54 2007] [9849:] [error ajp_marshal_into_msgb::jk_ajp_common.c (441): failed appending the auth type The exact thing that it fails to append differs at times, but it's obvious that the reason is because the browser is sending more than 8K of data in the request. I started to look at the mod_jk code and it seems that the 8K limit ends up being governed by the DEF_BUFFER_SZ constant which is (8 * 1024). 6 bytes are used for non-payload protocol stuff, so that ends up meaning that the protocol allows for 8186 bytes of payload in a given request. I gathered that the protocol defines the bytes at index 2 and 3 of the packet as a length specifier. This value is stored as two unsigned char values, so the true protocol limit of a given packet should be 65536 bytes (65530 bytes of payload). I'm wondering why the 8K limit was implemented, and I'm also wondering if there's any reason it can't be changed. A quick glance makes it look like this would be as simple as redifining DEF_BUFFER_SZ. I'm going to spend more time looking at the code today so I can get a better understanding of how it works overall, but I'd like to get an expert opinion on the matter. Thoughts? Thanks, Dave - 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]
svn commit: r523024 - /tomcat/connectors/trunk/jni/native/src/network.c
Author: mturk
Date: Tue Mar 27 11:23:06 2007
New Revision: 523024
URL: http://svn.apache.org/viewvc?view=revrev=523024
Log:
Fix accept pool cleanup and destroy in case accept fails because of parent pool
destroy
Modified:
tomcat/connectors/trunk/jni/native/src/network.c
Modified: tomcat/connectors/trunk/jni/native/src/network.c
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jni/native/src/network.c?view=diffrev=523024r1=523023r2=523024
==
--- tomcat/connectors/trunk/jni/native/src/network.c (original)
+++ tomcat/connectors/trunk/jni/native/src/network.c Tue Mar 27 11:23:06 2007
@@ -218,17 +218,18 @@
TCN_IMPLEMENT_CALL(void, Socket, destroy)(TCN_STDARGS, jlong sock)
{
tcn_socket_t *s = J2P(sock, tcn_socket_t *);
+apr_socket_t *as;
UNREFERENCED_STDARGS;
TCN_ASSERT(sock != 0);
+as = s-sock;
+s-sock = NULL;
apr_pool_cleanup_kill(s-pool, s, sp_socket_cleanup);
if (s-net s-net-cleanup) {
(*s-net-cleanup)(s-opaque);
s-net = NULL;
}
-if (s-sock) {
-apr_socket_t *as = s-sock;
-s-sock = NULL;
+if (as) {
apr_socket_close(as);
}
@@ -284,9 +285,12 @@
{
tcn_socket_t *s = J2P(sock, tcn_socket_t *);
jint rv = APR_SUCCESS;
+apr_socket_t *as;
UNREFERENCED_STDARGS;
TCN_ASSERT(sock != 0);
+as = s-sock;
+s-sock = NULL;
apr_pool_cleanup_kill(s-pool, s, sp_socket_cleanup);
if (s-child) {
apr_pool_clear(s-child);
@@ -298,9 +302,7 @@
rv = (*s-net-close)(s-opaque);
s-net = NULL;
}
-if (s-sock) {
-apr_socket_t *as = s-sock;
-s-sock = NULL;
+if (as) {
rv = (jint)apr_socket_close(as);
}
return rv;
@@ -347,7 +349,7 @@
a = (tcn_socket_t *)apr_pcalloc(p, sizeof(tcn_socket_t));
TCN_CHECK_ALLOCATED(a);
a-pool = p;
-apr_pool_cleanup_register(p, (const void *)a,
+apr_pool_cleanup_register(a-pool, (const void *)a,
sp_socket_cleanup,
apr_pool_cleanup_null);
@@ -388,7 +390,7 @@
TCN_THROW_IF_ERR(apr_socket_accept(n, s-sock, p), n);
a-pool = p;
-apr_pool_cleanup_register(s-child, (const void *)a,
+apr_pool_cleanup_register(a-pool, (const void *)a,
sp_socket_cleanup,
apr_pool_cleanup_null);
@@ -407,7 +409,7 @@
}
return P2J(a);
cleanup:
-if (p)
+if (p s-sock)
apr_pool_destroy(p);
return 0;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maximum 8K packet size in mod_jk
Filip Hanik - Dev Lists wrote: This is no longer the case, get the latest version and you should be able to configure the packet size I guess I can't ask for much better than that. Thanks for saving me a ton of wasted time! Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41949] - mod_jk 1.2.21 POST JSP Page SSI JSP sub request does not complete
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=41949. 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=41949 --- Additional Comments From [EMAIL PROTECTED] 2007-03-27 11:32 --- What is the /test/dhetest.jsp You explained that it's needed test.html test1.jsp test2.jsp Can you attach all the test files for ROOT context? -- 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 41949] - mod_jk 1.2.21 POST JSP Page SSI JSP sub request does not complete
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=41949. 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=41949 --- Additional Comments From [EMAIL PROTECTED] 2007-03-27 12:04 --- Created an attachment (id=19819) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=19819action=view) Test WAR file for JSP POST SSI bug Here is a simple war file which can be used to exhibit the bug. This assumes the context is named test. One more note, in my config the webapp context is aliased into apache so apache can server static files, i.e. the test.shtml page. Only the JSP pages are forwarded to tomcat using mod_jk. -- 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 41949] - mod_jk 1.2.21 POST JSP Page SSI JSP sub request does not complete
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=41949. 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=41949 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2007-03-27 12:59 --- It breaks on Tomcat 4.1.30 on my side as well. However 5.5.x works as expected, so I suppose we have some protocol error in mod_jk. -- 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 41853] - Servlet init method invoked twice in 5.5.20
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=41853. 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=41853 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2007-03-27 13:34 --- This was not a bug but a misconfiguration caused by my failure to be aware of the defaults for deployOnStartup and autoDeploy. This is my corrected Host element Host name=localhost appBase=webapps deployOnStartup=false autoDeploy=false Context path= docBase=builder.war/ /Host These other combinations resulted in a double servlet startup when tomcat was started, deployOnStartup=true autoDeploy=true deployOnStartup=false autoDeploy=true deployOnStartup=true autoDeploy=false -- 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: 6.0.11 anyone
oh, and can we have the JULI with support for commons-logging built as part of the standard build? if, yes, then I will be happy to do it Filip Filip Hanik - Dev Lists wrote: Remy Maucherat wrote: The new Executor It's a nice feature, but it's not urgent IMO. I'm not that happy about it since it's slow, too. Bug fixes Ok, but with the latest round of changes you made, I'd rather wait something like one week for some stabilization (the last I've seen is a round of experimental session repl optimizations). Sure, a week or so would be good. I just wanted to put 6.0.11 on the timetable, and yes, I forgot the NIO memory leak, big one. Filip 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41949] - mod_jk 1.2.21 POST JSP Page SSI JSP sub request does not complete
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=41949. 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=41949 --- Additional Comments From [EMAIL PROTECTED] 2007-03-27 14:13 --- Thanks for testing with 4.1.30 and verifying the bug. -- 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: 6.0.11 anyone
Filip Hanik - Dev Lists wrote: oh, and can we have the JULI with support for commons-logging built as part of the standard build? if, yes, then I will be happy to do it IMO, no. I'd like to keep a no dependencies, no nonsense build :) I don't see any need to use log4j for Tomcat logging anyway, unless you like running into problems. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 6.0.11 anyone
Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: oh, and can we have the JULI with support for commons-logging built as part of the standard build? if, yes, then I will be happy to do it IMO, no. I'd like to keep a no dependencies, no nonsense build :) I don't see any need to use log4j for Tomcat logging anyway, unless you like running into problems. it's more about being able to publish all our packages consistently. For example, Geronimo, needs to be able to have a unified logging system, and they do, commons logging. And right now, since those packages are not part of an official release, I can't publish that JAR unless I do it manually. I'd like to be able to publish the actual JAR out of the release. That doesn't mean that the JAR has to be in the lib directory, all I'm asking is that it is generated during our releases Filip 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: 6.0.11 anyone
Filip Hanik - Dev Lists wrote: That doesn't mean that the JAR has to be in the lib directory, all I'm asking is that it is generated during our releases I don't see any problem then. Since it is generated during the releases if you type ant -f extras.xml, it should be possible for the RM to release these extra binaries (at least the binaries which may be legally shipped, or are practical to ship) along with the regular packages. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41128] - Reference to java Thread name from RequestProcessor mbean
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=41128. 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=41128 --- Additional Comments From [EMAIL PROTECTED] 2007-03-27 17:11 --- Created an attachment (id=19820) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=19820action=view) patch against the current http://svn.apache.org/repos/asf/tomcat/current/tc5.5.x -- 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 41128] - Reference to java Thread name from RequestProcessor mbean
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=41128. 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=41128 --- Additional Comments From [EMAIL PROTECTED] 2007-03-27 17:12 --- Created an attachment (id=19821) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=19821action=view) patch against the current http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk -- 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 41128] - Reference to java Thread name from RequestProcessor mbean
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=41128. 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=41128 --- Additional Comments From [EMAIL PROTECTED] 2007-03-27 17:13 --- Gladly :) The patches are attached. Both patches worked ok for me. I didn't know how Tomcat exposed request-related MBeans until today so please forgive me if i missed anything. -- 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: 6.0.11 anyone
Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: That doesn't mean that the JAR has to be in the lib directory, all I'm asking is that it is generated during our releases I don't see any problem then. Since it is generated during the releases if you type ant -f extras.xml, it should be possible for the RM to release these extra binaries (at least the binaries which may be legally shipped, or are practical to ship) along with the regular packages. yes, this is what I was hoping for. Makes my life so much easier. Filip 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]
svn commit: r523135 - in /tomcat: connectors/trunk/coyote/src/java/org/apache/coyote/RequestInfo.java container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/CoyoteAdapter.java
Author: fhanik
Date: Tue Mar 27 18:36:22 2007
New Revision: 523135
URL: http://svn.apache.org/viewvc?view=revrev=523135
Log:
Enhancement request-bugzilla
http://issues.apache.org/bugzilla/show_bug.cgi?id=41128
Ability to track execution thread in the RequestInfo object for management
purposes
Patch submitted by Vlad Ilyushchenko
Modified:
tomcat/connectors/trunk/coyote/src/java/org/apache/coyote/RequestInfo.java
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/CoyoteAdapter.java
Modified:
tomcat/connectors/trunk/coyote/src/java/org/apache/coyote/RequestInfo.java
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/coyote/src/java/org/apache/coyote/RequestInfo.java?view=diffrev=523135r1=523134r2=523135
==
--- tomcat/connectors/trunk/coyote/src/java/org/apache/coyote/RequestInfo.java
(original)
+++ tomcat/connectors/trunk/coyote/src/java/org/apache/coyote/RequestInfo.java
Tue Mar 27 18:36:22 2007
@@ -44,14 +44,14 @@
public RequestGroupInfo getGlobalProcessor() {
return global;
}
-
+
public void setGlobalProcessor(RequestGroupInfo global) {
if( global != null) {
this.global=global;
global.addRequestProcessor( this );
} else {
if (this.global != null) {
-this.global.removeRequestProcessor( this );
+this.global.removeRequestProcessor( this );
this.global = null;
}
}
@@ -62,6 +62,7 @@
Request req;
Response res;
int stage = Constants.STAGE_NEW;
+String workerThreadName;
// Information about the current request ---
// This is usefull for long-running requests only
@@ -212,5 +213,11 @@
this.errorCount = errorCount;
}
+public String getWorkerThreadName() {
+return workerThreadName;
+}
+public void setWorkerThreadName(String workerThreadName) {
+this.workerThreadName = workerThreadName;
+}
}
Modified:
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/CoyoteAdapter.java
URL:
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/CoyoteAdapter.java?view=diffrev=523135r1=523134r2=523135
==
---
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/CoyoteAdapter.java
(original)
+++
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/CoyoteAdapter.java
Tue Mar 27 18:36:22 2007
@@ -143,7 +143,7 @@
}
try {
-
+
req.getRequestProcessor().setWorkerThreadName(Thread.currentThread().getName());
// Parse and set Catalina and configuration specific
// request parameters
if ( postParseRequest(req, request, res, response) ) {
@@ -159,6 +159,7 @@
} catch (Throwable t) {
log.error(sm.getString(coyoteAdapter.service), t);
} finally {
+req.getRequestProcessor().setWorkerThreadName(null);
// Recycle the wrapper request and response
request.recycle();
response.recycle();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Annotation processing - Geronimo injection
On Mar 27, 2007, at 10:39 AM, Remy Maucherat wrote: David Jencks wrote: compiled jsps If you read the spec literally, they can't be annotated, but this is quite arbitrary IMO (as soon as they're mapped in web.xml, they can). Doh! Of course you're right. I just haven't seen a jsp with any java code in it for a while :-). This could be a challenge for deployment unless you've precompiled your jsps I'll have to think about this. I'm pretty sure that someone who had more than my 2 days acquaintance with jasper could in a couple of minutes point out how to avoid using LifecycleProvider or AnnotationProcessor on generated classes. Hem, that does look difficult to me. Umm, could you explain how the jsf RI is independent? Of what? I meant they came up with the same interface without talking to us. The AnnotationProcessor style can't support constructor dependency injection or factory methods. These are not envisioned by the specs but there's nothing preventing their support through additional metadata. An object creation service can. However, the main benefit I can see for tomcat is that by swapping which implementation you use at startup, you can specify the policy for object instantiation (such as security sensitve, annotation sensitive, neither, custom.) without any runtime cost. Ok. I note the constructor dependency injection (as well as the future proof destructor dependency injection :D). As I said in my email, I am not in favor of the unification of all instantiation checks, as the said checks have a cost and may not be needed (in particular for tags). Maybe I haven't been explaining my thinking very well. I suspect that for a very large percentage of web apps, the expensive checks are completely unnecessary even for servlets. Furthermore AFAICT its pretty easy to tell whether or not an app is going to need them before you start constructing servlets and other components. So, if the app doesn't need the fancy stuff, you can supply it with a LifecycleProvider that doesn't do any. If it does, you can supply it with one that does do the checks. Furthermore, there's no reason jasper and tomcat have to be using the same LifecycleProvider at the same time. Jasper can get one free of checks, tomcat can have one that refuses to load any classes :-). I still don't understand the point behind the fancy classloading code or why you insist that it should only apply to servlets. Is there some other code or documentation I could look at that might help explain your point of view? obvious win-win choice for both tomcat and geronimo. Right now, it's mostly pita-win (it's a significant refactoring) :D You should IMO offer some incentive as part of this to justify the refactoring, such as support for web.xml annotation overrides in standalone Tomcat (as you can see, there's full support for annotations, but not overriding). i'll look into this... although I don't see the code involved as being very connected to what I've been proposing. thanks david jencks 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: 6.0.11 anyone
On Tue, 2007-03-27 at 23:22 +0200, Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: oh, and can we have the JULI with support for commons-logging built as part of the standard build? if, yes, then I will be happy to do it IMO, no. I'd like to keep a no dependencies, no nonsense build :) Please and thank you. Tomcat 6.0.x build system and reduced dependencies is greatly appreciated, and IMHO a step in the right direction. Not saying not to bundle the stuff, just saying please keep deps to a minimum and no nonsense build ++ =) -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: 6.0.11 anyone
On Tue, 2007-03-27 at 17:45 -0600, Filip Hanik - Dev Lists wrote: Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: oh, and can we have the JULI with support for commons-logging built as part of the standard build? if, yes, then I will be happy to do it IMO, no. I'd like to keep a no dependencies, no nonsense build :) I don't see any need to use log4j for Tomcat logging anyway, unless you like running into problems. it's more about being able to publish all our packages consistently. That is understandable. For example, Geronimo, needs to be able to have a unified logging system, and they do, commons logging. And right now, since those packages are not part of an official release, I can't publish that JAR unless I do it manually. I'd like to be able to publish the actual JAR out of the release. IMHO and pretty much the Gentoo Linux Java philosophy is bundled stuff is bad. FOSS Java apps tend to do it more than others. Please consider a slightly different viewpoint. But surely not trying to debate, or etc. Anytime deps are bundled as part of a release, you are locked into that version. If there are bug fixes and other releases. They don't tend to make it into other applications. Take Netbeans for example, current 5.5 version ships with a now outdated version of Tomcat 5.5, I believe 5.5.17, might be 5.5.20. Can't recall exactly. Just to be clear either way, current addition of commons-logging won't make much difference for us on Gentoo. Why? Because we install once instance of a given library, app or etc. We then provide all apps using that library, symbolic links to it said jar file or etc. Providing it's API/ABI etc compliant with other dependencies. If dependencies are fixed on a particular version. We slot it and allow for multiple instances to be installed. In Tomcat sense we install one version of Tomcat that say can be used with either Netbeans or Eclipse, in place of any version being shipped. ( Although not sure if eclipse plugins or etc ship tc, I know they have issues when tc is split via C_HOME/C_BASE as we do on Gentoo ) This allows for easier management. Say in this case, commons-logging has a new release. As it's package and updated it's updated for all applications using that slot. Now one might thing manually fetching a dep to be bad. (On Gentoo it's automated) However that also allows end user to make a choice on version to use. If it's been some time past primary app release, in this case Tomcat. Then it's possible what ever version they ship at the time is newer than the bundled version say in a previous Tomcat release. For a further example take Tomcat's jasper-jdt.jar or should I really call it by it's real name, Eclipse JDT. Or at least some of it. Which I can understand slimming the package down to all that is necessary. But that also means future updates to Eclipse JDT won't make it into Tomcat. On Gentoo, I might end up replacing that file with a symlink. For I am letting the build system do it's thing and repackage what it needs. So again not trying to really change the direction or debate this. Just providing a different view point. I can also understand our solution is quite limited to operating systems that allow for symbolic links. Then again from another point of view, could be more that allow for symbolic links than not ;) But in the end bundled stuff is bad IMHO. If it can be avoided it should be, and manually fetching deps is not a bad thing. Definitely when it's not pertinent to the application. But only a subset that might run on the application and want things available about of convenience. Consistency again I can understand, but does that mean things have to be consistent forever and not subject to change? Anyway, just some food for thought. Sorry for length, and hijacking thread topic a bit. Just felt it was kinda a good time to mention it all, since the discussion was along similar lines. Thanks for your time :) -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
DO NOT REPLY [Bug 41430] - JkOptions +ForwardDirectories with Apache's DirectoryIndex
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=41430. 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=41430 --- Additional Comments From [EMAIL PROTECTED] 2007-03-27 22:05 --- Any update on this one? Having same problem here with mod_jk-1.1.21 -- 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 41949] - mod_jk 1.2.21 POST JSP Page SSI JSP sub request does not complete
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=41949. 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=41949 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2007-03-27 23:19 --- Hi, This is a Tomcat 4.1.30 (and 4.1.31) bug Mod_jk fix is here: http://issues.apache.org/bugzilla/show_bug.cgi?id=41610 and the commit is here: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c?r1=502560r2=507923diff_format=h So mod_jk send Content-Length twice, once if present and other with Content-Length: 0. Since it was the later one that counted we always had Content-Length: 0. I have tested with 4.1.34 and it works like expected, so if you wish browse for the fix on Java side. If you need further discussion, address this @dev. -- 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]
