[VOTE] Make released versions RTC

[jean-frederic clere]

Hi,

I would also propose that we take an handling of release branches
similar to httpd.

The release branches are:
/tomcat/tc6.0.x/trunk

/tomcat/build/tc5.5.x/
/tomcat/container/tc5.5.x
/tomcat/jasper/tc5.5.x/
(Note it uses /tomcat/connectors/trunk)

/tomcat/build/branches/tc5.0.x
/tomcat/container/branches/tc5.0.x
/tomcat/connectors/branches/tc5.0.x
/tomcat/jasper/branches/tc5.0.x

The votes will get in a file named STATUS file and once accepted in a
file named CHANGES.
The proposal of backports/fixes should be a description of the
feature/PR number and a link to a commit (in another branch or sandbox)
or a patch (diff -u) against the branch.
A proposal needs 3 +1 votes and no -1 to be accepted. The committer that
makes the proposal is responsible to commit the new code (and move the
proposal from STATUS to CHANGES) in the branch once accepted.


[ ] +1
[ ] 0
[ ] -1


Jean-Frederic

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

Re: [VOTE] Move trunk to sandbox

[Tim Funk]

Remy Maucherat wrote:


[X] +1
[ ] 0
[ ] -1

 



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

Re: [VOTE] Make released versions RTC

[Yoav Shapira]

Hey,

On 9/4/07, jean-frederic clere <[EMAIL PROTECTED]> wrote:
> I would also propose that we take an handling of release branches
> similar to httpd.

> The votes will get in a file named STATUS file and once accepted in a
> file named CHANGES.
> The proposal of backports/fixes should be a description of the
> feature/PR number and a link to a commit (in another branch or sandbox)
> or a patch (diff -u) against the branch.
> A proposal needs 3 +1 votes and no -1 to be accepted. The committer that
> makes the proposal is responsible to commit the new code (and move the
> proposal from STATUS to CHANGES) in the branch once accepted.
>
> 
> [ ] +1
> [ ] 0
> [ X ] -1
> 

-1 from me.  I really don't like this, because I think it adds
significant overhead to development on released branches and the
current system works well enough.  This proposed system slows down bug
fix backports and goes against the very nature of committership trust,
in my mind.

Yoav

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

Re: [VOTE] Make released versions RTC

[Tim Funk]

What is a change? Any commit?

Is a change only for new features and bug fixes are out of scope?

-Tim

jean-frederic clere wrote:

Hi,

I would also propose that we take an handling of release branches
similar to httpd.

The votes will get in a file named STATUS file and once accepted in a
file named CHANGES.
The proposal of backports/fixes should be a description of the
feature/PR number and a link to a commit (in another branch or sandbox)
or a patch (diff -u) against the branch.
A proposal needs 3 +1 votes and no -1 to be accepted. The committer that
makes the proposal is responsible to commit the new code (and move the
proposal from STATUS to CHANGES) in the branch once accepted.



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

Re: [VOTE] Make released versions RTC

[Remy Maucherat]

jean-frederic clere wrote:

Hi,

I would also propose that we take an handling of release branches
similar to httpd.

The release branches are:
/tomcat/tc6.0.x/trunk

/tomcat/build/tc5.5.x/
/tomcat/container/tc5.5.x
/tomcat/jasper/tc5.5.x/
(Note it uses /tomcat/connectors/trunk)

/tomcat/build/branches/tc5.0.x
/tomcat/container/branches/tc5.0.x
/tomcat/connectors/branches/tc5.0.x
/tomcat/jasper/branches/tc5.0.x

The votes will get in a file named STATUS file and once accepted in a
file named CHANGES.


-> changelog.xml ? I suppose there's no reason to stop using it.


The proposal of backports/fixes should be a description of the
feature/PR number and a link to a commit (in another branch or sandbox)
or a patch (diff -u) against the branch.
A proposal needs 3 +1 votes and no -1 to be accepted. The committer that
makes the proposal is responsible to commit the new code (and move the
proposal from STATUS to CHANGES) in the branch once accepted.


