DO NOT REPLY [Bug 41432] - Webdav servlet does not work correctly with Windows XP webdav redirector.

[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=41432


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |




--- Additional Comments From [EMAIL PROTECTED]  2007-01-24 00:46 ---
I think that this bug is correct.

As far as I know, the syntax file://server/directory is the correct one to
access Webdav folders in Windows. It is first translated internally to the UNC
syntax \\server\directory, which is then understood by the Windows XP Webdav
filesystem driver.

The first fact, the translation of file://server/directory URLs to Windows UNC
path \\server\directory is documented in the Internet Explorer blog entry "File
URIs in Windows"
http://blogs.msdn.com/ie/archive/2006/12/06/file-uris-in-windows.aspx

The interpretation of UNC paths as Webdav folders under Windows XP is
documented, for instance, in KB article "How documents are opened from a Web
site in Office 2003" http://support.microsoft.com/kb/838028 (the article
explains that, when an UNC path is actually a WebDAV folder, then Office 2003
access it through the WebDAV protocol rather than through the normal filesystem
interface of the operating system.

When I say Apache WebDAV I mean httpd + mod_dav. Sorry for the ambiguity.

-- 
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 39636] - mod_jk does not pass SSL client certificate chain to AJP connector

[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=39636


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Attachment #18458|0   |1
is obsolete||




--- Additional Comments From [EMAIL PROTECTED]  2007-01-24 03:34 ---
Created an attachment (id=19447)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19447&action=view)
Patch for tomcat-connectors-1.2.20


-- 
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 39636] - mod_jk does not pass SSL client certificate chain to AJP connector

[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=39636


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Keywords||PatchAvailable
 Resolution|LATER   |




--- Additional Comments From [EMAIL PROTECTED]  2007-01-24 03:47 ---
Since version 1.2.19, the header package size limit of 8k is not an issue
anymore. Therefore this patch has become a topic a again (together with the
patch for bug #39637).

-- 
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 39637] - AJP13 connector does not handle chain of SSL client certificate

[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=39637


Bug 39637 depends on bug 39636, which changed state.

Bug 39636 Summary: mod_jk does not pass SSL client certificate chain to AJP 
connector
http://issues.apache.org/bugzilla/show_bug.cgi?id=39636

   What|Old Value   |New Value

 Status|RESOLVED|REOPENED
 Resolution|LATER   |



-- 
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: Comet API and InputStream.available()

[Christophe Pierret]

Here is what I understood:

Assumption #1:

When you receive a CometEvent.EventType.READ event, you can always read() at 
least one byte from the request's InputStream without blocking.

Is this correct ?
If not correct, then this mail goes directly to trash (and sorry for the 
inconvenience...)

If correct, then returning 1 for InputStream.available() in this context makes 
sense and gives an indication that a read can occur without blocking (without 
the need to convey the same information by a side-channel).
For reference: http://java.sun.com/j2se/1.4.2/docs/api/java/io/InputStream.html 
for InputStream.available() method contract with the caller. 

Note that available() returning 0 makes sense also. In this context, it means 
"I cannot guarantee that you can read without blocking".
But returning 0 will force the Comet API user to use the kind of hack I used, 
e.g.: I have read in the Comet API doc that I can read at least one byte 
without blocking and I will use another channel to convey information about it.
For example: 
public void doOnlyNonBlockingReads(InputStream is, boolean 
canReadOneByteEvenIfAvailableReturns0)

The fact that data is not yet read "under the hood" is not an issue as long as 
Assumption#1 is correct, you can read one byte of data without blocking, when 
you decide to call one of the read() methods.

I believe that when making a blocking read in a thread would be a critical 
issue, one should never call InputStream.read() methods if 
InputStream.available() returns 0 ... You simply don't have the guarantee that 
it won't block.

If you don't think that returning 1 for available() in the 
"CometEvent.EventType.READ event case" is a good thing, then 
I can live with a hack in my code ;^) 
I just believe this would make the Comet API better for others and easier to 
use. 
Reading the data on socket before going into the READ event could also be a 
solution to this kind of issue but raises other kind of problems.

Christophe

-Message d'origine-
De : Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED] 
Envoyé : mardi 23 janvier 2007 18:14
À : Tomcat Developers List
Objet : Re: Comet API and InputStream.available()

