Re: Proposal - Comet changes

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:

5. CometEvent

public class CometEvent {
  public enum EventType {

READ,TIMEOUT,SOCKET_CLOSE,CONTAINER_SHUTDOWN,CONTEXT_SHUTDOWN,GENERIC_ERROR 
//and anything else, we could also create groups of types, 
READ,ERROR,SHUTDOWN, with subtypes

  }

  public HttpServletRequest getRequest();
  public HttpServletResponse getResponse();
  ...and other useful info here
}

I believe this would allow for more flexibility in the future and a 
cleaner interface.
The CometServlet can actually stay exactly the same, if need be, as the 
begin,end methods can be called based on service() and event()


I still mixed on this. Switching to events is a bit more heavyweight 
(objects, ifs blocks to handle the event type), and will cleanup the 
interface but make the implementations slightly more complex.


What I really have a problem with is the many event types, since adding 
more adds complexity for the application code: for starters, the many 
error types (besides error and timeout, anything extra seems useless to 
me) and shutdown (this portion of the code does not have any business to 
get this sort of notifications, especially differentiating between 
shutdown types). As you said it, it's still actually down to 3 useful 
events: read, error and shutdown (aka, end).


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 40265] New: - *.css not delivered by a servlet specified in web.xml

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=40265

   Summary: *.css not delivered by a servlet specified in web.xml
   Product: Tomcat 5
   Version: 5.5.17
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I have a standard tomcat installation with customized server.xml and nothing
else changed.

There is a servlet that is mapped to "/" which delivers anything.

On Tomcat<=5.0 this works fine.
Since Tomcat 5.5 any *.css file is delivered directly by tomcat.

Changing the mapping to "*.css" had no success.

-- 
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 40265] - *.css not delivered by a servlet specified in web.xml

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=40265





--- Additional Comments From [EMAIL PROTECTED]  2006-08-16 11:28 ---
my server.xml


  


  
  

  

  



-- 
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 40265] - *.css not delivered by a servlet specified in web.xml

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=40265





--- Additional Comments From [EMAIL PROTECTED]  2006-08-16 11:30 ---
the server.xml above contained a wrong line. the  name attribute is 
"test".

my context's WEB-INF/web.xml contains:


Main
/



-- 
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 40265] - *.css not delivered by a servlet specified in web.xml

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=40265





--- Additional Comments From [EMAIL PROTECTED]  2006-08-16 11:44 ---
And what happens if you rename the servlet from "Main" to "default" ?

Maybe remove the "/" mapping completely.

Check out $CATALINA_BASE/conf/web.xml for the overridable defaults (overridable
in WEB-INF/web.xml)

-- 
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]

change in session activity tracking between Tomcat 4.1/5.0 and Tomcat 5.5

[Dies Koper]

Hello,

I'm looking into an issue we ran into when upgrading from Tomcat 4.1 to
Tomcat 5.5.

The time returned by the HttpSession.getLastAccessTime method seems to
have changed.
We believe it should return the time of the previous request from the
same client. It did in Tomcat 4.1. It did so no matter whether that
client accessed a Servlet or an html file.

However, in Tomcat 5.5 it only returns this time if the previous request
went to a servlet, and that servlet called the getSession or
request.encodeURL method. Otherwise it returns the time of the last
request from that client that did call either of those methods.

I am a bit confused why. Did the Tomcat developers disagree with the
Servlet spec or the interpretation of it at the time Tomcat 4.1 was
released and is this now fixed? Or is it an accidental side-effect of
another change?

The reason I ask is because I need to solve this problem. Should I look
for a work-around or try to write a patch?

So far, I found that the change happened in Tomcat 5.0, with the
following commit.

Revision: 302627
Author: remm
Date: 3:21:36, 2004-01-23
Message:
- Improvements to session activity tracking, handling the case where the
  session is new, as well as cross context.
- If this doesn't work, I give up ;)

Modified :
/tomcat/container/catalina/trunk/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
Modified :
/tomcat/container/catalina/trunk/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java
Modified :
/tomcat/container/catalina/trunk/catalina/src/share/org/apache/catalina/core/StandardHostValve.java
Modified :
/tomcat/container/catalina/trunk/catalina/src/share/org/apache/catalina/session/StandardSession.java

Thanks,
Dies


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r431890 - in /tomcat/tc6.0.x/trunk/webapps/examples/servlets: cookies.html helloworld.html index.html reqheaders.html reqinfo.html reqparams.html sessions.html

[remm]

Author: remm
Date: Wed Aug 16 05:57:35 2006
New Revision: 431890

URL: http://svn.apache.org/viewvc?rev=431890&view=rev
Log:
- Note: the paths are not completely correct.

Added:
tomcat/tc6.0.x/trunk/webapps/examples/servlets/cookies.html   (with props)
tomcat/tc6.0.x/trunk/webapps/examples/servlets/helloworld.html   (with 
props)
tomcat/tc6.0.x/trunk/webapps/examples/servlets/index.html   (with props)
tomcat/tc6.0.x/trunk/webapps/examples/servlets/reqheaders.html   (with 
props)
tomcat/tc6.0.x/trunk/webapps/examples/servlets/reqinfo.html   (with props)
tomcat/tc6.0.x/trunk/webapps/examples/servlets/reqparams.html   (with props)
tomcat/tc6.0.x/trunk/webapps/examples/servlets/sessions.html   (with props)