[X] +1
[ ] 0
[ ] -1



This project is much more appropriate given the project's maturity.

Rémy


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

Re: [VOTE] Make released versions RTC

[Mark Thomas]

jean-frederic clere wrote:
> The votes will get in a file named STATUS file and once accepted in a
> file named CHANGES.
> The proposal of backports/fixes should be a description of the
> feature/PR number and a link to a commit (in another branch or sandbox)
> or a patch (diff -u) against the branch.
> A proposal needs 3 +1 votes and no -1 to be accepted. The committer that
> makes the proposal is responsible to commit the new code (and move the
> proposal from STATUS to CHANGES) in the branch once accepted.
> 
> 
> [ ] +1
> [ ] 0
> [X] -1
> 

This is too heavy handed for all commits.

Mark

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

Re: [VOTE] Make released versions RTC

[jean-frederic clere]

Tim Funk wrote:
> What is a change? Any commit?
> 
> Is a change only for new features and bug fixes are out of scope?

My idea is to have it for all commits but only on release branches.
The idea is more to force people participating on the development of new
feature and help to fixing bugs.

Cheers

Jean-Frederic

> 
> -Tim
> 
> jean-frederic clere wrote:
>> Hi,
>>
>> I would also propose that we take an handling of release branches
>> similar to httpd.
>>
>> The votes will get in a file named STATUS file and once accepted in a
>> file named CHANGES.
>> The proposal of backports/fixes should be a description of the
>> feature/PR number and a link to a commit (in another branch or sandbox)
>> or a patch (diff -u) against the branch.
>> A proposal needs 3 +1 votes and no -1 to be accepted. The committer that
>> makes the proposal is responsible to commit the new code (and move the
>> proposal from STATUS to CHANGES) in the branch once accepted.
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


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

DO NOT REPLY [Bug 43303] New: - Versioning under Windows not reported by many connector components

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

   Summary: Versioning under Windows not reported by many connector
components
   Product: Tomcat 5
   Version: Nightly Build
  Platform: Other
OS/Version: Windows Server 2003
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Connector:AJP
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


many of the components in connectors project do not report file/dll version
information on windows32 as normally pulled from a resource file e.g.
jk/native/mod_jk, ajp/proxy, ajp/ajplib jk/native/jk_nt_service and

but jk/native/iis and jni/native/libtcnative do.

Also could the version of java and httpd compiled / running against should be
output as is similarily done for mod_ssl and httpd / openssl? 

Can build instructions for windows hosts be supplied in terms of required tools/
apr versions and folder structure be documented?

At the moment I'm having to amend each dsp file to include a dependency on a .rc
file which has to be autogenerated by using the win32ver.awk file from main
httpd which is hackish at best.

unfortunately my employer won't let me contribute code.

-- 
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: [VOTE] Make released versions RTC

[Tim Funk]

In that case

> [ ] +1
> [ ] 0
> [X] -1
> 

For ensuring new features start in "trunk" and work their way back, I'd 
+1. But since bugs (in BZ not marked as enhancement) would also need RTC 
- that is my reason for -1.


-Tim


jean-frederic clere wrote:

Tim Funk wrote:

What is a change? Any commit?

Is a change only for new features and bug fixes are out of scope?


My idea is to have it for all commits but only on release branches.
The idea is more to force people participating on the development of new
feature and help to fixing bugs.

Cheers

Jean-Frederic


-Tim

jean-frederic clere wrote:

Hi,

I would also propose that we take an handling of release branches
similar to httpd.

The votes will get in a file named STATUS file and once accepted in a
file named CHANGES.
The proposal of backports/fixes should be a description of the
feature/PR number and a link to a commit (in another branch or sandbox)
or a patch (diff -u) against the branch.
A proposal needs 3 +1 votes and no -1 to be accepted. The committer that
makes the proposal is responsible to commit the new code (and move the
proposal from STATUS to CHANGES) in the branch once accepted.



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

