svn commit: r441427 - in /tomcat/connectors/trunk/jk/native/common: jk_shm.h jk_status.c
Author: mturk
Date: Fri Sep 8 01:25:41 2006
New Revision: 441427
URL: http://svn.apache.org/viewvc?view=revrev=441427
Log:
Log client caused errors separately from server
related errors.
Modified:
tomcat/connectors/trunk/jk/native/common/jk_shm.h
tomcat/connectors/trunk/jk/native/common/jk_status.c
Modified: tomcat/connectors/trunk/jk/native/common/jk_shm.h
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_shm.h?view=diffrev=441427r1=441426r2=441427
==
--- tomcat/connectors/trunk/jk/native/common/jk_shm.h (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_shm.h Fri Sep 8 01:25:41 2006
@@ -106,6 +106,8 @@
volatile jk_uint32_t recoveries;
/* Number of recovery failures */
volatile jk_uint32_t recovery_errors;
+/* Number of client errors */
+volatile jk_uint32_t client_errors;
};
typedef struct jk_shm_worker jk_shm_worker_t;
Modified: tomcat/connectors/trunk/jk/native/common/jk_status.c
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_status.c?view=diffrev=441427r1=441426r2=441427
==
--- tomcat/connectors/trunk/jk/native/common/jk_status.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_status.c Fri Sep 8 01:25:41
2006
@@ -443,7 +443,7 @@
jk_puts(s, /tr\n/table\nbr/\n);
jk_puts(s, tabletr
thName/ththType/ththjvmRoute/ththHost/ththAddr/th
-
thAct/ththStat/ththD/ththF/ththM/ththV/ththAcc/ththErr/th
+
thAct/ththStat/ththD/ththF/ththM/ththV/ththAcc/ththErr/ththCE/th
thWr/ththRd/ththBusy/ththMax/ththRR/ththCd/ththRs/th/tr\n);
for (j = 0; j lb-num_of_workers; j++) {
worker_record_t *wr = (lb-lb_workers[j]);
@@ -468,6 +468,7 @@
jk_printf(s, td% JK_UINT64_T_FMT /td, wr-s-lb_value);
jk_printf(s, td% JK_UINT64_T_FMT /td, wr-s-elected);
jk_printf(s, td% JK_UINT32_T_FMT /td, wr-s-errors);
+jk_printf(s, td% JK_UINT32_T_FMT /td,
wr-s-client_errors);
jk_putv(s, td, status_strfsize(wr-s-transferred, buf),
/td, NULL);
jk_putv(s, td, status_strfsize(wr-s-readed, buf),
@@ -601,6 +602,7 @@
trthV/thtdLoad Balancer value/td/tr\n
trthAcc/thtdNumber of requests/td/tr\n
trthErr/thtdNumber of failed requests/td/tr\n
+trthCE/thtdNumber of client errors/td/tr\n
trthWr/thtdNumber of bytes transferred/min/td/tr\n
trthRd/thtdNumber of bytes read/min/td/tr\n
trthBusy/thtdCurrent number of busy
connections/td/tr\n
@@ -674,6 +676,7 @@
jk_printf(s, lbvalue=\% JK_UINT64_T_FMT \, wr-s-lb_value);
jk_printf(s, elected=\% JK_UINT64_T_FMT \, wr-s-elected);
jk_printf(s, errors=\% JK_UINT32_T_FMT \, wr-s-errors);
+jk_printf(s, clienterrors=\% JK_UINT32_T_FMT \,
wr-s-client_errors);
jk_printf(s, transferred=\% JK_UINT64_T_FMT \,
wr-s-transferred);
jk_printf(s, readed=\% JK_UINT64_T_FMT \, wr-s-readed);
jk_printf(s, busy=\%u\, wr-s-busy);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r441436 - /tomcat/connectors/trunk/jk/xdocs/changelog.xml
Author: mturk Date: Fri Sep 8 01:37:04 2006 New Revision: 441436 URL: http://svn.apache.org/viewvc?view=revrev=441436 Log: Document forced recovery. Modified: tomcat/connectors/trunk/jk/xdocs/changelog.xml Modified: tomcat/connectors/trunk/jk/xdocs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/changelog.xml?view=diffrev=441436r1=441435r2=441436 == --- tomcat/connectors/trunk/jk/xdocs/changelog.xml (original) +++ tomcat/connectors/trunk/jk/xdocs/changelog.xml Fri Sep 8 01:37:04 2006 @@ -26,6 +26,13 @@ subsection name=Native changelog update + Add feature to force the recovery of workers that are + member of loadbalancer if all the members are in error + state. This fixes the time gap where 503 was returned + caused by recovery_timeout although the backend was + ready to handle the requests. (mturk) + /update + update Docs: Seperate deprecated directives in their own table. (rjung) /update update - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal - Comet changes
Filip Hanik - Dev Lists wrote: No, I don't see how filters can work. It is possible that some filters which would be wrapping the request would be ok, but most likely they would do something when the call returns (and finish what they had to do), so any attempt to use the wrapped objects would fail later on. The same developer that does the comet servlet sets up the mapping for the filter, so I don't see a need to have to protect against this scenario. This is not practical. 4. For interception, I think the existing valves and filters could/should remain untouched. Interception will/should only be done at the activation of the request Sequential event method (such as READ) would not go through the interceptors, just like it is today. This is essential as we can have filters/valves that modify both incoming and outgoing content. Actually, I would like to have a new type of filters (both for the container side and the application side), because things like setting up the security contexts, etc, are still likely going to be needed. This would be something simpler than valves/filters, with no mapping (since most likely, a single servlet is all that's needed to handle all the Comet traffic of an application). The filter would have a filterEvent method, and the difference between the application side and the container side is that the first gets the facades, and the second the Request and Response objects (which allow access to everything). Each request should be un/wrapping as a regular filter on each invocation (of course, the wrappers can be stored in a request attribute). I see this as a duplicate effort, trying to recreate something that already exist, here are the cons 1. The developers would have to learn something new, tomcat specific to achieve the same thing that they could have done using filters 2. They would work the same way as filters, then why not use filters 3. They run into the same risk as you described above, ie, invalidating an object at request end, can happen here as well 4. Assuming that there would be only *one* comet servlet per application is not a safe assumption, I would never code it that way. 5. You lose the mapping feature, this is extremely useful, and could prove to be very useful for comet servlets as well 6. Everyone already knows how a filter works, and they are implementing a servlet, makes sense to just piggy back this functionality. This does not make sense. They do not work the same way as regular filters, as every event will be intercepted, so this does not duplicate existing functionality. As for mapping, it can be done too if needed, but I think it is not that useful. The problem for example is for a JEE server, to restore the security association for the thread which is processing the IO event. This can't be done otherwise since each event is sent using a different thread. So for example, the Comet servlet would not be able to access an EJB, a transaction, etc. 1) Yes. Different IO style, new API. If they can write the servlet, then that new filter is easier. How is that difficult ? 2) Because filters intercept the call to the service method, which is not going to occur. 3) In that case, they will not be able to code the Comet servlet either. Not my problem. 4) Ok. Well, it's about the same anyway. Valves (which have no mapping) work fine too, and I think mapping can be added later on if it turns out it was really needed (especially since mapping will be done only once per connection, it seems very practical). Personally, I would think the most realistic model (given it is not trivial) is to have one servlet take care of whatever XML protocol has been chosen, and then delegate to actual business logic somewhere else (= not in the servlet). That's why I think one servlet makes some sense. 5) You said it already. It's still something compared with a non existent interception model. 6) For starters, people would need to be told what they should do to write filters that would not break with Comet, and then find out that they're very limited (you can do access logging, though; oh, and compression, but you need to be smart ;) ). 5. StandardCometEvent could be a zero GC object if need be, if the SecurityManager is enabled, a non reusable facade should be used GC doesn't matter too much for the whole connection since it's quite long running. These objects would be discarded when the Comet connection ends (but it would be a bit bad to start allocating too many objects for each event). agreed. 6. CometServlet removal - good idea. 7. The servlet should have a way of gracefully ending the session, such as CometEvent.close() instead of just letting it timeout The servlet can close the writer or OS, and the client could send the appropriate end chunk, this should work. that is how it is today, I think its cleaner to provide them with the CometEvent.close() method and let the container handle the
DO NOT REPLY [Bug 40440] - Problem with characters when include static html
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=40440. 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=40440 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | --- Additional Comments From [EMAIL PROTECTED] 2006-09-08 10:48 --- but the problem still exist when I use [EMAIL PROTECTED] file=/included.htm % In case of using jsp:include... fileEncoding parameter fixed the problem but no t for [EMAIL PROTECTED] -- 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 39704] - context with privileged=true do not setup properly inner loaders
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=39704. 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=39704 --- Additional Comments From [EMAIL PROTECTED] 2006-09-08 10:52 --- Great. Thanks for the confirmation. -- 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 40440] - Problem with characters when include static html
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=40440. 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=40440 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-09-08 10:55 --- You need to set the fileEncoding on the DefaultServlet Bugzilla is not a support forum. Please address further questions to the users list. -- 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 40440] - Problem with characters when include static html
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=40440. 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=40440 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2006-09-08 11:01 --- i know that it is not the forum but I set fileEncoding on the DefaultServlet and when i use Request time include action the characters are ok but when I use Translation time include then there is still problem with incorrect characters. -- 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: Tomcat 5.5.19 Beta build is complete
Hi Filip and Mladen
is it correct that wrong tc native version is inside
build.properties.default ?
# - Tomcat native library -
tomcat-native.home=${base.path}/tomcat-native-1.1.3
tomcat-native.tar.gz=${tomcat-native.home}/tomcat-native.tar.gz
tomcat-native.loc=${base-tomcat.loc}/tomcat-connectors/native/tomcat-
native-1.1.3.tar.gz
Tcnative 1.1.4 can be found at:
http://tomcat.heanet.ie/native/1.1.4/source/
but missing at
http://archive.apache.org/dist/tomcat/tomcat-connectors/native/
Regards
Peter
Am 08.09.2006 um 05:01 schrieb Filip Hanik - Dev Lists:
http://people.apache.org/~fhanik/v5.5.19-beta/
I will run through the TCK tests tomorrow
Filip
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.19 Beta build is complete
Peter Rossbach wrote:
Hi Filip and Mladen
is it correct that wrong tc native version is inside
build.properties.default ?
# - Tomcat native library -
tomcat-native.home=${base.path}/tomcat-native-1.1.3
tomcat-native.tar.gz=${tomcat-native.home}/tomcat-native.tar.gz
tomcat-native.loc=${base-tomcat.loc}/tomcat-connectors/native/tomcat-native-1.1.3.tar.gz
Tcnative 1.1.4 can be found at:
http://tomcat.heanet.ie/native/1.1.4/source/
but missing at
http://archive.apache.org/dist/tomcat/tomcat-connectors/native/
Oops. The update is far from critical, but however Mladen bumped up the
required version number in the listener (note: please don't do that
unless there's an API breakage), so it won't fly.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r441484 - in /tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status: JkBalancerMember.java JkStatusParser.java JkStatusTask.java JkStatusUpdateTask.java
Author: pero
Date: Fri Sep 8 05:23:50 2006
New Revision: 441484
URL: http://svn.apache.org/viewvc?view=revrev=441484
Log:
Add new mod_jk 1.2.19 status and update attributes.
Modified:
tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/JkBalancerMember.java
tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/JkStatusParser.java
tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/JkStatusTask.java
tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/JkStatusUpdateTask.java
Modified:
tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/JkBalancerMember.java
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/JkBalancerMember.java?view=diffrev=441484r1=441483r2=441484
==
---
tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/JkBalancerMember.java
(original)
+++
tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/JkBalancerMember.java
Fri Sep 8 05:23:50 2006
@@ -22,12 +22,19 @@
* @version $Revision:$ $Date:$
* @see org.apache.jk.status.JkStatusParser
*/
+/**
+ * @author peter
+ *
+ */
public class JkBalancerMember implements Serializable {
int id;
String name;
+/* possible with 1.2.16 */
+String jvm_route;
+
String type;
String host;
@@ -36,12 +43,22 @@
String address;
+/* deprecated with mod_jk 1.2.16*/
String status;
+
+/* possible with 1.2.16 */
+String activation;
+/* possible with 1.2.16 */
+String state;
+
int lbfactor;
long lbvalue;
+/* possible with 1.2.16 */
+long lbmult = -1 ;
+
int elected;
long readed;
@@ -50,12 +67,36 @@
long errors;
+long clienterrors = -1;
+
int busy;
-
+
+/* possible with 1.2.16 */
+int maxbusy = -1;
+
String redirect;
String domain;
+/* possible with 1.2.16 */
+int distance = -1;
+
+/**
+ * @return Returns the jvm_route.
+ * @since mod_jk 1.2.19
+ */
+public String getJvm_route() {
+return jvm_route;
+}
+
+/**
+ * @param jvm_route The jvm_route to set.
+ * @since mod_jk 1.2.19
+ */
+public void setJvm_route(String jvm_route) {
+this.jvm_route = jvm_route;
+}
+
/**
* @return Returns the address.
*/
@@ -86,6 +127,23 @@
this.busy = busy;
}
+
+/**
+ * @return Returns the maxbusy.
+ * @since mod_jk 1.2.18
+ */
+public int getMaxbusy() {
+return maxbusy;
+}
+
+/**
+ * @param maxbusy The maxbusy to set.
+ * @since mod_jk 1.2.18
+ */
+public void setMaxbusy(int maxbusy) {
+this.maxbusy = maxbusy;
+}
+
/**
* @return Returns the elected.
*/
@@ -102,6 +160,22 @@
}
/**
+ * @return Returns the clienterrors.
+ * @since mod_jk 1.2.19
+ */
+public long getClienterrors() {
+return clienterrors;
+}
+
+/**
+ * @param clienterrors The clienterrors to set.
+ * @since mod_jk 1.2.19
+ */
+public void setClienterrors(long clienterrors) {
+this.clienterrors = clienterrors;
+}
+
+/**
* @return Returns the errors.
*/
public long getErrors() {
@@ -175,6 +249,22 @@
public void setLbvalue(long lbvalue) {
this.lbvalue = lbvalue;
}
+
+/**
+ * @return Returns the lbmult.
+ * @since mod_jk 1.2.19
+ */
+public long getLbmult() {
+return lbmult;
+}
+
+/**
+ * @param lbmult The lbmult to set.
+ * @since mod_jk 1.2.19
+ */
+public void setLbmult(long lbmult) {
+this.lbmult = lbmult;
+}
/**
* @return Returns the name.
@@ -191,6 +281,7 @@
this.name = name;
}
+
/**
* @return Returns the port.
*/
@@ -223,6 +314,7 @@
/**
* @return Returns the status.
+ * @deprecated since 1.2.16
*/
public String getStatus() {
return status;
@@ -231,12 +323,45 @@
/**
* @param status
*The status to set.
+ * @deprecated since 1.2.16
*/
public void setStatus(String status) {
this.status = status;
}
/**
+ * @return Returns the activation.
+ * @since mod_jk 1.2.19
+ */
+public String getActivation() {
+return activation;
+}
+
+/**
+ * @param activation The activation to set.
+ * @since mod_jk 1.2.19
+ */
+public void setActivation(String activation) {
+this.activation = activation;
+}
+
+/**
+ * @return Returns the state.
+ * @since mod_jk 1.2.19
+ */
+public String getState() {
+return state;
+}
+
+/**
+ * @param state The state to set.
+ * @since mod_jk 1.2.19
+ */
+public
Re: Proposal - Comet changes
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
No, I don't see how filters can work. It is possible that some
filters which would be wrapping the request would be ok, but most
likely they would do something when the call returns (and finish
what they had to do), so any attempt to use the wrapped objects
would fail later on.
The same developer that does the comet servlet sets up the mapping
for the filter, so I don't see a need to have to protect against this
scenario.
This is not practical.
4. For interception, I think the existing valves and filters
could/should remain untouched. Interception will/should only be
done at the activation of the request
Sequential event method (such as READ) would not go through the
interceptors, just like it is today. This is essential as we can
have filters/valves that modify both incoming and outgoing content.
Actually, I would like to have a new type of filters (both for the
container side and the application side), because things like
setting up the security contexts, etc, are still likely going to be
needed. This would be something simpler than valves/filters, with no
mapping (since most likely, a single servlet is all that's needed to
handle all the Comet traffic of an application).
The filter would have a filterEvent method, and the difference
between the application side and the container side is that the
first gets the facades, and the second the Request and Response
objects (which allow access to everything). Each request should be
un/wrapping as a regular filter on each invocation (of course, the
wrappers can be stored in a request attribute).
I see this as a duplicate effort, trying to recreate something that
already exist, here are the cons
1. The developers would have to learn something new, tomcat specific
to achieve the same thing that they could have done using filters
2. They would work the same way as filters, then why not use filters
3. They run into the same risk as you described above, ie,
invalidating an object at request end, can happen here as well
4. Assuming that there would be only *one* comet servlet per
application is not a safe assumption, I would never code it that way.
5. You lose the mapping feature, this is extremely useful, and could
prove to be very useful for comet servlets as well
6. Everyone already knows how a filter works, and they are
implementing a servlet, makes sense to just piggy back this
functionality.
This does not make sense. They do not work the same way as regular
filters, as every event will be intercepted, so this does not
duplicate existing functionality. As for mapping, it can be done too
if needed, but I think it is not that useful.
The problem for example is for a JEE server, to restore the security
association for the thread which is processing the IO event. This
can't be done otherwise since each event is sent using a different
thread. So for example, the Comet servlet would not be able to access
an EJB, a transaction, etc.
1) Yes. Different IO style, new API. If they can write the servlet,
then that new filter is easier. How is that difficult ?
2) Because filters intercept the call to the service method, which
is not going to occur.
3) In that case, they will not be able to code the Comet servlet
either. Not my problem.
4) Ok. Well, it's about the same anyway. Valves (which have no
mapping) work fine too, and I think mapping can be added later on if
it turns out it was really needed (especially since mapping will be
done only once per connection, it seems very practical). Personally, I
would think the most realistic model (given it is not trivial) is to
have one servlet take care of whatever XML protocol has been chosen,
and then delegate to actual business logic somewhere else (= not in
the servlet). That's why I think one servlet makes some sense.
5) You said it already. It's still something compared with a non
existent interception model.
6) For starters, people would need to be told what they should do to
write filters that would not break with Comet, and then find out that
they're very limited (you can do access logging, though; oh, and
compression, but you need to be smart ;) ).
head is clearing up...how about...
since:
public class MyServlet implements HttpServlet, o.a.c.CometProcessor {
wouldn't it make sense for:
public class MyFilter implements Filter, o.a.c.CometFilter {
and you'd declare it the same way, since we are piggy backing on the
servlet logic to create Comet servlets, wouldn't it be smart to piggy
back on the filter logic to create Comet filters?
the interface CometFilter would define the new application chain, ie
void event(CometEvent,CometFilterChain)
achieves the new filter chain, piggy backs on mapping logic.
Filip
5. StandardCometEvent could be a zero GC object if need be, if the
SecurityManager is enabled, a non reusable facade should be used
GC doesn't matter too much for the whole
svn commit: r441489 - /tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/package.html
Author: pero Date: Fri Sep 8 06:00:24 2006 New Revision: 441489 URL: http://svn.apache.org/viewvc?view=revrev=441489 Log: correct wrong link Modified: tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/package.html Modified: tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/package.html URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/package.html?view=diffrev=441489r1=441488r2=441489 == --- tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/package.html (original) +++ tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/package.html Fri Sep 8 06:00:24 2006 @@ -4,7 +4,7 @@ emAnt (version 1.6.x or later)/em that can be used to interact with the Apaache mod_jk status page to show, update, disable and stop mod_jk worker. For more information, see -a href=http://jakarta.apache.org/tomcat/connectors-doc/index.html;strongJK Documenation/strong/a./p +a href=http://tomcat.apache.org/connectors-doc/index.html;strongJK Documenation/strong/a./p pThe attributes of each task element correspond exactly to the request parameters that are included with an HTTP request - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 40160] - Webdav Context path must be /*
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=40160.
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=40160
--- Additional Comments From [EMAIL PROTECTED] 2006-09-08 13:42 ---
This is actually a Micorosft problem, and it is du to the implementation of the
MS Client, which requests some information against the root /, regardles of
the resource and the real root of WebDAV. To solve this problem, I am using a
simple Filter to filter the MS WebDAV requests:
/**
* The webdav interceptor blocks some FrontPage requests and determinate the
encoding of the underlying request
*
*/
public class WebdavInterceptor implements Filter {
public static final String MICROSOFT_PROTOCOL_AGENT =
Microsoft Data Access Internet Publishing Provider Protocol Discovery;
/** Creates a new instance of LoginInterceptor */
public WebdavInterceptor()
{
}
public void init(javax.servlet.FilterConfig filterConfig) throws
javax.servlet.ServletException
{
}
public void destroy()
{
}
/** Filter some invalid calls from the Microsoft WebDAV clients (Windows
2000, Windows XP and Office 2003) */
public void doFilter(ServletRequest servletRequest, ServletResponse
servletResponse,
FilterChain filterChain) throws IOException, ServletException
{
HttpServletRequest request = (HttpServletRequest)servletRequest;
String path = request.getServletPath();
if (path != null) {
if (path.endsWith(/index.jsp)) {
// a very strange microsoft webdav handling... (because of the
front page extensions!)
// Microsoft (protocol discoverer) is asking the root of the
server
// whether it can handles a WebDAV, so we have to catch it
here. Unfortunately we can't
// redirect the root URL (/) to a servlet, because we will
intercept any other
// path handling...
String agent = request.getHeader(user-agent);
if (MICROSOFT_PROTOCOL_AGENT.equals(agent)) {
HttpServletResponse response = (HttpServletResponse)
servletResponse;
response.addHeader(DAV, 1,2);
response.addHeader(Allow, OPTIONS, TRACE, PROPFIND);
response.addHeader(MS-AUTHOR-VIA, DAV);
return;
}
}
// block, front page and m$ office extensions requests...
if (path.startsWith(/_vti) || path.startsWith(/MSOffice)) {
((HttpServletResponse)servletResponse).setStatus
(HttpServletResponse.SC_NOT_FOUND);
return;
}
}
request.setCharacterEncoding(WebdavServlet.getEnconding(request));
filterChain.doFilter(servletRequest, servletResponse);
}
}
Please note, that the root / is mapped to /index.jsp, this is the standard
welcome file whithin my container. Thus the filter is mapped to:
filter-mapping
filter-namewebdavFilter/filter-name
url-pattern*.jsp/url-pattern
/filter-mapping
and also to the WebDAV Servlet:
filter-mapping
filter-namewebdavFilter/filter-name
servlet-namewebdav/servlet-name
/filter-mapping
The WebDAV servket should map additionaly the following paths:
servlet-mapping
servlet-namewebdav/servlet-name
url-pattern/_vti_inf.html/url-pattern
/servlet-mapping
servlet-mapping
servlet-namewebdav/servlet-name
url-pattern/_vti_bin/*/url-pattern
/servlet-mapping
servlet-mapping
servlet-namewebdav/servlet-name
url-pattern/MSOffice/*/url-pattern
/servlet-mapping
I hope, this helps you. My WebDAV root is for instance /webdav/*, and it
works within a container togther with a web application.
Regards
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: Proposal - Comet changes
Filip Hanik - Dev Lists wrote:
head is clearing up...how about...
since:
public class MyServlet implements HttpServlet, o.a.c.CometProcessor {
wouldn't it make sense for:
public class MyFilter implements Filter, o.a.c.CometFilter {
and you'd declare it the same way, since we are piggy backing on the
servlet logic to create Comet servlets, wouldn't it be smart to piggy
back on the filter logic to create Comet filters?
the interface CometFilter would define the new application chain, ie
void event(CometEvent,CometFilterChain)
achieves the new filter chain, piggy backs on mapping logic.
Great ! Yes, mapping is easy to add, so since you like it, those
filters can completely use the existing infrastructure. Are you ok if
I start with adding your CometEvent interface to the main source tree ?
On the other side of the container fence, I would need to make some mods
to the valve type (since if I don't have any possibility to integrate
with JEE, my boss will murder me). Most likely I would add a new event
method to Valve and ValveBase (as a special case, the begin event
would be handled by the regular invoke method), and the (very few)
valves that need to do business per event would be able to do it. AFAIK,
all current valves invoke methods support Comet without problems (they
don't do any funky tricks, and provide functionality that is still going
to be needed on the initial event: HTTP auth, error pages and reports,
etc). I think we should also specify that the response will be
considered committed after the initial event. This also means the event
method in the servlet adapter will not directly call the servlet (which
IMO is a good idea).
I missed it, but I am ok with adding a close method on the event
class, since it is more explicit (indeed, it is to be implemented by
closing the output buffer).
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r441504 - in /tomcat/tc6.0.x/trunk/java/org/apache/jasper: ./ compiler/ resources/
Author: remm
Date: Fri Sep 8 07:14:35 2006
New Revision: 441504
URL: http://svn.apache.org/viewvc?view=revrev=441504
Log:
- More cleanup (incl small API tweaks, parametrization, etc).
- Slash away most of BeanRepository. Most of it wasn't being used or did
anything of value (other than doing tons of
lookups in Vectors). Weird. Did I miss something ?
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/jasper/JspCompilationContext.java
tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/AntCompiler.java
tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/BeanRepository.java
tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Compiler.java
tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/ELNode.java
tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/ErrorDispatcher.java
tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Generator.java
tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/ParserController.java
tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/TagFileProcessor.java
tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java
tomcat/tc6.0.x/trunk/java/org/apache/jasper/resources/LocalStrings.properties
Modified: tomcat/tc6.0.x/trunk/java/org/apache/jasper/JspCompilationContext.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/jasper/JspCompilationContext.java?view=diffrev=441504r1=441503r2=441504
==
--- tomcat/tc6.0.x/trunk/java/org/apache/jasper/JspCompilationContext.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/jasper/JspCompilationContext.java Fri
Sep 8 07:14:35 2006
@@ -21,7 +21,8 @@
import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLClassLoader;
-import java.util.Hashtable;
+import java.util.HashMap;
+import java.util.Map;
import java.util.Set;
import javax.servlet.ServletContext;
@@ -54,41 +55,41 @@
protected org.apache.commons.logging.Log log =
org.apache.commons.logging.LogFactory.getLog(JspCompilationContext.class);
-private Hashtable tagFileJarUrls;
-private boolean isPackagedTagFile;
+protected MapString, URL tagFileJarUrls;
+protected boolean isPackagedTagFile;
-private String className;
-private String jspUri;
-private boolean isErrPage;
-private String basePackageName;
-private String derivedPackageName;
-private String servletJavaFileName;
-private String javaPath;
-private String classFileName;
-private String contentType;
-private ServletWriter writer;
-private Options options;
-private JspServletWrapper jsw;
-private Compiler jspCompiler;
-private String classPath;
-
-private String baseURI;
-private String outputDir;
-private ServletContext context;
-private URLClassLoader loader;
-
-private JspRuntimeContext rctxt;
-
-private int removed = 0;
-
-private URLClassLoader jspLoader;
-private URL baseUrl;
-private Class servletClass;
-
-private boolean isTagFile;
-private boolean protoTypeMode;
-private TagInfo tagInfo;
-private URL tagFileJarUrl;
+protected String className;
+protected String jspUri;
+protected boolean isErrPage;
+protected String basePackageName;
+protected String derivedPackageName;
+protected String servletJavaFileName;
+protected String javaPath;
+protected String classFileName;
+protected String contentType;
+protected ServletWriter writer;
+protected Options options;
+protected JspServletWrapper jsw;
+protected Compiler jspCompiler;
+protected String classPath;
+
+protected String baseURI;
+protected String outputDir;
+protected ServletContext context;
+protected URLClassLoader loader;
+
+protected JspRuntimeContext rctxt;
+
+protected int removed = 0;
+
+protected URLClassLoader jspLoader;
+protected URL baseUrl;
+protected Class servletClass;
+
+protected boolean isTagFile;
+protected boolean protoTypeMode;
+protected TagInfo tagInfo;
+protected URL tagFileJarUrl;
// jspURI _must_ be relative to the context
public JspCompilationContext(String jspUri,
@@ -118,7 +119,7 @@
}
this.rctxt = rctxt;
-this.tagFileJarUrls = new Hashtable();
+this.tagFileJarUrls = new HashMapString, URL();
this.basePackageName = Constants.JSP_PACKAGE_NAME;
}
@@ -230,7 +231,7 @@
return jspCompiler;
}
-private Compiler createCompiler(String className) {
+protected Compiler createCompiler(String className) {
Compiler compiler = null;
try {
compiler = (Compiler) Class.forName(className).newInstance();
@@ -304,8 +305,12 @@
* The map is populated when parsing the tag-file elements of the TLDs
* of any imported taglibs.
*/
-public Hashtable getTagFileJarUrls() {
-return
Re: Proposal - Comet changes
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
head is clearing up...how about...
since:
public class MyServlet implements HttpServlet, o.a.c.CometProcessor {
wouldn't it make sense for:
public class MyFilter implements Filter, o.a.c.CometFilter {
and you'd declare it the same way, since we are piggy backing on the
servlet logic to create Comet servlets, wouldn't it be smart to piggy
back on the filter logic to create Comet filters?
the interface CometFilter would define the new application chain, ie
void event(CometEvent,CometFilterChain)
achieves the new filter chain, piggy backs on mapping logic.
Great ! Yes, mapping is easy to add, so since you like it, those
filters can completely use the existing infrastructure. Are you ok
if I start with adding your CometEvent interface to the main source
tree ?
On the other side of the container fence, I would need to make some
mods to the valve type (since if I don't have any possibility to
integrate with JEE, my boss will murder me). Most likely I would add a
new event method to Valve and ValveBase (as a special case, the
begin event would be handled by the regular invoke method), and the
(very few) valves that need to do business per event would be able to
do it. AFAIK, all current valves invoke methods support Comet
without problems (they don't do any funky tricks, and provide
functionality that is still going to be needed on the initial event:
HTTP auth, error pages and reports, etc). I think we should also
specify that the response will be considered committed after the
initial event. This also means the event method in the servlet adapter
will not directly call the servlet (which IMO is a good idea).
I missed it, but I am ok with adding a close method on the event
class, since it is more explicit (indeed, it is to be implemented by
closing the output buffer).
yes please get started, I want to spend some time in the clustering code
right now, so I'll chime in a bit later.
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: Tomcat 5.5.19 Beta build is complete
ok, so we have a version mismatch, and a missing tar.gz file.
can we get this fixed?
Filip
Remy Maucherat wrote:
Peter Rossbach wrote:
Hi Filip and Mladen
is it correct that wrong tc native version is inside
build.properties.default ?
# - Tomcat native library -
tomcat-native.home=${base.path}/tomcat-native-1.1.3
tomcat-native.tar.gz=${tomcat-native.home}/tomcat-native.tar.gz
tomcat-native.loc=${base-tomcat.loc}/tomcat-connectors/native/tomcat-native-1.1.3.tar.gz
Tcnative 1.1.4 can be found at:
http://tomcat.heanet.ie/native/1.1.4/source/
but missing at
http://archive.apache.org/dist/tomcat/tomcat-connectors/native/
Oops. The update is far from critical, but however Mladen bumped up
the required version number in the listener (note: please don't do
that unless there's an API breakage), so it won't fly.
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: Tomcat 5.5.19 Beta build is complete
the other option is of course to roll back the listener back to 1.1.3
filip
Filip Hanik - Dev Lists wrote:
ok, so we have a version mismatch, and a missing tar.gz file.
can we get this fixed?
Filip
Remy Maucherat wrote:
Peter Rossbach wrote:
Hi Filip and Mladen
is it correct that wrong tc native version is inside
build.properties.default ?
# - Tomcat native library -
tomcat-native.home=${base.path}/tomcat-native-1.1.3
tomcat-native.tar.gz=${tomcat-native.home}/tomcat-native.tar.gz
tomcat-native.loc=${base-tomcat.loc}/tomcat-connectors/native/tomcat-native-1.1.3.tar.gz
Tcnative 1.1.4 can be found at:
http://tomcat.heanet.ie/native/1.1.4/source/
but missing at
http://archive.apache.org/dist/tomcat/tomcat-connectors/native/
Oops. The update is far from critical, but however Mladen bumped up
the required version number in the listener (note: please don't do
that unless there's an API breakage), so it won't fly.
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]
Re: Tomcat 5.5.19 Beta build is complete
Filip Hanik - Dev Lists wrote: the other option is of course to roll back the listener back to 1.1.3 filip Filip Hanik - Dev Lists wrote: ok, so we have a version mismatch, and a missing tar.gz file. can we get this fixed? Yes, it's either actually release the new native source bundle, or rollback the listener. IMO, it's better to rollback, since I am not aware of any API breakage, and I think the listener should contain the least recent native version that still works (of course, the installer could use the latest binary, and similarly the latest .tar.gz should be shipped in the download, if possible). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)
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=33453. 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=33453 --- Additional Comments From [EMAIL PROTECTED] 2006-09-08 15:43 --- My patch doesn't change the overall strategy for invoking the isOutDated() check, as you are suggesting. The isOutDated() check does load the class, as it did prior to my patch. Revalidating the entire tree would cause all the class files to be loaded, which would be bad. However, with the isOutDated() method fixed, I see no reason to revalidate the entire tree. (In reply to comment #61) What are the side-effects of revalidating the entire tree ? Does it cause all class files to be loaded or can the revalidation occur without having any lasting overheads (like increased memory consumption and slower revalidation process due to parsing of more complex .class data). My method only seeks to delete stale work/ .java and .class files during web- app deployment. It does not seek to recreate and load them, that can be left to moment of first use (although it would natually lead on to facilitating an automatic recreation function). By opening the .java file and looking for a magic comment and closing the file again, there is no lasting overhead. Since we never loaded the class. Which is just great for a revalidation pass during deployment. I'm a believer there should be a configuration mode of TC which is watertight, such that no amount of abuse will make the things fail in a way that bites you. The work/ directory is a nice speedup but the implementation is more a hack than an optimization, since it clearly breaks down in situations you wouldn't expect. This bug/problem hits developers a lot more than production upgrades. -- 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: Tomcat 5.5.19 Beta build is complete
Remy Maucherat wrote: the other option is of course to roll back the listener back to 1.1.3 Yes, it's either actually release the new native source bundle, or rollback the listener. IMO, it's better to rollback, since I am not aware of any API breakage, and I think the listener should contain the least recent native version that still works (of course, the installer could use the latest binary, and similarly the latest .tar.gz should be shipped in the download, if possible). Right, it makes sense. The best I think would be to actually use the 1.1.x as minimum version, (well 1.1.3 actually), and make a warning if the version is not 1.1.4 (latest one) instead failing. The fail should happen for 1.2.x version (API change). Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.19 Beta build is complete
Mladen Turk wrote: Remy Maucherat wrote: the other option is of course to roll back the listener back to 1.1.3 Yes, it's either actually release the new native source bundle, or rollback the listener. IMO, it's better to rollback, since I am not aware of any API breakage, and I think the listener should contain the least recent native version that still works (of course, the installer could use the latest binary, and similarly the latest .tar.gz should be shipped in the download, if possible). Right, it makes sense. The best I think would be to actually use the 1.1.x as minimum version, (well 1.1.3 actually), and make a warning if the version is not 1.1.4 (latest one) instead failing. The fail should happen for 1.2.x version (API change). You should do a 1.1.4 release here, though: http://www.apache.org/dist/tomcat/tomcat-connectors/native/ Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.19 Beta build is complete
ok, I'm changing it to 1.1.3, and we'll use that for now. Mladen Turk wrote: Remy Maucherat wrote: the other option is of course to roll back the listener back to 1.1.3 Yes, it's either actually release the new native source bundle, or rollback the listener. IMO, it's better to rollback, since I am not aware of any API breakage, and I think the listener should contain the least recent native version that still works (of course, the installer could use the latest binary, and similarly the latest .tar.gz should be shipped in the download, if possible). Right, it makes sense. The best I think would be to actually use the 1.1.x as minimum version, (well 1.1.3 actually), and make a warning if the version is not 1.1.4 (latest one) instead failing. The fail should happen for 1.2.x version (API change). Regards, Mladen. - 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: r441547 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/AprLifecycleListener.java
Author: fhanik Date: Fri Sep 8 09:03:03 2006 New Revision: 441547 URL: http://svn.apache.org/viewvc?view=revrev=441547 Log: Minimum required version is 1.1.3 Modified: tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/AprLifecycleListener.java Modified: tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/AprLifecycleListener.java URL: http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/AprLifecycleListener.java?view=diffrev=441547r1=441546r2=441547 == --- tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/AprLifecycleListener.java (original) +++ tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/AprLifecycleListener.java Fri Sep 8 09:03:03 2006 @@ -52,7 +52,7 @@ protected static final int REQUIRED_MAJOR = 1; protected static final int REQUIRED_MINOR = 1; -protected static final int REQUIRED_PATCH = 4; +protected static final int REQUIRED_PATCH = 3; // -- LifecycleListener Methods - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tagging 5.5.20
Ok, with the latest mishap of the native versions, we'll make another attempt. I will tag 5.5.20 on Monday, 4pm CST (22.00 GMT) Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.19 Beta build is complete
Filip Hanik - Dev Lists wrote: You should do a 1.1.4 release here, though: http://www.apache.org/dist/tomcat/tomcat-connectors/native/ are the native releases never voted on? No. They are part of Tomcat tags although we have version to be loosely coupled. We don't have a separate product 'Tomcat Native', so the versioning is just internal to Tomcat. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.19 Beta build is complete
Mladen Turk wrote: Filip Hanik - Dev Lists wrote: You should do a 1.1.4 release here, though: http://www.apache.org/dist/tomcat/tomcat-connectors/native/ are the native releases never voted on? No. They are part of Tomcat tags although we have version to be loosely coupled. We don't have a separate product 'Tomcat Native', so the versioning is just internal to Tomcat. in that case you can't upload the 1.1.4 release to www.apache.org (and its mirrors) until the Tomcat has been voted to release. you could put them in dev.apache.org or some other location. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.19 Beta build is complete
Filip Hanik - Dev Lists wrote: Mladen Turk wrote: Filip Hanik - Dev Lists wrote: You should do a 1.1.4 release here, though: http://www.apache.org/dist/tomcat/tomcat-connectors/native/ are the native releases never voted on? No. They are part of Tomcat tags although we have version to be loosely coupled. We don't have a separate product 'Tomcat Native', so the versioning is just internal to Tomcat. in that case you can't upload the 1.1.4 release to www.apache.org (and its mirrors) until the Tomcat has been voted to release. you could put them in dev.apache.org or some other location. Which isn't that great, since the .tar.gz is supposed to be included in the Tomcat release (for convenience). That .tar.gz could be removed, instead ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging 5.5.20
Filip Hanik - Dev Lists wrote: Ok, with the latest mishap of the native versions, we'll make another attempt. I will tag 5.5.20 on Monday, 4pm CST (22.00 GMT) OK. I'll try to refactor the APR listener so it uses the 'minimum API' (1.1.3) version without breaking, and issuing a note if the version is less then 'recommended' (1.1.4). Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging 5.5.20
Mladen Turk wrote: Filip Hanik - Dev Lists wrote: Ok, with the latest mishap of the native versions, we'll make another attempt. I will tag 5.5.20 on Monday, 4pm CST (22.00 GMT) OK. I'll try to refactor the APR listener so it uses the 'minimum API' (1.1.3) version without breaking, and issuing a note if the version is less then 'recommended' (1.1.4). This is useless (and possibly even dangerous) because the recommended version may change in the meantime. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging 5.5.20
Remy Maucherat wrote: OK. I'll try to refactor the APR listener so it uses the 'minimum API' (1.1.3) version without breaking, and issuing a note if the version is less then 'recommended' (1.1.4). This is useless (and possibly even dangerous) because the recommended version may change in the meantime. I meant: Minimum workable: 1.1.3 Minimum (without warning): 1.1.4 So, the next version (1.1.4+) will not issue an warning. -- Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r441576 - /tomcat/connectors/trunk/jk/native/iis/pcre/
Author: mturk Date: Fri Sep 8 10:10:54 2006 New Revision: 441576 URL: http://svn.apache.org/viewvc?view=revrev=441576 Log: Import pcre from Apache Httpd Added: tomcat/connectors/trunk/jk/native/iis/pcre/ - copied from r441575, httpd/httpd/trunk/srclib/pcre/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r441579 - /tomcat/connectors/trunk/jk/native/iis/isapi.dsw
Author: mturk
Date: Fri Sep 8 10:15:36 2006
New Revision: 441579
URL: http://svn.apache.org/viewvc?view=revrev=441579
Log:
Add .dsw file. We'll add pcre dependency to it.
Added:
tomcat/connectors/trunk/jk/native/iis/isapi.dsw (with props)
Added: tomcat/connectors/trunk/jk/native/iis/isapi.dsw
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/iis/isapi.dsw?view=autorev=441579
==
--- tomcat/connectors/trunk/jk/native/iis/isapi.dsw (added)
+++ tomcat/connectors/trunk/jk/native/iis/isapi.dsw Fri Sep 8 10:15:36 2006
@@ -0,0 +1,29 @@
+Microsoft Developer Studio Workspace File, Format Version 6.00
+# WARNING: DO NOT EDIT OR DELETE THIS WORKSPACE FILE!
+
+###
+
+Project: isapi=.\isapi.dsp - Package Owner=4
+
+Package=5
+{{{
+}}}
+
+Package=4
+{{{
+}}}
+
+###
+
+Global:
+
+Package=5
+{{{
+}}}
+
+Package=3
+{{{
+}}}
+
+###
+
Propchange: tomcat/connectors/trunk/jk/native/iis/isapi.dsw
--
svn:eol-style = CRLF
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[TC6] makeOutputDir() revision breaks Jasper
Revision 441109 to JspCompilationContext.java results in makeOutputDir()
returning false even if the desired outputDir exists. This is because
File.mkdirs() returns true if and only if the directory was created. If
the directory already exists, makeOutputDir() is returning false,
resulting in an IllegalStateException being thrown.
Possible fix that fits in with other recent revisions to
JspCompilationContext.java:
protected boolean makeOutputDir() {
synchronized(outputDirLock) {
File outDirFile = new File(outputDir);
if (!outDirFile.mkdirs() !outDirFile.exists())
return false;
else
return true;
}
}
Re: Tagging 5.5.20
Remy Maucherat wrote: I still don't see much usefulness. 1.1.4 doesn't contain any serious fixes over 1.1.3, but causes a warning. http://svn.apache.org/viewvc/tomcat/connectors/trunk/jni/native/src/network.c?r1=412388r2=415547diff_format=h It doesn't set/restore the timeout for each socket read/write operation any more, so it's a performance upgrade. If later there's a security issue needing a 1.1.5, there will not be any warning. But then we'll update the 'recommended' to 1.1.5 in listener. Really don't get it why are you against such a change. In general it means that native will work with 'minimum' version (API related), but the particular Tomcat release 'recommends at least' the noted version, with any consequitive version without warning. Don't see what's the problem with something like that. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 40449] New: - Requests for host removed via Host Manager not sent to Engine defaultHost
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=40449. 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=40449 Summary: Requests for host removed via Host Manager not sent to Engine defaultHost Product: Tomcat 5 Version: 5.5.17 Platform: All OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: Webapps:Manager AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Say you have an installation where you have two hosts. A localhost entry, which is specified in the ENGINE configuration as the default host. You also have a secondary web host, foo.yourdomain.com. Using the host-manager application, stop the secondary host and then using the host-manager application, remove it. Observed behavior: Additional requests for foo.yourdomain.com generate HTTP Status 503 - This application is not currently available Expected Behavior: The request should be delivered to the default host for the engine. Additional: It looks like the host remove code is not removing the host names from the internal host resoluton tables as expected. In order to make the requests go to the default host, tomcat has to be restarted. -- 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: Tagging 5.5.20
Filip Hanik - Dev Lists wrote: Don't see what's the problem with something like that. Regards, Mladen. I'm against such change to, not because of usefulness or not, we're trying to cut a stable release, if you want to do it, do for the next tomcat release. Then use 1.1.4 if you wish a stable release. It will work with 1.1.3, but then we'll have a questions like 'what version of native you use?'. Is it 1.1.3 or you downloaded the latest one. Having a simple warning on startup: You are using Native version a.b.c. The recommended one is x.y.z Would at least inform the user that there is API compatible version that has some upgrades over the one he has currently. I really don't see what's wrong with that, and why you guys made such a noise about it. It's a simple note to the user to consider to upgrade his native. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 40440] - Problem with characters when include static html
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=40440. 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=40440 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-09-08 18:43 --- (In reply to comment #5) i know that it is not the forum but I set fileEncoding on the DefaultServlet and when i use Request time include action the characters are ok but when I use Translation time include then there is still problem with incorrect characters. This is per the JSP spec. You need to include a [EMAIL PROTECTED] pageEncoding=utf-8 % in the included file, or you get iso-latin-1. -- 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 40151] - mod_jk with Apache doesn't handle jsessionid encoded directory URLs
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=40151. 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=40151 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2006-09-09 01:10 --- I swear that adding something like this was working for me 2 weeks ago, but now it doesn't work, I think I'm going crazy! Can you try adding this to your Apache config? LocationMatch /.*;jsessionid=.* JkMount motorweb /LocationMatch -- 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 32180] - EL functions are executed in privileged 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=32180. 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=32180 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2006-09-09 03:57 --- This is intentional so that the examples execute when a security manage is configured. See revision 305324 on this page http://svn.apache.org/viewvc/tomcat/jasper/branches/TOMCAT_5_0/jasper2/src/share/org/apache/jasper/runtime/PageContextImpl.java?view=logpathrev=306114 You may also want to take a look at revision 306114 on the same 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]
svn commit: r441734 - /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/runtime/PageContextImpl.java
Author: markt
Date: Fri Sep 8 21:02:03 2006
New Revision: 441734
URL: http://svn.apache.org/viewvc?view=revrev=441734
Log:
Code clean up since I was looking at this file
- unused fields removed
- tabs - 8 spaces
Modified:
tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/runtime/PageContextImpl.java
Modified:
tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/runtime/PageContextImpl.java
URL:
http://svn.apache.org/viewvc/tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/runtime/PageContextImpl.java?view=diffrev=441734r1=441733r2=441734
==
---
tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/runtime/PageContextImpl.java
(original)
+++
tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/runtime/PageContextImpl.java
Fri Sep 8 21:02:03 2006
@@ -69,7 +69,7 @@
// The expression evaluator, for evaluating EL expressions.
private static ExpressionEvaluatorImpl elExprEval
- = new ExpressionEvaluatorImpl(false);
+= new ExpressionEvaluatorImpl(false);
// The variable resolver, for evaluating EL expressions.
private VariableResolverImpl variableResolver;
@@ -81,19 +81,14 @@
private Servlet servlet;
private ServletConfig config;
private ServletContext context;
-private JspFactory factory;
-private boolean needsSession;
private String errorPageURL;
-private boolean autoFlush;
-private intbufferSize;
// page-scope attributes
-private transient Hashtableattributes;
+private transient Hashtableattributes;
// per-request state
private transient ServletRequest request;
private transient ServletResponse response;
-private transient Object page;
private transient HttpSession session;
private boolean isIncluded;
@@ -105,49 +100,45 @@
* Constructor.
*/
PageContextImpl(JspFactory factory) {
-this.factory = factory;
- this.variableResolver = new VariableResolverImpl(this);
- this.outs = new BodyContentImpl[0];
- this.attributes = new Hashtable(16);
- this.depth = -1;
+this.variableResolver = new VariableResolverImpl(this);
+this.outs = new BodyContentImpl[0];
+this.attributes = new Hashtable(16);
+this.depth = -1;
}
public void initialize(Servlet servlet,
- ServletRequest request,
+ ServletRequest request,
ServletResponse response,
- String errorPageURL,
+ String errorPageURL,
boolean needsSession,
- int bufferSize,
+ int bufferSize,
boolean autoFlush) throws IOException {
- _initialize(servlet, request, response, errorPageURL, needsSession,
- bufferSize, autoFlush);
+_initialize(servlet, request, response, errorPageURL, needsSession,
+bufferSize, autoFlush);
}
private void _initialize(Servlet servlet,
-ServletRequest request,
-ServletResponse response,
-String errorPageURL,
-boolean needsSession,
-int bufferSize,
-boolean autoFlush) throws IOException {
-
- // initialize state
- this.servlet = servlet;
- this.config = servlet.getServletConfig();
- this.context = config.getServletContext();
- this.needsSession = needsSession;
- this.errorPageURL = errorPageURL;
- this.bufferSize = bufferSize;
- this.autoFlush = autoFlush;
- this.request = request;
- this.response = response;
-
- // Setup session (if required)
- if (request instanceof HttpServletRequest needsSession)
- this.session = ((HttpServletRequest)request).getSession();
- if (needsSession session == null)
- throw new IllegalStateException
+ ServletRequest request,
+ ServletResponse response,
+ String errorPageURL,
+ boolean needsSession,
+ int bufferSize,
+ boolean autoFlush) throws IOException {
+
+// initialize state
+this.servlet = servlet;
+this.config = servlet.getServletConfig();
+this.context = config.getServletContext();
+this.errorPageURL = errorPageURL;
+this.request = request;
+ this.response = response;
+
+// Setup session (if required)
+if (request instanceof HttpServletRequest needsSession)
+this.session = ((HttpServletRequest)request).getSession();
+if (needsSession session == null)
+throw new
DO NOT REPLY [Bug 32569] - ServletContextListener will not die
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=32569. 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=32569 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-09-09 04:09 --- This has been fixed in 5.5.17 onwards. See http://marc.theaimsgroup.com/?l=tomcat-devm=114419083413539w=2 -- 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 32593] - Server (Apache 2.0.48) reached MaxClients setting on FreeBSD
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=32593. 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=32593 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-09-09 04:43 --- There have been many fixes to mod_jk and the AJP connector sicne this bug report. Given the lack of response (over 12 months) to Yoav's request for information, I am going to assume that an upgrade to a later version fixed it. If this is not the case, please provide (using the latest Tomcat 5.5.x and mod_jk 1.2.x) either the steps to reproduce the issue or a thread dump from Tomcat once it hangs. -- 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]
