DO NOT REPLY [Bug 36121] - Including JSP's changes working directory

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2007-09-06 20:38 ---
This is still fixed in svn so I am marking this as fixed. If the fix for this
gets reverted, I will re-open 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]

DO NOT REPLY [Bug 41430] - JkOptions +ForwardDirectories with Apache's DirectoryIndex

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





--- Additional Comments From [EMAIL PROTECTED]  2007-09-06 20:38 ---
Note any fix for this should not break the fix for 36121.

-- 
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 35941] - Wrong remote IP reported when using AJP and APR

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





--- Additional Comments From [EMAIL PROTECTED]  2007-09-06 19:17 ---
For the record, I build Tomcat native with APR 1.2.9 for both of the above 
tests.

-- 
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 43126] - Webapp Classloader put exclusive locks on (DB2) JDBC driver native library?

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2007-09-06 19:12 ---
This is indeed a JNI 'feature'.

-- 
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 41538] - Unable to run Tomcat as a Windows service under JDK 1.6

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2007-09-06 19:09 ---
*** Bug 42915 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]

DO NOT REPLY [Bug 41827] - Not support SSI

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2007-09-06 19:06 ---
The classes are in catalina.jar

-- 
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 35941] - Wrong remote IP reported when using AJP and APR

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





--- Additional Comments From [EMAIL PROTECTED]  2007-09-06 19:05 ---
With APR as shipped for httpd 2.2.4, there was a bug looking up the remote IP,
and it's quite possible the apr-ajp connector overwrites the server address with
the remote IP when it becomes known.  Although this does not sound like your 
bug,
it's something to be aware of, and something to avoid.

It's addressed in the last two versions of APR 1.2.x, and in the httpd 2.2.6
distribution, so hopefully it's the last we would see of this bug.  It only
occurred when AcceptEx caught the connection on Windows 2000, and then apr
used traditional socket calls to determine the remote IP address. 

-- 
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 42729] - Documentation - Installation - JDK Not JRE

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





--- Additional Comments From [EMAIL PROTECTED]  2007-09-06 19:01 ---
You are confused because previously, Tomcat required a JDK to compile any JSP
pages into bytecode.  Tomcat 5.5 and later ship with their own compiler.

-- 
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 41538] - Unable to run Tomcat as a Windows service under JDK 1.6

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2007-09-06 19:01 ---
*** Bug 41868 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]

DO NOT REPLY [Bug 41868] - Not able to start the Tomcat 6.0.10 in WinXP as a Service with JRE 1.6.0

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE




--- Additional Comments From [EMAIL PROTECTED]  2007-09-06 19:01 ---


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

-- 
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 42729] - Documentation - Installation - JDK Not JRE

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2007-09-06 18:55 ---
No, JRE is correct.

-- 
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 41463] - Exception report with IE but not firefox!

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2007-09-06 18:52 ---
IE 'feature' -> INVALID

-- 
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 41513] - JSP examples don't work and don't display source

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2007-09-06 18:51 ---
This is fixed in the latest source from svn.

-- 
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 42188] - Missing Source File Headers and Copyright statements

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2007-09-06 18:48 ---
This has since been fixed using the insert_license.pl script.

-- 
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 43316] - message jsp.error.beans.property.conversion missing in resourcebundle

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE




--- Additional Comments From [EMAIL PROTECTED]  2007-09-06 17:50 ---


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

-- 
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 40528] - missing error message localisations

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2007-09-06 17:50 ---
*** Bug 43316 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]

DO NOT REPLY [Bug 35941] - Wrong remote IP reported when using AJP and APR

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WORKSFORME




--- Additional Comments From [EMAIL PROTECTED]  2007-09-06 17:41 ---
It also works with httpd 2.0.59, mod_jk 1.2.25, Tomcat 5.5.25 and Tomcat-Native
1.1.10

I am not going to rule out a bug in an earlier version but if you still see this
issue, an upgrade to the latest versions should fix it. If it doesn't, it is a
configuration issue and you should use the users list for further assistance in
that case.

-- 
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 35941] - Wrong remote IP reported when using AJP and APR

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