Re: [VOTE] Make released versions RTC

[Filip Hanik - Dev Lists]

-1,
that means the entire tomcat project is RTC, since you just voted to get 
rid of trunk


Filip

jean-frederic clere wrote:

Hi,

I would also propose that we take an handling of release branches
similar to httpd.

The release branches are:
/tomcat/tc6.0.x/trunk

/tomcat/build/tc5.5.x/
/tomcat/container/tc5.5.x
/tomcat/jasper/tc5.5.x/
(Note it uses /tomcat/connectors/trunk)

/tomcat/build/branches/tc5.0.x
/tomcat/container/branches/tc5.0.x
/tomcat/connectors/branches/tc5.0.x
/tomcat/jasper/branches/tc5.0.x

The votes will get in a file named STATUS file and once accepted in a
file named CHANGES.
The proposal of backports/fixes should be a description of the
feature/PR number and a link to a commit (in another branch or sandbox)
or a patch (diff -u) against the branch.
A proposal needs 3 +1 votes and no -1 to be accepted. The committer that
makes the proposal is responsible to commit the new code (and move the
proposal from STATUS to CHANGES) in the branch once accepted.


[ ] +1
[ ] 0
[ ] -1


Jean-Frederic

-
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: [VOTE] Make released versions RTC

[Jim Jagielski]

On Sep 4, 2007, at 4:53 AM, jean-frederic clere wrote:


Hi,

I would also propose that we take an handling of release branches
similar to httpd.

The release branches are:
/tomcat/tc6.0.x/trunk

/tomcat/build/tc5.5.x/
/tomcat/container/tc5.5.x
/tomcat/jasper/tc5.5.x/
(Note it uses /tomcat/connectors/trunk)

/tomcat/build/branches/tc5.0.x
/tomcat/container/branches/tc5.0.x
/tomcat/connectors/branches/tc5.0.x
/tomcat/jasper/branches/tc5.0.x

The votes will get in a file named STATUS file and once accepted in a
file named CHANGES.
The proposal of backports/fixes should be a description of the
feature/PR number and a link to a commit (in another branch or  
sandbox)

or a patch (diff -u) against the branch.
A proposal needs 3 +1 votes and no -1 to be accepted. The committer  
that

makes the proposal is responsible to commit the new code (and move the
proposal from STATUS to CHANGES) in the branch once accepted.



I'm +1 for this type of procedure, but I don't see how
this can be shoehorned into the current setup and layout
of TC.

The basic ideas behind httpd and apr are:

  o There is a set development location (currently trunk)
which operates under CTR.

  o There is a set release branch location which only
operates on RTC. All code patches must first be
applied on the development location and then be
proposed for backport and obtain 3 (or more) +1
votes.

The premise is that there is a codebase which is CTR
and thus very free and easy, but it is never directly in
a "to be released" path. All code that is destined for
actual release must be applied to the stable/release
branch via a RTC method.


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

Re: [VOTE] Make released versions RTC

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:

-1,
that means the entire tomcat project is RTC, since you just voted to get 
rid of trunk


Personally, using the CTR model, I noticed a number of people always 
considered the "R" portion invalid, and useless chatter that is best 
ignored. My take on the situation is that persons with bad intentions 
can easily abuse this model.


Rémy

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

Re: [VOTE] Make released versions RTC

[Remy Maucherat]

Jim Jagielski wrote:

I'm +1 for this type of procedure, but I don't see how
this can be shoehorned into the current setup and layout
of TC.

The basic ideas behind httpd and apr are:

  o There is a set development location (currently trunk)
which operates under CTR.

  o There is a set release branch location which only
operates on RTC. All code patches must first be
applied on the development location and then be
proposed for backport and obtain 3 (or more) +1
votes.

The premise is that there is a codebase which is CTR
and thus very free and easy, but it is never directly in
a "to be released" path. All code that is destined for
actual release must be applied to the stable/release
branch via a RTC method.