Added: tomcat/tc6.0.x/trunk/webapps/examples/servlets/cookies.html
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/examples/servlets/cookies.html?rev=431890&view=auto
==
--- tomcat/tc6.0.x/trunk/webapps/examples/servlets/cookies.html (added)
+++ tomcat/tc6.0.x/trunk/webapps/examples/servlets/cookies.html Wed Aug 16 
05:57:35 2006
@@ -0,0 +1,60 @@
+
+
+
+Untitled Document
+
+
+
+
+
+Source Code for Cookie Example
+   
+ 
+import java.io.*;
+import javax.servlet.*;
+import javax.servlet.http.*;
+
+public class CookieExample extends HttpServlet {
+
+public void doGet(HttpServletRequest request, 
HttpServletResponse response)
+throws IOException, ServletException
+{
+response.setContentType("text/html");
+PrintWriter out = response.getWriter();
+
+// print out cookies
+
+Cookie[] cookies = request.getCookies();
+for (int i = 0; i < cookies.length; i++) {
+Cookie c = cookies[i];
+String name = c.getName();
+String value = c.getValue();
+out.println(name + " = " + 
value);
+}
+
+// set a cookie
+
+String name = request.getParameter("cookieName");
+if (name != null && name.length() > 0) {
+String value = request.getParameter("cookieValue");
+Cookie c = new Cookie(name, value);
+response.addCookie(c);
+}
+}
+}
+
+

Propchange: tomcat/tc6.0.x/trunk/webapps/examples/servlets/cookies.html
--
svn:eol-style = native

Added: tomcat/tc6.0.x/trunk/webapps/examples/servlets/helloworld.html
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/examples/servlets/helloworld.html?rev=431890&view=auto
==
--- tomcat/tc6.0.x/trunk/webapps/examples/servlets/helloworld.html (added)
+++ tomcat/tc6.0.x/trunk/webapps/examples/servlets/helloworld.html Wed Aug 16 
05:57:35 2006
@@ -0,0 +1,49 @@
+
+
+
+Untitled Document
+
+
+
+
+
+Source Code for HelloWorld Example
+   
+
+import java.io.*;
+import javax.servlet.*;
+import javax.servlet.http.*;
+
+public class HelloWorld extends HttpServlet {
+
+public void doGet(HttpServletRequest request, 
HttpServletResponse response)
+throws IOException, ServletException
+{
+response.setContentType("text/html");
+PrintWriter out = response.getWriter();
+out.println("");
+out.println("");
+out.println("");
+out.println("");
+out.println("");
+out.println("
Hello 
World!
");
+out.println("");
+out.println("");
+}
+}
+
+

Propchange: tomcat/tc6.0.x/trunk/webapps/examples/servlets/helloworld.html
--
svn:eol-style = native

Added: tomcat/tc6.0.x/trunk/webapps/examples/servlets/index.html
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/examples/servlets/index.html?rev=431890&view=auto
==
--- tomcat/tc6.0.x/trunk/webapps/examples/servlets/index.html (added)
+++ tomcat/tc6.0.x/trunk/webapps/examples/servlets/index.html Wed Aug 16 
05:57:35 2006
@@ -0,0 +1,120 @@
+
+
+
+
+   
+   
+   
+   Servlet Examples
+
+
+Servlet
+Examples with Code
+This is a collection of examples which demonstrate some of the more
+frequently used parts of the Servlet API. Familiarity with the Java(tm)
+Programming Language is assumed.
+These examples will only work when viewed via an http URL. They will
+not work if you are viewing these pages via a "file://..." URL. Please
+refer to the README file provide with this Tomcat release regarding
+how to configure and start the provided web server.
+Wherever you see a form, enter some data and see how the servlet reacts.
+When playing with the Cookie and Session Examples, jump back to the Headers
+Example to see exactly what your browser is sending the server.
+To navigate your way throu

svn commit: r431891 - /tomcat/tc6.0.x/trunk/build.xml

[remm]

Author: remm
Date: Wed Aug 16 05:57:57 2006
New Revision: 431891

URL: http://svn.apache.org/viewvc?rev=431891&view=rev
Log:
- Build the examples classes.

Modified:
tomcat/tc6.0.x/trunk/build.xml

Modified: tomcat/tc6.0.x/trunk/build.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/build.xml?rev=431891&r1=431890&r2=431891&view=diff
==
--- tomcat/tc6.0.x/trunk/build.xml (original)
+++ tomcat/tc6.0.x/trunk/build.xml Wed Aug 16 05:57:57 2006
@@ -422,7 +422,16 @@
   
 
 
-
+
+
+
+
+   
 
 
   



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 40265] - *.css not delivered by a servlet specified in web.xml

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=40265





--- Additional Comments From [EMAIL PROTECTED]  2006-08-16 13:31 ---
Created an attachment (id=18721)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=18721&action=view)
test webapp

i wrote a minimal test webapp. the server.xml is in the next attachment.

The behaviour is:
- when a folder exists on startup, anything below is served by tomcat
- when the folder not exists, it's served by my servlet
- when the folder is created after tomcat startup, it's still served by my
servlet
- when the folder is removed after tomcat startup, it's still served by tomcat