--- Additional Comments From [EMAIL PROTECTED]  2007-09-06 17:01 ---
This works as expected with:
httpd 2.2.4, mod_proxy_ajp, Tomcat 5.5.25, Tomcat-Native 1.1.10

Still check earlier versions...

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

[Mladen Turk]

Remy Maucherat wrote:


To give an idea, "tis" could mean:
- API changing patches (any protected or above signature change)
- code changes in the critical path (for example, code which gets 
executed on each HTTP request)


Fine.

- any other commit for which a committer asks for the RTC procedure 
should be rollbacked if it hinders concurrent work, and go through the 
RTC procedure




This looks like a conditional veto that can be voted over. Perfect!
IIUC it means that instead veto one asks for a vote (+3 votes), right?
Looks like RTC on demand, that would require some sort of lazy consensus.

Regards,
Mladen


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

Re: [VOTE] Make released versions RTC

[Mladen Turk]

Yoav Shapira wrote:

Hi,

On 9/6/07, Mladen Turk <[EMAIL PROTECTED]> wrote:


Do we need it? Yes, if we wish to survive as a project.
It's pain in the ass, I know, but IMHO it's also the only
way to get some sense in this chaos.


I disagree.  I think the current CTR policy has worked just fine and
can continue to work jsut fine.


If you read my post I was careful enough to not mention the RTC policy.
All I was saying is that current CTR caused too many problems,
because trunk was our stable branch, and disagreement on API
caused drastic things like putting trunk to sandbox etc. All that
could be prevented if we had trunk with CTR and stable branch with
RTC policy (or something like, that would give more stability to the
stable branch).

It's obvious that Filip and Remy have two different views on the
subject, and all of us are influenced by that.
Jean-Frederic, myself, and some other folks think this has to stop, and the
easiest way is to comply to some rules that are already in place within
different ASF projects.

This won't prevent the security issues, cause those have priority
and don't need to comply to the RTC (or something like) policy.


Regards,
Mladen


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

Re: [VOTE] Make released versions RTC

[Yoav Shapira]

Hey,

On 9/6/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Most of the comments were that it was too annoying to do for casual
> bugfixing, and it's true it's not justified for all patches. Maybe a
> finer rule could be devised, something like using a RtisTC (tis = the
> important stuff) model.
>
> To give an idea, "tis" could mean:
> - API changing patches (any protected or above signature change)
> - code changes in the critical path (for example, code which gets
> executed on each HTTP request)
> - any other commit for which a committer asks for the RTC procedure
> should be rollbacked if it hinders concurrent work, and go through the
> RTC procedure

I like this, I think it's a great compromise.

Yoav

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

Re: [VOTE] Make released versions RTC

[Remy Maucherat]

Mladen Turk wrote:

Henri Gomez wrote:
Well what's the consensus on Java projects, like Xerces, Xalan or 
Lucene ?


It doesn't mater how other project do things. It's irrelevant.
We had CTR policy till now and it was working.
Now we have a new situation with different developers POVs,
and cause of that, this requires a different set of rules.

Do we need it? Yes, if we wish to survive as a project.
It's pain in the ass, I know, but IMHO it's also the only
way to get some sense in this chaos.


Most of the comments were that it was too annoying to do for casual 
bugfixing, and it's true it's not justified for all patches. Maybe a 
finer rule could be devised, something like using a RtisTC (tis = the 
important stuff) model.


To give an idea, "tis" could mean:
- API changing patches (any protected or above signature change)
- code changes in the critical path (for example, code which gets 
executed on each HTTP request)
- any other commit for which a committer asks for the RTC procedure 
should be rollbacked if it hinders concurrent work, and go through the 
RTC procedure


Jean-Frédéric didn't like it much though, and it's true that people need 
to play fair for it to work.


Rémy

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

Re: [VOTE] Make released versions RTC

[Yoav Shapira]

Hi,

On 9/6/07, Mladen Turk <[EMAIL PROTECTED]> wrote:
> It doesn't mater how other project do things. It's irrelevant.

I agree with that.

> We had CTR policy till now and it was working.

It's still working.  We've already voted to move the current "trunk"
into a special sandbox, with no loss of work.

> Now we have a new situation with different developers POVs,
> and cause of that, this requires a different set of rules.