ok, I'm confused, why would available return 1 when there is no data to be read?
the values for available are
 >0 data to be read
0 no data to be read
-1 end of stream reached

I don't think we have -1 in our values, as that would only happen if the client 
closed the connection, and at that point we will probably call another event, 
although initially I know the NIO connector calls read with 0 data to be read

Filip

Christophe Pierret wrote:
> I suggest a minor update to the behaviour exhibited by the 
> CoyoteInputStream.available() method when called from inside a Comet.READ 
> event.
> Instead of returning 0 on first call (before trying to read), available() 
> should return 1 when initially called, as it seems guaranteed that reading 
> one byte won't block.  It is still consistent with InputStream.available() 
> documentation :
> *  Returns the number of bytes that can be read (or skipped over) from this 
> input stream without blocking by the next caller of a method for this input 
> stream.
>
> When first read occurs, it should then return the real available bytes.
>
> I had to implement this behaviour myself when using Comet API in my product, 
> since I already had a working implementation for a fragmented packet reader 
> based on ByteBuffer (done for NIO kind of IO). 
> In this case available() would return byteBuffer.limit() - 
> byteBuffer.position().
>
> Please have a look at code fragment at the end of mail to get the idea.
> I call InputStreamByteBuffer.setInputStream() only once for each Comet.READ 
> event.
> Since I cannot afford to do a blocking read, I loop while( (avail= 
> myInputStreamByteBuffer.available())==0 ) and read inside the loop until 
> (avail - count_bytes_read) ==0 ...
> My InputStream adapter code is a bit too much convoluted for my taste, but it 
> currently works with Comet/CoyoteInputStream.
>
> I think that implementing this kind of behaviour in Tomcat in the InputStream 
> returned by HttpServletRequest.getInputStream() would be a good thing.
> It could be done either by writing a wrapper around CoyoteInputStream or by 
> adding some extra (optional) behaviour to CoyoteInputStream activated only 
> when inside a Comet read, or by doing it at the InputBuffer level.
>
> What do you think of this idea ?
> If you agree, I volunteer to test the updated code (or even propose a patch 
> for it).
>
> Here is the code fragment excerpted from my Inputstream adaptator:
> public static class InputStreamByteBuffer implements IByteBuffer
> {
> private InputStream inputStream;
> private boolean fixTomcatAvailable;
> InputStreamByteBuffer(InputStream is)
> {
> this.inputStream = is;
> fixTomcatAvailable = true;
> }
>
> public InputStream getInputS

DO NOT REPLY [Bug 41447] - path element in new context.xml files

[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=41447


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2007-01-24 04:20 ---
Bugzilla is not a support forum. User questions belong to the Tomcat User
mailing list. Read the comments to your post there.

-- 
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 41447] - It's not possible to deploy a WAR file to a multi-level context path

[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=41447


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|critical|enhancement
 Status|RESOLVED|REOPENED
 OS/Version|Windows XP  |All
 Resolution|INVALID |
Summary|path element in new |It's not possible to deploy
   |context.xml files   |a WAR file to a multi-level
   ||context path




--- Additional Comments From [EMAIL PROTECTED]  2007-01-24 05:40 ---
As already stated on the Users list, my comment there was wrong. I also couldn't
find a way of deploying a WAR file with a multi-level context path.
Provided there really is no way to achieve this, I'm not sure whether this
should be seen as a regression (as it was possible with Tomcat < 5.5) or as an
enhancement request (since it doesn't seem to be documented that this should be
possible at all).

-- 
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: Comet API and InputStream.available()

[Remy Maucherat]

Christophe Pierret wrote:

Here is what I understood:

Assumption #1:  When you receive a
CometEvent.EventType.READ event, you can always read() at least one
byte from the request's InputStream without blocking.

Is this correct ? If not correct, then this mail goes directly to
trash (and sorry for the inconvenience...)


It's not 100% correct: you may do one blocking read without waiting for 
client input (as the poller signaled data was available). However, the 
InputStream that is given to you in the Servlet is a buffered stream 
that has no relation with the socket. I don't like the idea of returning 
"1", which is a hack. The only non hack way of doing it is to do the 
read somewhere (in CometAdapter.event) to fill the buffer of the input 
stream before calling the Servlet.


At the moment, I use this read method (which is compatible with both 
behaviors of available()) in the chat servlet from the examples:

do {
int n = is.read(buf);
if (n > 0) {
log("Read " + n + " bytes: " + new String(buf, 0, n)
+ " for session: " + 
request.getSession(true).getId());

} else if (n < 0) {
// Error: do cleanup
event.close();
return;
}
} while (is.available() > 0);

Rémy


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

DO NOT REPLY [Bug 40356] - expressions in XML attributes evaluated in wrong order

[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=40356





--- Additional Comments From [EMAIL PROTECTED]  2007-01-24 07:11 ---
XML processors do not need to report the order of attributes. An XML based
language that assigns semantics to the ordering of XML attributes thus would be
severely broken (no idea whether this applies here; I just wanted to clarify
from an XML point of view).


-- 
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 41447] - It's not possible to deploy a WAR file to a multi-level context path

[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=41447





--- Additional Comments From [EMAIL PROTECTED]  2007-01-24 09:03 ---
Works for me.  When you're deploying webapps via context files (e.g.
conf/Catalina/localhost/contextname.xml) you need to move your war file (or
exploded webapp dir) OUTSIDE of the your defined appBase directory or else it
won't work properly.

You should be able to make you app work by doing the following:

- move your war to a location outside of $CATALINA_HOME/webapps (or whatever you
have 'appBase' set to)
- update your context descriptor to point to /path/to/your/war
- restart

-- 
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 41452] New: - JkMount /*/servlet/ xxxx doesn't detect need to connect

[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=41452

   Summary: JkMount /*/servlet/  doesn't detect need to connect
   Product: Tomcat 5
   Version: 5.5.17
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Native:JK
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Apache 2.2.4

Downloaded mod_jk-apache-2.2.3.so 1/23/07 from Win32 folder on tomcat 
site/mirror, renamed to mod_jk.so and moved to Apache2/./modules

Created workers.properties and updated Apache2/conf/httpd.conf per your 
instructions including among others:

JkMount /*/servlet/ UnderNetBeans 
JkMount /*.jsp UnderNetBeans

Testing of 'JkMount /*.jsp' worked successfully
Testing of 'JkMount /*/servlet' failed Http 404 from Apache Http (didn't 
connect to Tomcat)
Testing of 'JkMount /hpltest/servlet/HelloWorldExample' instead 
of 'JkMount /*/servlet' (the only change) worked successfully, connecting to 
Tomcat and seeeming to rule out setup/connection/deploy issues.