http://192.168.100.197:8080/test.htm -> served by my servlet
http://192.168.100.197:8080/xyz/xy.css -> served by my servlet
http://192.168.100.197:8080/layout/test.css -> served by tomcat
http://192.168.100.197:8080/layout/xy.css -> served by tomcat, 404


-- 
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 40265] - files are sometimes not delivered by a servlet specified in web.xml

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=40265


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|*.css not delivered by a|files are sometimes not
   |servlet specified in web.xml|delivered by a servlet
   ||specified in web.xml




-- 
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 40265] - files are sometimes not delivered by a servlet specified in web.xml

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=40265





--- Additional Comments From [EMAIL PROTECTED]  2006-08-16 13:33 ---
Created an attachment (id=18722)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=18722&action=view)
server.xml


-- 
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 40265] - files are sometimes not delivered by a servlet specified in web.xml

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=40265





--- Additional Comments From [EMAIL PROTECTED]  2006-08-16 13:36 ---
when i remove the default servlet form the $TOMCAT_HOME/conf/web.xml, files on
existing folders not found anymore.

-- 
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]

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:

5. CometEvent

public class CometEvent {
  public enum EventType {

READ,TIMEOUT,SOCKET_CLOSE,CONTAINER_SHUTDOWN,CONTEXT_SHUTDOWN,GENERIC_ERROR 
//and anything else, we could also create groups of types, 
READ,ERROR,SHUTDOWN, with subtypes

  }

  public HttpServletRequest getRequest();
  public HttpServletResponse getResponse();
  ...and other useful info here
}

I believe this would allow for more flexibility in the future and a 
cleaner interface.
The CometServlet can actually stay exactly the same, if need be, as 
the begin,end methods can be called based on service() and event()


I still mixed on this. Switching to events is a bit more heavyweight 
(objects, ifs blocks to handle the event type), and will cleanup the 
interface but make the implementations slightly more complex.
The implementation is already pretty complex, there are two methods I am 
required to implement although they are never called by the container.
The CometProcessor today is hard to implement without actually reverse 
engineer the code to see what is going on.
What I am looking for, and I'm not saying the above is the final answer, 
is a more intuitive life cycle. So there are two goals:
1. Get rid of the application having to set 
request.setAttribute(bla.bla.comet), I think the fact that a servlet 
implements the CometProcessor interface should be enough
  The same thing goes for request.removeAttribute(bla.bla.comet) - 
since the container already controls the lifecycle, let it control the 
lifecycle all the way, just like a servlet
  An alternative is to provide a CometServlet that finals the service() 
method, and that way all comet communication, including the "start" 
event, is sent to the event() method.
2. When speaking of the lifecycle of the request, the CometProcessor can 
end it by calling response.getWriter().close(), unless we provide a 
close() method the event object
3. In terms of heavy weight, the entire lifecycle of the request can 
reuse the same event object, the only thing that changes in between is 
the event. so essentially, you're only pushing one object on the stack 
instead of two or three or however many arguments you have.


What I really have a problem with is the many event types, since 
adding more adds complexity for the application code: for starters, 
the many error types (besides error and timeout, anything extra seems 
useless to me) and shutdown (this portion of the code does not have 
any business to get this sort of notifications, especially 
differentiating between shutdown types). As you said it, it's still 
actually down to 3 useful events: read, error and shutdown (aka, end).
I agree on the types, that is why I mention main and sub types, for the 
main. The sub types can be useful, cause an implementation may want to 
know why the request is ended or error:ed out. Its important, cause a 
simple connection timeout, the webapp developer might wanna keep his 
"push data" in a queue to push once the client opens a new connection. 
But if the webapp is reloaded, that queue should be emptied out and 
reloaded upon start again. (for example, today request attributes could 
throw a ClassCastException upon webapp reload, but if there was an 
event, the developer could actually clear those attributes out and 
reload them later). So the lifecycle of a comet servlet, is slightly 
different than a servlet.


I need to noodle on it some more to see how this can be all simplified, 
including the implementation at the end.

I'll come back with a more detailed proposal tomorrow.

Filip

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 40265] - files are sometimes not delivered by a servlet specified in web.xml

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=40265





--- Additional Comments From [EMAIL PROTECTED]  2006-08-16 13:41 ---
i changed the servlet mapping to:

csstest
/layout/test.css

the file is still served by tomcat


-- 
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 40213] - Tomcat/JK Software caused connection abort: socket write error

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=40213





--- Additional Comments From [EMAIL PROTECTED]  2006-08-16 14:14 ---
I have the same problem. Any one knows how do i fix?
(In reply to comment #0)
> Tomcat keeps throwing the following warning within it log files.  I'm not 
> sure 
> if this is the cause of our tomcat server dying sporadically with no real 
> error message being reported but I would like to clear the issue.  This error 
> has only been reported since upgrading from an earlier version of Tomcat.
> 
> 08-Aug-2006 15:57:09 org.apache.jk.core.MsgContext action
> WARNING: Error sending end packet
> java.net.SocketException: Software caused connection abort: socket write error
>   at java.net.SocketOutputStream.socketWrite0(Native Method)
>   at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
>   at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
>   at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:518)
>   at org.apache.jk.common.JkInputStream.endMessage
> (JkInputStream.java:112)
>   at org.apache.jk.core.MsgContext.action(MsgContext.java:293)
>   at org.apache.coyote.Response.action(Response.java:182)
>   at org.apache.coyote.Response.finish(Response.java:304)
>   at org.apache.jk.server.JkCoyoteHandler.invoke
> (JkCoyoteHandler.java:204)
>   at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:282)
>   at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:754)
>   at org.apache.jk.common.ChannelSocket.processConnection
> (ChannelSocket.java:684)
>   at org.apache.jk.common.ChannelSocket$SocketConnection.runIt
> (ChannelSocket.java:876)
>   at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
> (ThreadPool.java:684)
>   at java.lang.Thread.run(Thread.java:595)
> 08-Aug-2006 15:57:09 org.apache.jk.common.ChannelSocket processConnection
> WARNING: processCallbacks status 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 40265] - files are sometimes not delivered by a servlet specified in web.xml

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=40265


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2006-08-16 14:38 ---
http://tomcat.apache.org/tomcat-5.5-doc/config/host.html
See the "deployOnStartup" attribute.