I disagree here.  We also already have at least a couple of -1 veto
votes on this RTC vote.

> Do we need it? Yes, if we wish to survive as a project.
> It's pain in the ass, I know, but IMHO it's also the only
> way to get some sense in this chaos.

I disagree.  I think the current CTR policy has worked just fine and
can continue to work jsut fine.  I think the trunk->sandbox issue is
one issue, albeit a sensitive one that stepped on a couple of people's
toes, but that it.  It's not justification a radical change.

Yoav

-
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:
I get more and more provocations from you, for example on the Servlet 
expert group, where you could not resist alluding to this conflict in 
your introduction.
huh? it was a mere reference that we are working on the same project, 
twist it anyway you want.


Ok. It must be the "evil" part in "evil twin" and whoever of the two of 
us could be the "evil" one that gave me the wrong idea :|


Rémy

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

Re: [VOTE] Make released versions RTC

[Mladen Turk]

Henri Gomez wrote:

Well what's the consensus on Java projects, like Xerces, Xalan or Lucene ?



It doesn't mater how other project do things. It's irrelevant.
We had CTR policy till now and it was working.
Now we have a new situation with different developers POVs,
and cause of that, this requires a different set of rules.

Do we need it? Yes, if we wish to survive as a project.
It's pain in the ass, I know, but IMHO it's also the only
way to get some sense in this chaos.



Regards,
Mladen

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

Re: Draft for September 2007 Board report

[Niall Pemberton]

On 9/3/07, Mladen Turk <[EMAIL PROTECTED]> wrote:
> Hi,
>
> We need to file the board report by next week for a board
> meeting on September 19th.
>
> Here is my draft, so please fill in the gaps, since it's my
> first one :)

Seems to me that theres a serious community issue here in TomcatLand -
with two committers taking chunks out of each other. Maybe its not yet
time to highlight this to the board - but I don't see anything being
tried to bring these two back to a point of co-operation and mutual
respect (my suggestion - get the Travel Assitance Committee to pay for
their airfare to the next Hackathon so they can sit down and talk
face-to-face over several beers).

Just my 2 cents as an outsider.

Niall

