Re: [poll] mod_jk for i5/OS / V5R4 mini

[Rainer Jung]

> 
> A note shouldn't hurt. Did there is a date for 1.2.25 release ?
> 

It's released. So a note would be part of future releases, and of course
we can add important stuff to the web site docs in between. Since 1.2.25
had been released only 2 weeks ago, I think we don't plan a regular
release in the next app. 2 months.

Regards,

Rainer

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

Re: Bug in B2C converter WAS: svn commit: r568307 - /tomcat/trunk/java/org/apache/tomcat/util/buf/B2CConverter.java

[Filip Hanik - Dev Lists]

Bill Barker wrote:
"Filip Hanik - Dev Lists" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
  

Bill Barker wrote:

"Remy Maucherat" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]


  

Filip Hanik - Dev Lists wrote:



Test Case and 5.5.x patch can be found here.
http://people.apache.org/~fhanik/tomcat/b2c/

This is what is happening

int cnt=conv.read( result, 0, BUFFER_SIZE );
is called with a "while (true)" statement,

When the IntermediateInputStream.read returns -1, the above statement 
returns cnt==1.
So to avoid calling conv.read, we must check to see if we have more 
bytes to read by implementing the available() method, to avoid the 
inputstream ever returning -1.


  

It's possible, but I have a hard time understanding the issue.



The issue is that InputStreamReader reads 8192 bytes from 
IntermediateInputStream on the first go.  It then translates them into 
2734 chars, but thinks that the last few bytes represent an incomplete 
char, so holds onto them.  On the next call, IntermediateInputStream 
returns -1, so InputStreamReader outputs the last char as best it can 
(resulting in returning 1).  Then the IntermediateInputStream buffer is 
reset, and it can continue on reading (but from the wrong position, 
resulting in corruption).


Filip's patch is inelegant (better would be to use the ByteChunk sink), 
but other than my looking for a better way to do it, I can't come up with 
the required technical reason to porting the base of it to 5.5 (of 
course, I could care less what he does in his sandbox :).


  
I've committed the fix to 5.5, if you find a more elegant way of solving 
the actual problem, feel free to revert it and commit another fix. I don't 
care about the how, as long as there is a fix that will be included in the 
tag 5.5.25 on Friday





No problem.  I can see how to do this better, but I'll wait until the 
weekend to commit (since it's not totally trivial, I don't want a one-day 
window for regression testing :).  That way 5.5.25 can go out with your 
patch.  It doesn't include the NIO dependancy (which was my only concern), 
so it works well enough for me for now.
  
according to the KISS principle, your fix would have to be less than 4 
lines changed to be "more elegant" :)


Filip

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

DO NOT REPLY [Bug 43201] New: - Wrong set method called in custom tag

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

   Summary: Wrong set method called in custom tag
   Product: Tomcat 5
   Version: 5.5.23
  Platform: Other
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Suppose we have two custom tags   and .  The body content of
the outer tag is JSP.  The inner tag has an empty content but has an attribute
"isTrue" of type java.lang.Boolean.

In the definition of the inner tag we have two setter methods:

/* method 1 */
public void setIsTrue (Boolean isTrue) { ...  }

/* method 2 */
public void setIsTrue (String isTrueString) { ... }

In a page written using XML Syntax, if I say 

bla bla bla 

Then method 1 is called, as expected...

However, if I say 



Then method 2 is called instead!  Method 2 should never be called!  I've
deployed the exact same WAR file on Weblogic 9 and there only method 1 is 
called.   

This seems like a bug to me:  Am I missing something?

Thanx

-- 
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: Bug in B2C converter WAS: svn commit: r568307 - /tomcat/trunk/java/org/apache/tomcat/util/buf/B2CConverter.java

[Bill Barker]

"Filip Hanik - Dev Lists" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Bill Barker wrote:
>> "Filip Hanik - Dev Lists" <[EMAIL PROTECTED]> wrote in message 
>> news:[EMAIL PROTECTED]
>>
>>> Bill Barker wrote:
>>>
 "Remy Maucherat" <[EMAIL PROTECTED]> wrote in message 
 news:[EMAIL PROTECTED]


> Filip Hanik - Dev Lists wrote:
>
>
>> Test Case and 5.5.x patch can be found here.
>> http://people.apache.org/~fhanik/tomcat/b2c/
>>
>> This is what is happening
>>
>> int cnt=conv.read( result, 0, BUFFER_SIZE );
>> is called with a "while (true)" statement,
>>
>> When the IntermediateInputStream.read returns -1, the above statement 
>> returns cnt==1.
>> So to avoid calling conv.read, we must check to see if we have more 
>> bytes to read by implementing the available() method, to avoid the 
>> inputstream ever returning -1.
>>
>>
> It's possible, but I have a hard time understanding the issue.
>
>
>
 The issue is that InputStreamReader reads 8192 bytes from 
 IntermediateInputStream on the first go.  It then translates them into 
 2734 chars, but thinks that the last few bytes represent an incomplete 
 char, so holds onto them.  On the next call, IntermediateInputStream 
 returns -1, so InputStreamReader outputs the last char as best it can 
 (resulting in returning 1).  Then the IntermediateInputStream buffer is 
 reset, and it can continue on reading (but from the wrong position, 
 resulting in corruption).

 Filip's patch is inelegant (better would be to use the ByteChunk sink), 
 but other than my looking for a better way to do it, I can't come up 
 with the required technical reason to porting the base of it to 5.5 (of 
 course, I could care less what he does in his sandbox :).


>>> I've committed the fix to 5.5, if you find a more elegant way of solving 
>>> the actual problem, feel free to revert it and commit another fix. I 
>>> don't care about the how, as long as there is a fix that will be 
>>> included in the tag 5.5.25 on Friday
>>>
>>>
>>
>> No problem.  I can see how to do this better, but I'll wait until the 
>> weekend to commit (since it's not totally trivial, I don't want a one-day 
>> window for regression testing :).  That way 5.5.25 can go out with your 
>> patch.  It doesn't include the NIO dependancy (which was my only 
>> concern), so it works well enough for me for now.
>>
> according to the KISS principle, your fix would have to be less than 4 
> lines changed to be "more elegant" :)
>

Yes, it is more than 4 lines, but most of them are deletes :).  I've done it 
already on my local machine here, in case anybody wants RTC on the 5.5.x 
branch (and Filip's test case passes with flying colors :).  I'm pretty much 
sure that there are no regressions for 5.5.x+, but I still need to look at 
3.3.x,  and 4.1.x.

If anyone is interested, I can post the patch files.  Otherwise, I'll assume 
that CTR is still in place, and you can veto it when I commit over the w/e 
;).  Of course, if this message was meant as a pre-emptive veto, then I 
won't bother.

> Filip 




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