-- 
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

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:

5. CometEvent

public class CometEvent {
  public enum EventType {

READ,TIMEOUT,SOCKET_CLOSE,CONTAINER_SHUTDOWN,CONTEXT_SHUTDOWN,GENERIC_ERROR 
//and anything else, we could also create groups of types, 
READ,ERROR,SHUTDOWN, with subtypes

  }

  public HttpServletRequest getRequest();
  public HttpServletResponse getResponse();
  ...and other useful info here
}

I believe this would allow for more flexibility in the future and a 
cleaner interface.
The CometServlet can actually stay exactly the same, if need be, as 
the begin,end methods can be called based on service() and event()


I still mixed on this. Switching to events is a bit more heavyweight 
(objects, ifs blocks to handle the event type), and will cleanup the 
interface but make the implementations slightly more complex.
The implementation is already pretty complex, there are two methods I am 
required to implement although they are never called by the container.
The CometProcessor today is hard to implement without actually reverse 
engineer the code to see what is going on.
What I am looking for, and I'm not saying the above is the final answer, 
is a more intuitive life cycle. So there are two goals:
1. Get rid of the application having to set 
request.setAttribute(bla.bla.comet), I think the fact that a servlet 
implements the CometProcessor interface should be enough
  The same thing goes for request.removeAttribute(bla.bla.comet) - since 
the container already controls the lifecycle, let it control the 
lifecycle all the way, just like a servlet
  An alternative is to provide a CometServlet that finals the service() 
method, and that way all comet communication, including the "start" 
event, is sent to the event() method.
2. When speaking of the lifecycle of the request, the CometProcessor can 
end it by calling response.getWriter().close(), unless we provide a 
close() method the event object
3. In terms of heavy weight, the entire lifecycle of the request can 
reuse the same event object, the only thing that changes in between is 
the event. so essentially, you're only pushing one object on the stack 
instead of two or three or however many arguments you have.


I see all that as a bit equivalent. I don't see why the implementation 
of the CometServlet (or the example ChatServlet) is complex.


About 1) and 2), I thought about it and it is indeed possible to remove 
the attribute, but more explicit mechanisms looked less error prone to 
me (after all, there are plenty of people out there who flush and close 
the request at the end of their service methods ...). It also gives a 
choice to the user to trigger or not comet IO based on some other things.




What I really have a problem with is the many event types, since 
adding more adds complexity for the application code: for starters, 
the many error types (besides error and timeout, anything extra seems 
useless to me) and shutdown (this portion of the code does not have 
any business to get this sort of notifications, especially 
differentiating between shutdown types). As you said it, it's still 
actually down to 3 useful events: read, error and shutdown (aka, end).
I agree on the types, that is why I mention main and sub types, for the 
main. The sub types can be useful, cause an implementation may want to 
know why the request is ended or error:ed out. Its important, cause a 
simple connection timeout, the webapp developer might wanna keep his 
"push data" in a queue to push once the client opens a new connection. 
But if the webapp is reloaded, that queue should be emptied out and 
reloaded upon start again. (for example, today request attributes could 
throw a ClassCastException upon webapp reload, but if there was an 
event, the developer could actually clear those attributes out and 
reload them later). So the lifecycle of a comet servlet, is slightly 
different than a servlet.


Ok.

I need to noodle on it some more to see how this can be all simplified, 
including the implementation at the end.

I'll come back with a more detailed proposal tomorrow.


Rémy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Proposal - Comet changes

[Filip Hanik - Dev Lists]

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:

5. CometEvent

public class CometEvent {
  public enum EventType {

READ,TIMEOUT,SOCKET_CLOSE,CONTAINER_SHUTDOWN,CONTEXT_SHUTDOWN,GENERIC_ERROR 
//and anything else, we could also create groups of types, 
READ,ERROR,SHUTDOWN, with subtypes

  }

  public HttpServletRequest getRequest();
  public HttpServletResponse getResponse();
  ...and other useful info here
}

I believe this would allow for more flexibility in the future and a 
cleaner interface.
The CometServlet can actually stay exactly the same, if need be, as 
the begin,end methods can be called based on service() and event()