Yes, that is pretty much the plan. Also, by forcing some level of 
agreement before a commit, this removes the potential for clashes and 
flames due to unannounced changes :)


Rémy

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

Re: [VOTE] Make released versions RTC

[Filip Hanik - Dev Lists]

Remy Maucherat wrote:

Jim Jagielski wrote:

I'm +1 for this type of procedure, but I don't see how
this can be shoehorned into the current setup and layout
of TC.

The basic ideas behind httpd and apr are:

  o There is a set development location (currently trunk)
which operates under CTR.

  o There is a set release branch location which only
operates on RTC. All code patches must first be
applied on the development location and then be
proposed for backport and obtain 3 (or more) +1
votes.

The premise is that there is a codebase which is CTR
and thus very free and easy, but it is never directly in
a "to be released" path. All code that is destined for
actual release must be applied to the stable/release
branch via a RTC method.


Yes, that is pretty much the plan. Also, by forcing some level of 
agreement before a commit, this removes the potential for clashes and 
flames due to unannounced changes :)
yes, it is also easily abused by folks who throw around vetoes as often 
as I change underwear. I don't see a need to slow down development even 
further, at this point if the previous vote is considered valid, we 
don't even have a development branch, and a few months of work got 
thrown out the window


Filip


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]

svn commit: r572854 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java webapps/docs/changelog.xml

[markt]

Author: markt
Date: Tue Sep  4 18:53:49 2007
New Revision: 572854

URL: http://svn.apache.org/viewvc?rev=572854&view=rev
Log:
An alternative fix for 30949 that does not require additional try/catch/finally 
blocks
Also remove unnecessary unwrapping now that unwrapRequest() and 
unwrapResponse() are called in invoke()

Modified:

tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
tomcat/container/tc5.5.x/webapps/docs/changelog.xml

Modified: 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java?rev=572854&r1=572853&r2=572854&view=diff
==
--- 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
 (original)
+++ 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
 Tue Sep  4 18:53:49 2007
@@ -362,10 +362,6 @@
 wrequest.setQueryString(hrequest.getQueryString());
 
 processRequest(request,response,state);
-
-wrequest.recycle();
-unwrapRequest(state);
-
 }
 
 // Handle an HTTP path-based forward
@@ -401,10 +397,6 @@
 }
 
 processRequest(request,response,state);
-
-wrequest.recycle();
-unwrapRequest(state);
-
 }
 
 // This is not a real close in order to support error processing
@@ -554,8 +546,6 @@
 ApplicationFilterFactory.DISPATCHER_REQUEST_PATH_ATTR,
 servletPath);
 invoke(state.outerRequest, state.outerResponse, state);
-
-wrequest.recycle();
 }
 
 // Handle an HTTP path based include
@@ -592,8 +582,6 @@
 ApplicationFilterFactory.DISPATCHER_REQUEST_PATH_ATTR,
 servletPath);
 invoke(state.outerRequest, state.outerResponse, state);
-
-wrequest.recycle();
 }
 
 }
@@ -768,6 +756,8 @@
 // See Bugzilla 30949
 unwrapRequest(state);
 unwrapResponse(state);
+// Recycle request if necessary (also BZ 30949)
+recycleRequestWrapper(state);
 
 // Rethrow an exception if one was thrown by the invoked servlet
 if (ioException != null)
@@ -1024,6 +1014,12 @@
 if (!same) {
 throw new ServletException(sm.getString(
 "applicationDispatcher.specViolation.response"));
+}
+}
+
+private void recycleRequestWrapper(State state) {
+if (state.wrapRequest instanceof ApplicationHttpRequest) {
+((ApplicationHttpRequest) state.wrapRequest).recycle();
 }
 }
 }

Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?rev=572854&r1=572853&r2=572854&view=diff
==
--- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Tue Sep  4 18:53:49 2007
@@ -34,6 +34,10 @@
   
 
   
