DO NOT REPLY [Bug 23860] - flag unmatched ending tags(was Struts: warn if logic tags are prematurely terminated)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23860. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23860 flag unmatched ending tags(was Struts: warn if logic tags are prematurely terminated) [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-10-25 11:02 --- *** This bug has been marked as a duplicate of 10903 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10903] - Unbalanced tags do not generate compile time error
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10903. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10903 Unbalanced tags do not generate compile time error [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-10-25 11:02 --- *** Bug 23860 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk timeout?
I noticed this message from Glenn Nielsen recently on this mailing list:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg47341.html
It appears that hgomez submitted a bunch of code that allows you to
configure a ping/pong mechanism that helps it detect hung tomcats. I'm
very much interested in this code, but wonder if it could also detect
an aborted apache process?
Here is a simple test I performed recently with my server configured
like this: (Apache (1.3.x) ---(mod_jk)-- Tomcat 4.1). On all my
apache requests, I set a hard_timeout() using mod_perl. It is pretty
easy to see that this hard_timeout works fine by looking at apache's
/server-status page. My next test was to see if this hard_timeout()
worked for Tomcat. So, I wrote a simple JSP page as such:
%
while(1) {
Thread.sleep(10);
System.out.println(hi\n);
}
%
When I request this page and tail my log file, I see hi printed over
and over as I would expect to see. However, the disturbing part is
that even after the hard_timeout() has expired, this thread is still
executing (since I see a bunch of hi\n in my log file). I check
apache's /server-status page and the process that was servicing the
request is long gone.
Could this recently submitted ping/pong code also be used from the java
side to detect when the Apache side is no longer servicing the request?
I'd be willing to help make this happen if someone could give me some
guidance.
Thanks,
-Brian
P.S. Please note that I am not on the tomcat-dev@ list.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardDefaultContext.java
Since I recently made changes to the DefaultContext in Tomcat 4, perhaps
this could be back ported to Tomcat 4.1.
Regards,
Glenn
[EMAIL PROTECTED] wrote:
remm2003/10/24 04:57:27
Modified:catalina/src/share/org/apache/catalina/core
StandardDefaultContext.java
Log:
- Add support for resource links to StdDefContext.
Revision ChangesPath
1.8 +16 -4 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardDefaultContext.java
Index: StandardDefaultContext.java
===
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardDefaultContext.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- StandardDefaultContext.java 21 Oct 2003 00:18:25 - 1.7
+++ StandardDefaultContext.java 24 Oct 2003 11:57:27 - 1.8
@@ -1373,6 +1373,14 @@
}
listener.addResource(contextEntry);
}
+ContextResourceLink [] resourceLinks = findResourceLinks();
+for (int i = 0; i resourceLinks.length; i++) {
+ContextResourceLink contextEntry = resourceLinks[i];
+if (contextResources.exists(contextEntry.getName())) {
+listener.removeResourceLink(contextEntry.getName());
+}
+listener.addResourceLink(contextEntry);
+}
String [] envRefs = findResourceEnvRefs();
for (int i = 0; i envRefs.length; i++) {
if (contextResources.exists(envRefs[i])) {
@@ -1498,6 +1506,10 @@
ContextResource [] resources = findResources();
for( int i = 0; i resources.length; i++ ) {
context.addResource(resources[i]);
+}
+ContextResourceLink [] resourceLinks = findResourceLinks();
+for( int i = 0; i resourceLinks.length; i++ ) {
+context.addResourceLink(resourceLinks[i]);
}
String [] envRefs = findResourceEnvRefs();
for( int i = 0; i envRefs.length; i++ ) {
-
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 23970] - form-based authentication and SSL, general principles
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23970. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23970 form-based authentication and SSL, general principles --- Additional Comments From [EMAIL PROTECTED] 2003-10-25 16:25 --- All I want to do is encrypt a login form but not the pages the security-constraint protects. It's all well and good that the spec says such-and-such, but what you are ignoring is that fact that this change in TC5 is effectively taking away a large, significant piece functionality from a large, significant percentage of the people out there using TC. There are probably hundreds if not thousands of TC4 users out there doing what I want to do in TC5 but can't. It also implies that you (or rather the people who wrote the spec) expect that other application server providers, i.e. IBM and BEA etc, will be willing to do this to their users too, which is obviously a false assumption. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Embedded Tomcat
I've successfully embedded Tomcat into my application and have talked to a few people about how to shared objects between the application and the JSPs from the contexts I've defined. I've had a suggested to use JNDI but this seems a little more elaborate than I need, and someone else was talking about using ServletContext.setAttribute() and ServletContext.getAttribute() Is there a code example both application side and web side somewhere that could show me how to do this? I've been wrestling with this for a while and it's starting to irritate me. :) I've embedded Tomcat for the sole purpose of being able to create JSPs and Servlets that can examine the properties of the application and modify the properties as well. For example, I need to be able to do the following in my JSP. MyApplication app = someway of getting access to the instantiated object; Object obj = app.getSomeData(); obj.modifyInSomeWay(); app.setSomeData(obj); If anyone can provide an example for this, I would very much appreciate it. Thanks. -- Robert Charbonneau [EMAIL PROTECTED] -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24123] - AccessLogInterceptor does not log PUT/POST requests
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24123. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24123 AccessLogInterceptor does not log PUT/POST requests --- Additional Comments From [EMAIL PROTECTED] 2003-10-25 22:41 --- Created an attachment (id=8737) Enable logging of POST/PUT requests and report the number of bytes received. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/loggers AccessLogInterceptor.java
billbarker2003/10/25 18:19:13
Modified:src/share/org/apache/tomcat/modules/loggers
AccessLogInterceptor.java
Log:
Change logging to an event that always gets fired.
Also log the bytes recieved for PUT.
Fix for Bug #24123
Summitted by: Michael Lemke [EMAIL PROTECTED]
Revision ChangesPath
1.12 +9 -4
jakarta-tomcat/src/share/org/apache/tomcat/modules/loggers/AccessLogInterceptor.java
Index: AccessLogInterceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/loggers/AccessLogInterceptor.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- AccessLogInterceptor.java 29 Sep 2003 07:41:50 - 1.11
+++ AccessLogInterceptor.java 26 Oct 2003 01:19:13 - 1.12
@@ -189,7 +189,7 @@
/** pThis method is actually creating an entry in the log file./p
*/
-public int beforeCommit(Request request, Response response) {
+public int postRequest(Request request, Response response) {
synchronized (AccessLogInterceptor.class) {
FileWriter fw = getFileWriter();
if (fw != null) {
@@ -242,9 +242,14 @@
fw.write(request.protocol().toString().trim());
break;
case 'b':
- String cl = response.getMimeHeaders().
-getHeader(Content-Length);
- if(cl != null) {
+ String cl;
+ if(response.getStatus() == 201) {
+ cl = request.getHeader(Content-Length);
+ } else {
+ cl = response.getMimeHeaders().
+ getHeader(Content-Length);
+ }
+ if(cl != null !0.equals(cl)) {
fw.write(cl);
} else {
fw.write(-);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24123] - AccessLogInterceptor does not log PUT/POST requests
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24123. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24123 AccessLogInterceptor does not log PUT/POST requests [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-10-26 01:22 --- Patch committed. Thanks much! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat RELEASE-NOTES-3.3.2.txt
billbarker2003/10/25 18:43:59 Modified:.RELEASE-NOTES-3.3.2.txt Log: Documenting patch. Revision ChangesPath 1.21 +4 -1 jakarta-tomcat/RELEASE-NOTES-3.3.2.txt Index: RELEASE-NOTES-3.3.2.txt === RCS file: /home/cvs/jakarta-tomcat/RELEASE-NOTES-3.3.2.txt,v retrieving revision 1.20 retrieving revision 1.21 diff -u -r1.20 -r1.21 --- RELEASE-NOTES-3.3.2.txt 26 Sep 2003 04:27:48 - 1.20 +++ RELEASE-NOTES-3.3.2.txt 26 Oct 2003 01:43:59 - 1.21 @@ -75,6 +75,9 @@ Fix problem where the AccessLog was printing the content-length of the Request instead of the Response. +24123Fix problem where the AccessLog wasn't logging request that produce + no output. Also log the Request's content length for PUT requests. + Jasper: Bug No. Description - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Embedded Tomcat
Hi Robert,
Congratulations on having Embedded Tomcat in your application.
My apologies for not explaining a solution to your problem more clearly.
The method we had discussed by private mail earlier today indeed works. I
cannot give you actual source code, simply because I'm downloading Tomcat at
the moment.
The only part that you need to work on is the :
MyApplication app = someway of getting access to the instantiated object;
that you have mentioned below:
Let's say your application (with all its parts) is represented by
MyApplication.
You could create the class along the lines of :
public class MyApplication{
private static MyApplication currentInstance = null;
private MyApplication(){
}
public MyApplication getCurrentInstance(){
if (currentInstance==null){
currentInstance = new MyApplication();
initialize(); // some initialization work
}
return currentInstance;
}
}
You should now be able to access MyApplication's object from within your web
applications via MyApplication.getCurrentInstance();
In your care, you do not need JNDI. There is another means of sharing objects
(via JMX) that I shall explore once this Tomcat download is completed.
-- Sriram
--- Robert Charbonneau [EMAIL PROTECTED] wrote:
I've successfully embedded Tomcat into my application and have talked to a
few
people about how to shared objects between the application and the JSPs from
the contexts I've defined. I've had a suggested to use JNDI but this seems a
little more elaborate than I need, and someone else was talking about using
ServletContext.setAttribute() and ServletContext.getAttribute()
Is there a code example both application side and web side somewhere that
could show me how to do this? I've been wrestling with this for a while and
it's starting to irritate me. :)
I've embedded Tomcat for the sole purpose of being able to create JSPs and
Servlets that can examine the properties of the application and modify the
properties as well. For example, I need to be able to do the following in my
JSP.
MyApplication app = someway of getting access to the instantiated object;
Object obj = app.getSomeData();
obj.modifyInSomeWay();
app.setSomeData(obj);
If anyone can provide an example for this, I would very much appreciate it.
Thanks.
--
Robert Charbonneau
[EMAIL PROTECTED]
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24121] - Hotfixes need to be easier to find
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24121. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24121 Hotfixes need to be easier to find --- Additional Comments From [EMAIL PROTECTED] 2003-10-26 04:37 --- I don't think this bug is a duplicate of #24121 as this bug is meant to address the general issue of making sure that hotfixes are easy to find. As it is, the only download that is easy to find are releases of Tomcat. The procedure for releasing hotfixes needs to be changed to ensure that people can easily find them. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