I still mixed on this. Switching to events is a bit more heavyweight 
(objects, ifs blocks to handle the event type), and will cleanup the 
interface but make the implementations slightly more complex.
The implementation is already pretty complex, there are two methods I 
am required to implement although they are never called by the 
container.
The CometProcessor today is hard to implement without actually 
reverse engineer the code to see what is going on.
What I am looking for, and I'm not saying the above is the final 
answer, is a more intuitive life cycle. So there are two goals:
1. Get rid of the application having to set 
request.setAttribute(bla.bla.comet), I think the fact that a servlet 
implements the CometProcessor interface should be enough
  The same thing goes for request.removeAttribute(bla.bla.comet) - 
since the container already controls the lifecycle, let it control 
the lifecycle all the way, just like a servlet
  An alternative is to provide a CometServlet that finals the 
service() method, and that way all comet communication, including the 
"start" event, is sent to the event() method.
2. When speaking of the lifecycle of the request, the CometProcessor 
can end it by calling response.getWriter().close(), unless we provide 
a close() method the event object
3. In terms of heavy weight, the entire lifecycle of the request can 
reuse the same event object, the only thing that changes in between 
is the event. so essentially, you're only pushing one object on the 
stack instead of two or three or however many arguments you have.


I see all that as a bit equivalent. I don't see why the implementation 
of the CometServlet (or the example ChatServlet) is complex.
let me tell you why, if I extend the CometServlet, which I must since it 
is abstract, I would assume I can override the begin method, expecting 
to have begin called, but if I don't call super.begin, the 
implementation no longer works cause the org.apache.tomcat.comet never 
gets set. The docs for it doesn't say I have to set this attribute. so 
without reverse engineering the source code, it would be hard to 
implement this. Granted some of the complexity could just be lack of 
documentation.
So by implementing CometProcessor or extending CometServlet, I think we 
can safely assume that the request is a comet request instead of having 
to explicitly call request.setAttribute,

we can still use the attribute internally.


About 1) and 2), I thought about it and it is indeed possible to 
remove the attribute, but more explicit mechanisms looked less error 
prone to me (after all, there are plenty of people out there who flush 
and close the request at the end of their service methods ...). It 
also gives a choice to the user to trigger or not comet IO based on 
some other things.
flush I can see, but close in a comet I can't, there is no way to send 
additional data after close is called, as that is a output stream close 
method.

calling close, will/should eventually trigger event(END).




What I really have a problem with is the many event types, since 
adding more adds complexity for the application code: for starters, 
the many error types (besides error and timeout, anything extra 
seems useless to me) and shutdown (this portion of the code does not 
have any business to get this sort of notifications, especially 
differentiating between shutdown types). As you said it, it's still 
actually down to 3 useful events: read, error and shutdown (aka, end).
I agree on the types, that is why I mention main and sub types, for 
the main. The sub types can be useful, cause an implementation may 
want to know why the request is ended or error:ed out. Its important, 
cause a simple connection timeout, the webapp developer might wanna 
keep his "push data" in a queue to push once the client opens a new 
connection. But if the webapp is reloaded, that queue should be 
emptied out and reloaded upon start again. (for example, today 
request attributes could throw a ClassCastException upon webapp 
reload, but if there was an event, the developer could actually clear 
those attributes out and reload them later). So the lifecycle of a 
comet servlet, is slightly different than a servlet.


Ok.

I need to noodle on it some more to see how this ca

DO NOT REPLY [Bug 40257] - tomcat 5.0.28 to 5.5.17 upgrade - Tomcat Manager Context Deployment does not work

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=40257





--- Additional Comments From [EMAIL PROTECTED]  2006-08-16 16:10 ---

Tomcat 5.5.17 changed code with respect to deploy command. But documentation 
did not reflect it.

 

Deploy works if the url specified 

 

a. With jar prefix removed 

b. default path added at the end

 

http://localhost:8080/manager/deploy?
config=file:/path/context.xml&war=file:/path/bar.war&path=/bar
 
Can you please fix the documentation please?







(In reply to comment #0)
> We are trying to use tomcat manager feature.
> http://tomcat.apache.org/tomcat-5.5-doc/manager-howto.html#Deploy%20A%20New%
> 20Application%20Remotely
> Deploy A New Application from a Local Path
> Deploy using a Context configuration ".xml" file
> Here is an example of deploying an application using a Context 
> configuration ".xml" file and a web application ".war" file located on the 
> server. 
> http://localhost:8080/manager/deploy?

> config=file:/path/context.xml&war=jar:file:/path/bar.war!/
> This feature works in 5.0.28.  We are tryng to upgrade to 5.5.17 tomcat 
> We are seeing following error. "Invalid context path was specified" 
> Looks like this is tomcat manager bug.
> Need help!!



-- 
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 40265] - files are sometimes not delivered by a servlet specified in web.xml

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=40265





--- Additional Comments From [EMAIL PROTECTED]  2006-08-16 17:43 ---
Thank you for solving this Bug: changing the attribute fixes the behaviour.

But i have read the documentation. There is mentioned, that every directory
containing a WEB-INF/web.xml is deployed as context. Can you describe how this
can cause the effect of this bug?

Auto-deploy of webapps was already there in tomcat 5.0. There my example webapp
works fine. So something must have changed (in a way that is at least
incompatible with tomcat 5.0).

I think the detection of weather the directoray is a webapp or not might be 
broken.

Michael.

-- 
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

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:
flush I can see, but close in a comet I can't, there is no way to send 
additional data after close is called, as that is a output stream close 
method.

calling close, will/should eventually trigger event(END).