> Thanks,
> Mladen
>
> Apache Tomcat Board Report, September 2007
>
> Summary
> --
> The project continues to be active on a number of fronts.  There are
> no issues requiring Board attention at this time.
>
> Releases
> -
> We cut a number of releases incorporating all our active branches.
>
> Tomcat 5.5.25 is going to be released in few days.
>
> Tomcat 6, the current production branch, had one releases this past
> quarter: 6.0.14, which is the latest stable Tomcat at this time.
>
> Finally, the Tomcat connectors, mainly mod_jk, has a couple of
> releases as well: 1.2.24 and 1.2.25. However we had to revoke
> the 1.2.24 release because of serious regression that sliped trough
> the testing phase.
>
> Security
> 
> The Tomcat security site (http://tomcat.apache.org/security.html) has
> been getting more love and attention.  It now contains the vast
> majority of known issues and fixes for all Tomcat branches.
>
> We've been working closely with security issue reports and the Apache
> Security committee on quickly replying to issues, resolving them, and
> coordinating public disclosures.
>
> There exist few open security issues at the moment.  The fixes
> are already in SVN, and most of them are already incorporated with
> 6.0.14 and 5.5.25 releases.
>
> Development
> ---
> There is ongoing discussion about the purpose of the current code
> inside Tomcat 6 trunk, and the majority of developers have agreed
> to put the trunk into the sandbox.
>
> Community
> -
> After last quarter's new committers and PMC members, there were no
> changes the committership nor PMC membership this time.
> Mladen Turk was elected as new PMC Chair and voted by the ASF Board.

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

Filip Hanik - Dev Lists wrote:

you start to sound like you believe yourself by this point.
After my vacation, I'll pull out the emails you wrote, where, even 
though it was a veto, you clearly specified to leave it in.
I will also pull out the email, where I offered to elaborate more, 
and you pretty much declined.
Then I will pull out the email where I offered to pull out the much 
debated Comet implementation, so that trunk can move forward.
And if you wish, I can pull out even more examples. Just let me know 
how much time and proof it needs to take before your willing to 
re-evaluate your accusatory statements.


I don't know why I would not "believe myself". What I wrote is:
- trunk is your own development branch, and that significant changes 
are not even discussed
- moving trunk to the sandbox is somehow characterized as "throwing it 
away"
- I did do comparable development in the sandbox, so I suppose I was 
throwing my code away


You can post archives (that are from a few weeks ago anyway, hopefully 
people here do remember) if you'd like to attempt to show I'm a bad 
person or something, but there's nothing related to the issues I 
brought forward in them.


In a regular branch like trunk, I expect collaboration, discussion 
and announcements of upcoming changes, etc, which did not happen.
you're having a control issue, and your manifesting it by wanting to 
get rid of trunk, even though several people have politely and 
respectfully asked for it to remain. Mainly the Geronimo folks who 
would want it in their distribution. Getting rid of trunk, simply 
means that Geronimo has one more obstacle to get around, sounds like 
it would benefit someone else, doesn't it?


I proposed to move trunk to the sandbox (not delete it, obviously) 
because I felt the development process is not appropriate. Development 
can continue on it in the sandbox. The vote has now passed, so do you 
agree to move the branch ?
as I said earlier, do what you feel is right with trunk. My opinion 
hasn't changed, and you keep twisting my views. but I'm out of the debate


Geronimo chose to rely on a development branch which did not even have 
a release plan in place. The interface used in 6.0.x has marginally 
inferior capabilities (it doesn't allow constructor injection, which 
is not required by anything at the moment). This would create a 
limitation about the web component for now, and that's about it. 
Overall, what they chose to do does sound risky to me.


I would like to point out that I accepted their patch after a few 
modifications, although I don't particularly like Geronimo, and this 
meant more work for me in my real job (adapting JBoss to the new 
interface was not so easy and took me one day of work :( ).


However, to compare with your way of doing things, if David Jencks was 
acting like you are, he would have done the follwing. He would have 
committed his original patch without accepting my modifications, and I 
would have loudly complained about it (probably one of these "non 
justified" vetoes ...). I suppose complaints would have been ignored, 
with the only option for me to go "dump" my stuff in the sandbox and 
then suggestions to default on innocent third parties - aka, vote on 
the two injection APIs (where, similar to Comet, I bet only 2 people 
max care).


Despite your posturing as the knight with the shiny armor, this is not 
the proper way to do things (at least if you don't want to end up 
being dragged in never ending conflicts). I think I'm not asking for a 
lot overall.


Besides annotations and comet, the changes in trunk are of a bug 
fix/feature improvement type, and discussing every minor detail would 
be equivalent to RTC. Currently we are using CTR, hence you get the 
option to review anything that has been done.


This is obviously not RTC, this is normal, detailed discussion of 
significant changes, such as API changes. You have shown you did not 
care about comments after commit, and preferred to default to 
meaningless votes to resolve problems after they escalated (that you 
would not feel like abiding to if they do not turn out in your favor, 
I suppose :| ).


I will also assert there are very few actual changes in trunk that 
would take time to apply:

- some NIO connector changes
- clustering changes
- the annotation injection change

That's quite easy to apply to 6.0.x. Even if trunk was deleted 
outright, it would seem it would take mere hours to recreate it.


I've never ignored your emails, nor have I not answered anytime you 
asked for an explanation. Take the virtual loader for example, huge 
improvements to a component that wasn't really working, but was 
included in the main distribution. Simply because you "didn't like 
it" was your explanation, doesn't make it immensely useful for very 
large installation of Tomcat.


It is "I don't like it, *because*". I never vetoed the vloader, but I 
always did say I did not like it. What's wrong wit

Re: [VOTE] Make released versions RTC

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:

you start to sound like you believe yourself by this point.
After my vacation, I'll pull out the emails you wrote, where, even 
though it was a veto, you clearly specified to leave it in.
I will also pull out the email, where I offered to elaborate more, and 
you pretty much declined.
Then I will pull out the email where I offered to pull out the much 
debated Comet implementation, so that trunk can move forward.
And if you wish, I can pull out even more examples. Just let me know how 
much time and proof it needs to take before your willing to re-evaluate 
your accusatory statements.


I don't know why I would not "believe myself". What I wrote is:
- trunk is your own development branch, and that significant changes are 
not even discussed

- moving trunk to the sandbox is somehow characterized as "throwing it away"
- I did do comparable development in the sandbox, so I suppose I was 
throwing my code away


You can post archives (that are from a few weeks ago anyway, hopefully 
people here do remember) if you'd like to attempt to show I'm a bad 
person or something, but there's nothing related to the issues I brought 
forward in them.


In a regular branch like trunk, I expect collaboration, discussion and 
announcements of upcoming changes, etc, which did not happen.
you're having a control issue, and your manifesting it by wanting to get 
rid of trunk, even though several people have politely and respectfully 
asked for it to remain. Mainly the Geronimo folks who would want it in 
their distribution. Getting rid of trunk, simply means that Geronimo has 
one more obstacle to get around, sounds like it would benefit someone 
else, doesn't it?


I proposed to move trunk to the sandbox (not delete it, obviously) 
because I felt the development process is not appropriate. Development 
can continue on it in the sandbox. The vote has now passed, so do you 
agree to move the branch ?


Geronimo chose to rely on a development branch which did not even have a 
release plan in place. The interface used in 6.0.x has marginally 
inferior capabilities (it doesn't allow constructor injection, which is 
not required by anything at the moment). This would create a limitation 
about the web component for now, and that's about it. Overall, what they 
chose to do does sound risky to me.


I would like to point out that I accepted their patch after a few 
modifications, although I don't particularly like Geronimo, and this 
meant more work for me in my real job (adapting JBoss to the new 
interface was not so easy and took me one day of work :( ).


However, to compare with your way of doing things, if David Jencks was 
acting like you are, he would have done the follwing. He would have 
committed his original patch without accepting my modifications, and I 
would have loudly complained about it (probably one of these "non 
justified" vetoes ...). I suppose complaints would have been ignored, 
with the only option for me to go "dump" my stuff in the sandbox and 
then suggestions to default on innocent third parties - aka, vote on the 
two injection APIs (where, similar to Comet, I bet only 2 people max care).


Despite your posturing as the knight with the shiny armor, this is not 
the proper way to do things (at least if you don't want to end up being 
dragged in never ending conflicts). I think I'm not asking for a lot 
overall.


Besides annotations and comet, the changes in trunk are of a bug 
fix/feature improvement type, and discussing every minor detail would be 
equivalent to RTC. Currently we are using CTR, hence you get the option 
to review anything that has been done.


This is obviously not RTC, this is normal, detailed discussion of 
significant changes, such as API changes. You have shown you did not 
care about comments after commit, and preferred to default to 
meaningless votes to resolve problems after they escalated (that you 
would not feel like abiding to if they do not turn out in your favor, I 
suppose :| ).


I will also assert there are very few actual changes in trunk that would 
take time to apply:

- some NIO connector changes
- clustering changes
- the annotation injection change

That's quite easy to apply to 6.0.x. Even if trunk was deleted outright, 
it would seem it would take mere hours to recreate it.


I've never ignored your emails, nor have I not answered anytime you 
asked for an explanation. Take the virtual loader for example, huge 
improvements to a component that wasn't really working, but was included 
in the main distribution. Simply because you "didn't like it" was your 
explanation, doesn't make it immensely useful for very large 
installation of Tomcat.


It is "I don't like it, *because*". I never vetoed the vloader, but I 
always did say I did not like it. What's wrong with that exactly, is it 
not allowed ? In this particular case, I think it allows too many 
things, and will lead to less war portability, so actually advertising 
it is

Re: What new in Tomcat 6.0 ?

[Ashish Jain]

Hi!!

   Thanks a lot for the quick response. I also want to know how these
changes leads to  performance improvement.

Thanks and Regards
 Ashish


On 9/6/07, Mark Thomas <[EMAIL PROTECTED]> wrote:
>
> Ashish Jain wrote:
> > Hi All!!
> >
> >  I am new to Tomcat. Can someone tell me what is new in Tomcat 6.0compared
> > to the last version.
>
> This question should be posted to the users list. See
> http://tomcat.apache.org/lists.html
>
> Mark
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>