+30949: Improve previous fix. Ensure requests are re-cycled
+on cross-context includes and forwards when an exception occurs in the
+target page. (markt)
+  
 43216: Set correct StandardSession#accessCount as system 
property STRICT_SERVLET_COMPLIANCE is true after application restart with 
SESSION.ser file.
 Patch provided by Takayuki Kaneko (pero)
   



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

svn commit: r572855 - /tomcat/container/tc5.5.x/webapps/docs/changelog.xml

[markt]

Author: markt
Date: Tue Sep  4 18:59:22 2007
New Revision: 572855

URL: http://svn.apache.org/viewvc?rev=572855&view=rev
Log:
Fix the changelog I broke on previous commit

Modified:
tomcat/container/tc5.5.x/webapps/docs/changelog.xml

Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?rev=572855&r1=572854&r2=572855&view=diff
==
--- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Tue Sep  4 18:59:22 2007
@@ -34,9 +34,10 @@
   
 
   
-30949: Improve previous fix. Ensure requests are re-cycled
+30949: Improve previous fix. Ensure requests are recycled
 on cross-context includes and forwards when an exception occurs in the
 target page. (markt)
+  
   
 43216: Set correct StandardSession#accessCount as system 
property STRICT_SERVLET_COMPLIANCE is true after application restart with 
SESSION.ser file.
 Patch provided by Takayuki Kaneko (pero)



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

svn commit: r572856 - in /tomcat/tc6.0.x/trunk: java/org/apache/catalina/core/ApplicationDispatcher.java webapps/docs/changelog.xml

[markt]

Author: markt
Date: Tue Sep  4 19:01:02 2007
New Revision: 572856

URL: http://svn.apache.org/viewvc?rev=572856&view=rev
Log:
Port improved fix for bug 30949 to TC6.

Modified:

tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java
tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java?rev=572856&r1=572855&r2=572856&view=diff
==
--- 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java 
(original)
+++ 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java 
Tue Sep  4 19:01:02 2007
@@ -341,10 +341,6 @@
 wrequest.setQueryString(hrequest.getQueryString());
 
 processRequest(request,response,state);
-
-wrequest.recycle();
-unwrapRequest(state);
-
 }
 
 // Handle an HTTP path-based forward
@@ -377,10 +373,6 @@
 }
 
 processRequest(request,response,state);
-
-wrequest.recycle();
-unwrapRequest(state);
-
 }
 
 // This is not a real close in order to support error processing
@@ -521,8 +513,6 @@
 ApplicationFilterFactory.DISPATCHER_REQUEST_PATH_ATTR,
 servletPath);
 invoke(state.outerRequest, state.outerResponse, state);
-
-wrequest.recycle();
 }
 
 // Handle an HTTP path based include
@@ -555,8 +545,6 @@
 ApplicationFilterFactory.DISPATCHER_REQUEST_PATH_ATTR,
 servletPath);
 invoke(state.outerRequest, state.outerResponse, state);
-
-wrequest.recycle();
 }
 
 }
@@ -731,7 +719,9 @@
 // See Bugzilla 30949
 unwrapRequest(state);
 unwrapResponse(state);
-
+// Recycle request if necessary (also BZ 30949)
+recycleRequestWrapper(state);
+
 // Rethrow an exception if one was thrown by the invoked servlet
 if (ioException != null)
 throw ioException;
@@ -985,5 +975,10 @@
 throw new ServletException(sm.getString(
 "applicationDispatcher.specViolation.response"));
 }
+}
+
+private void recycleRequestWrapper(State state) {
+if (state.wrapRequest instanceof ApplicationHttpRequest) {
+((ApplicationHttpRequest) state.wrapRequest).recycle();}
 }
 }

Modified: tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml?rev=572856&r1=572855&r2=572856&view=diff
==
--- tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml Tue Sep  4 19:01:02 2007
@@ -35,6 +35,11 @@
   
 
   