Ok, I will make those changes.

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r432054 - in /tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector: OutputBuffer.java Response.java

[remm]

Author: remm
Date: Wed Aug 16 15:29:09 2006
New Revision: 432054

URL: http://svn.apache.org/viewvc?rev=432054&view=rev
Log:
- Expose the closed flag.

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/OutputBuffer.java
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/OutputBuffer.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/OutputBuffer.java?rev=432054&r1=432053&r2=432054&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/OutputBuffer.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/OutputBuffer.java 
Wed Aug 16 15:29:09 2006
@@ -201,6 +201,16 @@
 }
 
 
+/**
+ * Is the response output closed ?
+ * 
+ * @return closed flag value
+ */
+public boolean isClosed() {
+return this.closed;
+}
+
+
 // - Public Methods
 
 

Modified: tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java?rev=432054&r1=432053&r2=432054&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java Wed 
Aug 16 15:29:09 2006
@@ -433,6 +433,14 @@
 
 
 /**
+ * Closed flag accessor.
+ */
+public boolean isClosed() {
+return outputBuffer.isClosed();
+}
+
+
+/**
  * Set the error flag.
  */
 public void setError() {



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Proposal - Comet changes

[Remy Maucherat]

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:
flush I can see, but close in a comet I can't, there is no way to send 
additional data after close is called, as that is a output stream 
close method.

calling close, will/should eventually trigger event(END).


Ok, I will make those changes.


And I don't see any way to do it other than adding a begin and an end 
action in ActionCode.


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Proposal - Comet changes

[Filip Hanik - Dev Lists]

Remy Maucherat wrote:

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:
flush I can see, but close in a comet I can't, there is no way to 
send additional data after close is called, as that is a output 
stream close method.

calling close, will/should eventually trigger event(END).


Ok, I will make those changes.


And I don't see any way to do it other than adding a begin and an end 
action in ActionCode.
I did it in the NIO connector fairly easily, cause in there the socket 
is associated with a key, and the key has several attributes, so I just 
told the key to timeout.
But using the ActionCode might be a be better solution, as we can apply 
it more easily to all connectors.


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: Proposal - Comet changes

[Filip Hanik - Dev Lists]

Filip Hanik - Dev Lists wrote:

Remy Maucherat wrote:

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:
flush I can see, but close in a comet I can't, there is no way to 
send additional data after close is called, as that is a output 
stream close method.

calling close, will/should eventually trigger event(END).


Ok, I will make those changes.


And I don't see any way to do it other than adding a begin and an end 
action in ActionCode.
I did it in the NIO connector fairly easily, cause in there the socket 
is associated with a key, and the key has several attributes, so I 
just told the key to timeout.
But using the ActionCode might be a be better solution, as we can 
apply it more easily to all connectors.
what am I thinking, all connectors, so far only the connectors 
supporting poll are valid candidates for comet :)




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: change in session activity tracking between Tomcat 4.1/5.0 and Tomcat 5.5

[Jan Luehe]

Hi Dies,

Dies Koper wrote On 08/16/06 05:28,:

>Hello,
>
>I'm looking into an issue we ran into when upgrading from Tomcat 4.1 to
>Tomcat 5.5.
>
>The time returned by the HttpSession.getLastAccessTime method seems to
>have changed.
>We believe it should return the time of the previous request from the
>same client. It did in Tomcat 4.1. It did so no matter whether that
>client accessed a Servlet or an html file.
>
>However, in Tomcat 5.5 it only returns this time if the previous request
>went to a servlet, and that servlet called the getSession or
>request.encodeURL method. Otherwise it returns the time of the last
>request from that client that did call either of those methods.
>  
>

I think this change was made to bring the impl in compliance with the
servlet
spec.

The javadocs of HttpSession.getLastAccessedTime() have this:

* Returns the last time the client sent a request associated with
* this session, as the number of milliseconds since midnight
* January 1, 1970 GMT, and marked by the time the container received the
* request.

Notice the "associated with this session".

Only if a request creates or resumes a session should the session's
lastAccessedTime
be updated.


Jan


>I am a bit confused why. Did the Tomcat developers disagree with the
>Servlet spec or the interpretation of it at the time Tomcat 4.1 was
>released and is this now fixed? Or is it an accidental side-effect of
>another change?
>
>The reason I ask is because I need to solve this problem. Should I look
>for a work-around or try to write a patch?
>
>So far, I found that the change happened in Tomcat 5.0, with the
>following commit.
>
>Revision: 302627
>Author: remm
>Date: 3:21:36, 2004-01-23
>Message:
>- Improvements to session activity tracking, handling the case where the
>  session is new, as well as cross context.
>- If this doesn't work, I give up ;)
>
>Modified :
>/tomcat/container/catalina/trunk/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
>Modified :
>/tomcat/container/catalina/trunk/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java
>Modified :
>/tomcat/container/catalina/trunk/catalina/src/share/org/apache/catalina/core/StandardHostValve.java
>Modified :
>/tomcat/container/catalina/trunk/catalina/src/share/org/apache/catalina/session/StandardSession.java
>
>Thanks,
>Dies
>
>
>-
>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]

[EMAIL PROTECTED]: Project tomcat-tc6 (in module tomcat-tc6) failed