mod_jk.log shows for failed attempt:

"[Wed Jan 24 10:36:15 2007] [4776:0776] [debug] jk_uri_worker_map.c (423): rule 
map size is 2
[Wed Jan 24 10:36:15 2007] [4776:0776] [debug] jk_uri_worker_map.c (364): 
wildchar rule '/*/servlet/=UnderNetBeans' source 'JkMount' was added
[Wed Jan 24 10:36:15 2007] [4776:0776] [debug] jk_uri_worker_map.c (364): 
wildchar rule '/*.jsp=UnderNetBeans' source 'JkMount' was added"  No send 
issued.

Workaround 'JkMount /hpltest/servlet/HelloWorldExample UnderNetBeans' with no 
wildcards worked successfully, connecting to Tomcat and displaying valid 
servlet results.

mod_jk.log shows for succesfull attempt:

"[Wed Jan 24 10:38:08 2007] [5176:0360] [debug] jk_uri_worker_map.c (423): rule 
map size is 2
[Wed Jan 24 10:38:08 2007] [5176:0360] [debug] jk_uri_worker_map.c (372): exact 
rule '/hpltest/servlet/HelloWorldExample=UnderNetBeans' source 'JkMount' was 
added
[Wed Jan 24 10:38:08 2007] [5176:0360] [debug] jk_uri_worker_map.c (364): 
wildchar rule '/*.jsp=UnderNetBeans' source 'JkMount' was added"  Send issued.