+30949: Improve previous fix. Ensure requests are re-cycled
+on cross-context includes and forwards when an exception occurs in the
+target page. (markt)
+  
+  
 42944: Correctly handle servlet mappings that use a '+'
 character as part of the url pattern. (markt)
   



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

DO NOT REPLY [Bug 30949] - After Failed Include, Request and Response not Unwrapped

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2007-09-04 19:02 ---
I have committed a fix for this that doesn't require additional
try/catch/finally blocks. See r572854 (TC5.5.x) and r572856 (TC6.0.x)

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

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

svn commit: r572857 - /tomcat/jasper/tc5.5.x/.project

[markt]

Author: markt
Date: Tue Sep  4 19:04:35 2007
New Revision: 572857

URL: http://svn.apache.org/viewvc?rev=572857&view=rev
Log:
Remove duplicate line

Modified:
tomcat/jasper/tc5.5.x/.project

Modified: tomcat/jasper/tc5.5.x/.project
URL: 
http://svn.apache.org/viewvc/tomcat/jasper/tc5.5.x/.project?rev=572857&r1=572856&r2=572857&view=diff
==
--- tomcat/jasper/tc5.5.x/.project (original)
+++ tomcat/jasper/tc5.5.x/.project Tue Sep  4 19:04:35 2007
@@ -15,7 +15,6 @@
   See the License for the specific language governing permissions and
   limitations under the License.
 -->
-
 
jasper




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

DO NOT REPLY [Bug 33774] - JNDIRealm fails when server disconnects after time

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2007-09-04 19:11 ---
The "connection reset" message refers to a problem that never existed in the
6.0.x series - it was fixed before that series was started.

Please check your configuration via the users list. If you still see the
problem, you will need to post the stack trace (you can XXX out server names,
ports etc from the stack trace) so we can figure out where the problem lies.

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

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

svn commit: r572859 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/realm/JNDIRealm.java

[markt]

Author: markt
Date: Tue Sep  4 19:14:45 2007
New Revision: 572859

URL: http://svn.apache.org/viewvc?rev=572859&view=rev
Log:
Improve fix for 33774 by adding check for alternative exception to the 
remaining point where it could be seen.

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/realm/JNDIRealm.java

Modified: tomcat/tc6.0.x/trunk/java/org/apache/catalina/realm/JNDIRealm.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/realm/JNDIRealm.java?rev=572859&r1=572858&r2=572859&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/realm/JNDIRealm.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/realm/JNDIRealm.java Tue Sep  
4 19:14:45 2007
@@ -1549,6 +1549,21 @@
 // Try the authentication again.
 principal = getPrincipal(context, username);
 
+} catch (ServiceUnavailableException e) {
+
+// log the exception so we know it's there.
+containerLog.warn(sm.getString("jndiRealm.exception"), e);
+
+// close the connection so we know it will be reopened.
+if (context != null)
+close(context);
+
+// open a new directory context.
+context = open();
+
+// Try the authentication again.
+principal = getPrincipal(context, username);
+
 }
 
 



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

svn commit: r572860 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java

[markt]

Author: markt
Date: Tue Sep  4 19:15:35 2007
New Revision: 572860

URL: http://svn.apache.org/viewvc?rev=572860&view=rev
Log:
Port improved fix for 33774 that adds a check for the alternative exception to 
the remaining point where it could be seen.

Modified:

tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java

Modified: 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java?rev=572860&r1=572859&r2=572860&view=diff
==
--- 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java
 (original)
+++ 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java
 Tue Sep  4 19:15:35 2007
@@ -1533,6 +1533,21 @@
 // Try the authentication again.
 principal = getPrincipal(context, username);
 
+} catch (ServiceUnavailableException e) {
+
+// log the exception so we know it's there.
+containerLog.warn(sm.getString("jndiRealm.exception"), e);
+
+// close the connection so we know it will be reopened.
+if (context != null)
+close(context);
+
+// open a new directory context.
+context = open();
+
+// Try the authentication again.
+principal = getPrincipal(context, username);
+
 }
 
 



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