[Bill Barker]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project tomcat-tc6 has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-tc6 :  Java Servlet 2.5 & Server Pages JSP 2.1 implementation (for 
...


Full details are available at:
http://vmgump.apache.org/gump/public/tomcat-tc6/tomcat-tc6/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -INFO- Failed with reason build failed
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/tomcat-tc6/tomcat-tc6/gump_work/build_tomcat-tc6_tomcat-tc6.html
Work Name: build_tomcat-tc6_tomcat-tc6 (Type: Build)
Work ended in a state of : Failed
Elapsed: 37 secs
Command Line: java -Djava.awt.headless=true org.apache.tools.ant.Main 
-Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only 
-Dtomcat-native.tar.gz=/usr/local/gump/public/workspace/tomcat-tc6/README.txt 
-Dcommons-logging-api.jar=/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-16082006.jar
 
-Dtomcat-dbcp.jar=/usr/local/gump/public/workspace/tomcat-tc6/tomcat-deps/tomcat-jdbc-16082006.jar
 
-Djasper-jdt.jar=/usr/local/gump/packages/eclipse-3.1M6/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar
 
[Working Directory: /usr/local/gump/public/workspace/tomcat-tc6]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/tomcat-tc6/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/packages/javamail-1.4/mail.jar:/usr/local/gump/packages/javamail-1.4/lib/mailapi.jar:/usr/local/gump/packages/jaf-1.1ea/activation.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-16082006.jar:/usr/local/gump/packages/eclipse-3.1M6/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar:/usr/local/gump/public/workspace/tomcat-tc6/tomcat-deps/tomcat-jdbc-16082006.jar
-
[javac] public void init(FilterConfig filterConfig) {
[javac]  ^
[javac] 
/x1/gump/public/workspace/tomcat-tc6/webapps/examples/WEB-INF/classes/compressionFilters/CompressionFilter.java:126:
 cannot find symbol
[javac] symbol  : class ServletRequest
[javac] location: class compressionFilters.CompressionFilter
[javac] public void doFilter ( ServletRequest request, ServletResponse 
response,
[javac]^
[javac] 
/x1/gump/public/workspace/tomcat-tc6/webapps/examples/WEB-INF/classes/compressionFilters/CompressionFilter.java:126:
 cannot find symbol
[javac] symbol  : class ServletResponse
[javac] location: class compressionFilters.CompressionFilter
[javac] public void doFilter ( ServletRequest request, ServletResponse 
response,
[javac]^
[javac] 
/x1/gump/public/workspace/tomcat-tc6/webapps/examples/WEB-INF/classes/compressionFilters/CompressionFilter.java:127:
 cannot find symbol
[javac] symbol  : class FilterChain
[javac] location: class compressionFilters.CompressionFilter
[javac] FilterChain chain ) throws IOException, 
ServletException {
[javac] ^
[javac] 
/x1/gump/public/workspace/tomcat-tc6/webapps/examples/WEB-INF/classes/compressionFilters/CompressionFilter.java:127:
 cannot find symbol
[javac] symbol  : class ServletException
[javac] location: class compressionFilters.CompressionFilter
[javac] FilterChain chain ) throws IOException, 
ServletException {
[javac] ^
[javac] 
/x1/gump/public/workspace/tomcat-tc6/webapps/examples/WEB-INF/classes/compressionFilters/CompressionFilter.java:205:
 cannot find symbol
[javac] symbol  : class FilterConfig
[javac] location: class compressionFilters.CompressionFilter
[javac] public void setFilterConfig(FilterConfig filterC

[EMAIL PROTECTED]: Project tomcat-tc6 (in module tomcat-tc6) failed

[Bill Barker]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project tomcat-tc6 has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-tc6 :  Java Servlet 2.5 & Server Pages JSP 2.1 implementation (for 
...


Full details are available at:
http://vmgump.apache.org/gump/public/tomcat-tc6/tomcat-tc6/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -INFO- Failed with reason build failed
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/tomcat-tc6/tomcat-tc6/gump_work/build_tomcat-tc6_tomcat-tc6.html
Work Name: build_tomcat-tc6_tomcat-tc6 (Type: Build)
Work ended in a state of : Failed
Elapsed: 37 secs
Command Line: java -Djava.awt.headless=true org.apache.tools.ant.Main 
-Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only 
-Dtomcat-native.tar.gz=/usr/local/gump/public/workspace/tomcat-tc6/README.txt 
-Dcommons-logging-api.jar=/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-16082006.jar
 
-Dtomcat-dbcp.jar=/usr/local/gump/public/workspace/tomcat-tc6/tomcat-deps/tomcat-jdbc-16082006.jar
 
-Djasper-jdt.jar=/usr/local/gump/packages/eclipse-3.1M6/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar
 
[Working Directory: /usr/local/gump/public/workspace/tomcat-tc6]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/tomcat-tc6/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/packages/javamail-1.4/mail.jar:/usr/local/gump/packages/javamail-1.4/lib/mailapi.jar:/usr/local/gump/packages/jaf-1.1ea/activation.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-16082006.jar:/usr/local/gump/packages/eclipse-3.1M6/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar:/usr/local/gump/public/workspace/tomcat-tc6/tomcat-deps/tomcat-jdbc-16082006.jar
-
[javac] public void init(FilterConfig filterConfig) {
[javac]  ^
[javac] 
/x1/gump/public/workspace/tomcat-tc6/webapps/examples/WEB-INF/classes/compressionFilters/CompressionFilter.java:126:
 cannot find symbol
[javac] symbol  : class ServletRequest
[javac] location: class compressionFilters.CompressionFilter
[javac] public void doFilter ( ServletRequest request, ServletResponse 
response,
[javac]^
[javac] 
/x1/gump/public/workspace/tomcat-tc6/webapps/examples/WEB-INF/classes/compressionFilters/CompressionFilter.java:126:
 cannot find symbol
[javac] symbol  : class ServletResponse
[javac] location: class compressionFilters.CompressionFilter
[javac] public void doFilter ( ServletRequest request, ServletResponse 
response,
[javac]^
[javac] 
/x1/gump/public/workspace/tomcat-tc6/webapps/examples/WEB-INF/classes/compressionFilters/CompressionFilter.java:127:
 cannot find symbol
[javac] symbol  : class FilterChain
[javac] location: class compressionFilters.CompressionFilter
[javac] FilterChain chain ) throws IOException, 
ServletException {
[javac] ^
[javac] 
/x1/gump/public/workspace/tomcat-tc6/webapps/examples/WEB-INF/classes/compressionFilters/CompressionFilter.java:127:
 cannot find symbol
[javac] symbol  : class ServletException
[javac] location: class compressionFilters.CompressionFilter
[javac] FilterChain chain ) throws IOException, 
ServletException {
[javac] ^
[javac] 
/x1/gump/public/workspace/tomcat-tc6/webapps/examples/WEB-INF/classes/compressionFilters/CompressionFilter.java:205:
 cannot find symbol
[javac] symbol  : class FilterConfig
[javac] location: class compressionFilters.CompressionFilter
[javac] public void setFilterConfig(FilterConfig filterC

Re: change in session activity tracking between Tomcat 4.1/5.0 and Tomcat 5.5

[Dies Koper]

Hello Jan,

Thank you for your reply.

Yes, I noticed the "associated with this session". It seemed clear. But
then I read the following in the specification:

[Servlet 2.4 spec - SRV.7.6 Last Accessed Times]
The session is considered to be accessed when a request that is part of
the session is first handled by the servlet container.

I noticed "request that is part of the session".
Is a request with a jsessionid that gets accepted by the container part
of a session? I'd say yes. But you say it is not, until the servlet
calls a method that needs to access the session context (getSession,
encodeURL, etc.), only then you can say it actually was part of the session?
I suppose that does sounds reasonable.

> I think this change was made to bring the impl in compliance with the
> servlet spec.

The servlet 2.3 spec contains the same. So Tomcat 4.1 does not but
Tomcat 5.0/5.5 now does comply with the spec regarding this method?
#I had opened a bug about this last month, I'd like to add this info to
it for reference before it is closed.

Just to make sure, you /think/ this change was done because you have
some recollection of it or guessing from what I wrote and what the spec
writes?
I tried searching the mailing lists about it but could not find any
discussion about it.

Thank again for the reply,
Dies


Jan Luehe wrote:
> Hi Dies,
> 
> Dies Koper wrote On 08/16/06 05:28,:
> 
>> Hello,
>>
>> I'm looking into an issue we ran into when upgrading from Tomcat 4.1 to
>> Tomcat 5.5.
>>
>> The time returned by the HttpSession.getLastAccessTime method seems to
>> have changed.
>> We believe it should return the time of the previous request from the
>> same client. It did in Tomcat 4.1. It did so no matter whether that
>> client accessed a Servlet or an html file.
>>
>> However, in Tomcat 5.5 it only returns this time if the previous request
>> went to a servlet, and that servlet called the getSession or
>> request.encodeURL method. Otherwise it returns the time of the last
>> request from that client that did call either of those methods.
>>  
>>
> 
> I think this change was made to bring the impl in compliance with the
> servlet
> spec.
> 
> The javadocs of HttpSession.getLastAccessedTime() have this:
> 
> * Returns the last time the client sent a request associated with
> * this session, as the number of milliseconds since midnight
> * January 1, 1970 GMT, and marked by the time the container received the
> * request.
> 
> Notice the "associated with this session".
> 
> Only if a request creates or resumes a session should the session's
> lastAccessedTime
> be updated.
> 
> 
> Jan
> 
> 
>> I am a bit confused why. Did the Tomcat developers disagree with the
>> Servlet spec or the interpretation of it at the time Tomcat 4.1 was
>> released and is this now fixed? Or is it an accidental side-effect of
>> another change?
>>
>> The reason I ask is because I need to solve this problem. Should I look
>> for a work-around or try to write a patch?
>>
>> So far, I found that the change happened in Tomcat 5.0, with the
>> following commit.
>>
>> Revision: 302627
>> Author: remm
>> Date: 3:21:36, 2004-01-23
>> Message:
>> - Improvements to session activity tracking, handling the case where the
>>  session is new, as well as cross context.
>> - If this doesn't work, I give up ;)
>> 
>> Modified :
>> /tomcat/container/catalina/trunk/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
>> Modified :
>> /tomcat/container/catalina/trunk/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java
>> Modified :
>> /tomcat/container/catalina/trunk/catalina/src/share/org/apache/catalina/core/StandardHostValve.java
>> Modified :
>> /tomcat/container/catalina/trunk/catalina/src/share/org/apache/catalina/session/StandardSession.java


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]