Both full logs are available.

-- 
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 41452] - JkMount /*/servlet/ xxxx doesn't detect need to connect

[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=41452





--- Additional Comments From [EMAIL PROTECTED]  2007-01-24 09:47 ---
Created an attachment (id=19448)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19448&action=view)
Log of failed test


-- 
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 41452] - JkMount /*/servlet/ xxxx doesn't detect need to connect

[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=41452





--- Additional Comments From [EMAIL PROTECTED]  2007-01-24 09:47 ---
Created an attachment (id=19449)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19449&action=view)
Log of successful test


-- 
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 41452] - JkMount /*/servlet/ xxxx doesn't detect need to connect

[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=41452


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2007-01-24 09:58 ---
Try /*/servlet/* first. Your pattern does not match the requested URL.

-- 
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 41447] - It's not possible to deploy a WAR file to a multi-level context path

[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=41447


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2007-01-24 10:18 ---
(In reply to comment #3)
> You should be able to make you app work by doing the following:
> 
> - move your war to a location outside of $CATALINA_HOME/webapps (or whatever 
> you
> have 'appBase' set to)
> - update your context descriptor to point to /path/to/your/war
> - restart

You're right. This works.
Thanks for the explanation.

-- 
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: Comet API and InputStream.available()

[Christophe Pierret]

OK, I understand your rationale.
It is a tough job to retrofit asynchronous IOs in a synchronous framework like 
the "servlet specification" and you did great given the constraints !
Continue the good job...
  Christophe


-Message d'origine-
De : Remy Maucherat [mailto:[EMAIL PROTECTED] 
Envoyé : mercredi 24 janvier 2007 14:48
À : Tomcat Developers List
Objet : Re: Comet API and InputStream.available()

Christophe Pierret wrote:
> Here is what I understood:
> 
> Assumption #1:  When you receive a 
> CometEvent.EventType.READ event, you can always read() at least one 
> byte from the request's InputStream without blocking.
> 
> Is this correct ? If not correct, then this mail goes directly to 
> trash (and sorry for the inconvenience...)

It's not 100% correct: you may do one blocking read without waiting for client 
input (as the poller signaled data was available). However, the InputStream 
that is given to you in the Servlet is a buffered stream that has no relation 
with the socket. I don't like the idea of returning "1", which is a hack. The 
only non hack way of doing it is to do the read somewhere (in 
CometAdapter.event) to fill the buffer of the input stream before calling the 
Servlet.

At the moment, I use this read method (which is compatible with both behaviors 
of available()) in the chat servlet from the examples:
 do {
 int n = is.read(buf);
 if (n > 0) {
 log("Read " + n + " bytes: " + new String(buf, 0, n)
 + " for session: " + request.getSession(true).getId());
 } else if (n < 0) {
 // Error: do cleanup
 event.close();
 return;
 }
 } while (is.available() > 0);

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: Comet API and InputStream.available()

[Filip Hanik - Dev Lists]

In most cases, almost all cases there will be data to be read when a 
READ event occurs.
An example where there is none, is when we recieve a request, and there 
is no data in the body yet.
as we parse the GET request, we invoke READ so that you can read any 
client data, if any.

And that is the case when it returns 0, a fully valid use case.

Filip

Christophe Pierret wrote:

OK, I understand your rationale.
It is a tough job to retrofit asynchronous IOs in a synchronous framework like the 
"servlet specification" and you did great given the constraints !
Continue the good job...
  Christophe


-Message d'origine-
De : Remy Maucherat [mailto:[EMAIL PROTECTED] 
Envoyé : mercredi 24 janvier 2007 14:48

À : Tomcat Developers List
Objet : Re: Comet API and InputStream.available()

Christophe Pierret wrote:
  

Here is what I understood:

Assumption #1:  When you receive a 
CometEvent.EventType.READ event, you can always read() at least one 
byte from the request's InputStream without blocking.


Is this correct ? If not correct, then this mail goes directly to 
trash (and sorry for the inconvenience...)



It's not 100% correct: you may do one blocking read without waiting for client input (as 
the poller signaled data was available). However, the InputStream that is given to you in 
the Servlet is a buffered stream that has no relation with the socket. I don't like the 
idea of returning "1", which is a hack. The only non hack way of doing it is to 
do the read somewhere (in CometAdapter.event) to fill the buffer of the input stream 
before calling the Servlet.

At the moment, I use this read method (which is compatible with both behaviors 
of available()) in the chat servlet from the examples:
 do {
 int n = is.read(buf);
 if (n > 0) {
 log("Read " + n + " bytes: " + new String(buf, 0, n)
 + " for session: " + request.getSession(true).getId());
 } else if (n < 0) {
 // Error: do cleanup
 event.close();
 return;
 }
 } while (is.available() > 0);

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: Jasper: Using a non-File based environment

[Felix Meschberger]

Hi,

Sorry to not have replied earlier - I was very much distracted into the
underwoods 

On 11/17/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:


File abstraction is already present in Tomcat (for example, JSP used to
run on top of Slide), so you can have all webapp resources loaded from a
repository of your choice, rather than the filesystem.



Agreed.

If you want generated source and classes to be stored in the repository,

then I really don't see the point. For starters, it's an implementation
detail which could go away.



I agree with the second point. For the first point - why not storing the
java sources and class files in the filesystem: We are building a system
ontop of JCR which supports staging with replication. We will have separate
development, author and publishing systems, where JSP development generally
take place on the development system. There are use cases, where we would
not want to replicate the JSP sources but the JSP class files. In these
cases, having the class files in the repository would allow us to use the
same mechanics for this.

Regards
Felix

Possible javax.servlet.http.HttpServlet bugs, and where to report them?

[Mike Kaufman]

I think there's a bug in javax.servlet.http.HttpServlet, but I'm not 
sure where to report it. I'm posting this here for the time being (and 
possibly on the Glassfish "issue tracker" if and when I can jump through 
the hoops required to do so), but please let me know if it ought to be 
reported some other way: and apologies if this doesn't belong here!


The actual bug is that the "NoBodyResponse" inner class within 
HttpServlet doesn't track whether getWriter or getOutput stream have 
been called, and doesn't alter the response's behaviour accordingly.


This differs from the ServletResponse Javadoc which states that:
- Calls to getWriter are supposed to throw IllegalStateException if 
getOutputStream has already been called and vice-versa.
- The behaviour of various other methods depend on whether or not 
getWriter has already been called (e.g. setCharacterEncoding is supposed 
to have no effect if getWriter has already been called).


As a result, HTTP "HEAD" requests may complete successfully where an 
identical "GET" would fail with an IllegalStateException, or "HEAD" and 
"GET" may result in different headers (and different results from 
methods such as getCharacterEncoding whilst processing the request).


A more general issue is that the NoBodyResponse class could, and perhaps 
should (to conform to SRV 8.2 of the Servlet specification), be a 
ServletResponseWrapper subclass. At the very least this would shorten 
and simplify its code. The Apache Tomcat bug database includes a couple 
of entries for this (Tomcat 4 bug 10555 and Tomcat 5 bug 22290), and 
although these have long since been "closed" on the basis that this code 
is the responsibility of the Servlet API itself rather than Tomcat, and 
therefore these bugs were handed over to the Servlet API feedback e-mail 
address "[EMAIL PROTECTED]", I can't find any sign of this 
being followed up anywhere or ever being finally resolved.


This has left me rather unclear as to where to report HttpServlet bugs. 
The code itself doesn't seem to be part of the Servlet specification, 
but is supplied as part of the standard "servlet.jar", "javaee.jar" or 
equivalent; the source code is present and identical in multiple 
versions of Tomcat, and Glassfish, and probably elsewhere; Tomcat bug 
22290 indicates that the Servlet API people are responsible for 
maintaining the code but they only seem to have an e-mail address, which 
itself may be obsolete (I've had no reply to an e-mail sent to it, 
though with e-mails it's always hard to be sure); Tomcat was the 
reference implementation for earlier API versions but now it's Glassfish 
(or is it Sun Java System Application Server?); the code has copyright 
notices for both Sun and Apache; and the Sun bug database has some bug 
reports for HttpServlet but not since Dec 2002, and its bug report form 
doesn't really seem to cater for this.


Sorry, but I'm confused!!! Can anyone give me a definitive answer as to 
where bugs in javax.servlet.http.HttpServlet should be reported?


Whilst we're here, I think there are also some other minor/cosmetic 
issues in the HttpServlet code:
- The "write" method of the NoBodyOutputStream inner class has a comment 
saying that a negative length should "maybe" be an 
IllegalArgumentException, but the code actually throws an IOException. 
If this really should be an IllegalArgumentException, it ought to be 
fixed. If an IOException is OK, or if fixing this now isn't acceptable 
in case it breaks existing code, then maybe the comment should be 
removed (or updated to explain this).
- The "write" method of the NoBodyOutputStream inner class reports 
negative lengths by looking-up an "err.io.negativelength" message, but 
it then ignores the result and instead uses a hard-coded string as the 
actual error message.
- The doTrace method includes a "close" of the output stream when it has 
finished. However, prior to this it sets the content length and then 
writes that amount of content, which should always result in the output 
stream being automatically flushed and closed. Hence the response has 
already been closed when the call to close occurs. Whilst it should 
usually be fairly safe to assume that repeating a close won't do any 
harm, the output stream is implementation-specific, and I can't see 
anything that says it must allow duplicate close attempts (and why 
attempt the close at all if it isn't needed?).
- The doTrace method ends with a "return;" statement, which seems rather 
pointless as the last statement of a method.




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

DO NOT REPLY [Bug 38360] - Domain for session cookies

[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=38360


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[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 37794] - getParameter() fails on POST with transfer-encoding: chunked

[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=37794


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |




--- Additional Comments From [EMAIL PROTECTED]  2007-01-24 15:37 ---
This is really a problem for any POST requests coming out of MIDP where you
cannot change your transfer encoding (its controlled by the device).

Thanks a lot,
-Rushabh

-- 
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 41432] - Webdav servlet does not work correctly with Windows XP webdav redirector.

[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=41432


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||DUPLICATE




--- Additional Comments From [EMAIL PROTECTED]  2007-01-24 17:49 ---
As far as I can tell (I can't find a way to force the file url to use a
different port) this is the same as 36303.

If I try to add a webdav folder as a network place it works perfectly on any
port other than 80. On 80 it fails with exactly the same error message as I get
trying a file url.

All the evidence here points to a MS bug.

*** This bug has been marked as a duplicate of 36303 ***

-- 
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 36303] - webdav servlet does not work when setting port to 80 for the http connector

[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=36303


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2007-01-24 17:49 ---
*** Bug 41432 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: Possible javax.servlet.http.HttpServlet bugs, and where to report them?

[Jan Luehe]

Hi Mike,

thanks for your comments, which I have recorded at:

 https://servlet-spec-eg.dev.java.net/issues/show_bug.cgi?id=40

and

 https://glassfish.dev.java.net/issues/show_bug.cgi?id=2212

I agree with all the problems you've pointed out, and I agree they need
to be fixed.

I think we've inherited the "NoBodyResponse" inner class from one of
the very first servlet releases. I agree this inner class is poorly
designed, in addition to having the bugs you've pointed out.

I very much support the idea of it implementing
javax.servlet.http.HttpServletResponseWrapper. This would be a
backwards-compatible change (since "NoBodyResponse" would continue to
implement javax.servlet.http.HttpServletResponse), would reduce the 
code, and
would also take care of the missing IllegalStateException in connection 
with calling

getWriter() after getOutputStream() (and vice versa).

I'll produce code diffs for javax.servlet.http.HttpServlet and will run them
by the EG and you.

Thanks!


Jan


Mike Kaufman wrote On 01/24/07 12:06 PM,:

I think there's a bug in javax.servlet.http.HttpServlet, but I'm not 
sure where to report it. I'm posting this here for the time being (and 
possibly on the Glassfish "issue tracker" if and when I can jump 
through the hoops required to do so), but please let me know if it 
ought to be reported some other way: and apologies if this doesn't 
belong here!


The actual bug is that the "NoBodyResponse" inner class within 
HttpServlet doesn't track whether getWriter or getOutput stream have 
been called, and doesn't alter the response's behaviour accordingly.


This differs from the ServletResponse Javadoc which states that:
- Calls to getWriter are supposed to throw IllegalStateException if 
getOutputStream has already been called and vice-versa.
- The behaviour of various other methods depend on whether or not 
getWriter has already been called (e.g. setCharacterEncoding is 
supposed to have no effect if getWriter has already been called).


As a result, HTTP "HEAD" requests may complete successfully where an 
identical "GET" would fail with an IllegalStateException, or "HEAD" 
and "GET" may result in different headers (and different results from 
methods such as getCharacterEncoding whilst processing the request).


A more general issue is that the NoBodyResponse class could, and 
perhaps should (to conform to SRV 8.2 of the Servlet specification), 
be a ServletResponseWrapper subclass. At the very least this would 
shorten and simplify its code. The Apache Tomcat bug database includes 
a couple of entries for this (Tomcat 4 bug 10555 and Tomcat 5 bug 
22290), and although these have long since been "closed" on the basis 
that this code is the responsibility of the Servlet API itself rather 
than Tomcat, and therefore these bugs were handed over to the Servlet 
API feedback e-mail address "[EMAIL PROTECTED]", I can't 
find any sign of this being followed up anywhere or ever being finally 
resolved.


This has left me rather unclear as to where to report HttpServlet 
bugs. The code itself doesn't seem to be part of the Servlet 
specification, but is supplied as part of the standard "servlet.jar", 
"javaee.jar" or equivalent; the source code is present and identical 
in multiple versions of Tomcat, and Glassfish, and probably elsewhere; 
Tomcat bug 22290 indicates that the Servlet API people are responsible 
for maintaining the code but they only seem to have an e-mail address, 
which itself may be obsolete (I've had no reply to an e-mail sent to 
it, though with e-mails it's always hard to be sure); Tomcat was the 
reference implementation for earlier API versions but now it's 
Glassfish (or is it Sun Java System Application Server?); the code has 
copyright notices for both Sun and Apache; and the Sun bug database 
has some bug reports for HttpServlet but not since Dec 2002, and its 
bug report form doesn't really seem to cater for this.


Sorry, but I'm confused!!! Can anyone give me a definitive answer as 
to where bugs in javax.servlet.http.HttpServlet should be reported?


Whilst we're here, I think there are also some other minor/cosmetic 
issues in the HttpServlet code:
- The "write" method of the NoBodyOutputStream inner class has a 
comment saying that a negative length should "maybe" be an 
IllegalArgumentException, but the code actually throws an IOException. 
If this really should be an IllegalArgumentException, it ought to be 
fixed. If an IOException is OK, or if fixing this now isn't acceptable 
in case it breaks existing code, then maybe the comment should be 
removed (or updated to explain this).
- The "write" method of the NoBodyOutputStream inner class reports 
negative lengths by looking-up an "err.io.negativelength" message, but 
it then ignores the result and instead uses a hard-coded string as the 
actual error message.
- The doTrace method includes a "close" of the output stream when it 
has finished. However, prior to this it sets the content length and 
then writes

Re: Possible javax.servlet.http.HttpServlet bugs, and where to report them?

[Mark Thomas]

Jan Luehe wrote:
> Hi Mike,
> 
> thanks for your comments, which I have recorded at:
> 
>  https://servlet-spec-eg.dev.java.net/issues/show_bug.cgi?id=40

Jan - is it possible to get read access to this?

Cheers,

Mark

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

Re: Possible javax.servlet.http.HttpServlet bugs, and where to report them?

[Jan Luehe]

Mark,

Mark Thomas wrote On 01/24/07 07:59 PM,:


Jan Luehe wrote:
 


Hi Mike,

thanks for your comments, which I have recorded at:

https://servlet-spec-eg.dev.java.net/issues/show_bug.cgi?id=40
   



Jan - is it possible to get read access to this?
 



please go to https://servlet-spec-eg.dev.java.net/
and request observer role.

Jan


Cheers,

Mark

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