Re: JK 1.2.26 ?

[nambo]

Henri Gomez wrote:
> 2007/9/11, Rainer Jung <[EMAIL PROTECTED]>:
>> Hi Henri,
>>
>> 1.2.25 is still pretty young :)
> 
> Yes
> 
>> There are 2 new bugs for 1.2.25 that I'm aware of:
>>
>> - BZ 43287 (already fixed)
>> - BZ 43229 (still needs to be fixed, should be fixed in next release)

Hi, this bug (43229) is very serious I think.
It means retries/failover doesn't work with reply_timeout.

>>
>> Version 1.2.25 is now 1 month old. So a reasonable target release date
>> would be in about 10 weeks?
>>
>> Do you have anything special in mind or the need for earlier fixes?

I hope earlier fixes. Or could you alert the users?

Kazu Nambo

-- 
View this message in context: 
http://www.nabble.com/JK-1.2.26---tf4421382.html#a12632302
Sent from the Tomcat - Dev mailing list archive at Nabble.com.


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

Re: [VOTE] Make released versions RTC

[Mark Thomas]

Jim Jagielski wrote:
> 
> On Sep 10, 2007, at 8:00 PM, Mark Thomas wrote:
> 
>> Jim Jagielski wrote:
>>> How about:
>>>
>>>o CTR on trunk
>>>
>>>o Various release branches are made (ala httpd, apr, etc...).
>>>  These include a STATUS file.
>>>
>>>o All code applied to the release branch is under
>>>  lazy consensus but *must* be specified in STATUS.
>>>  (eg: "I plan on applying rev786987 in 3 days under
>>>  lazy consensus").
>>>
>>> Not as stringent as RTC, but also provides a good level
>>> of oversight with a minimum of overhead... RTC can be
>>> maintained for older, stable releases.
>>
>> Still -1.
>>
>> It provides no more oversight than RTC

Sorry my bad - I meant CTR here.

My point is that your less stringent proposal provides additional
overhead over CTR but no extra oversight / benefit.

> I have no idea how you could possibly justify that statement.
> With RTC one *requires* 3 +1 votes. The above does not.
> 
> And STATUS is there to indicate what *will* be done, not
> what *has* been done.

Mark


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

Re: [VOTE] Make released versions RTC

[Mark Thomas]

Jim Jagielski wrote:
> 
> On Sep 10, 2007, at 4:47 PM, Remy Maucherat wrote:
> 
>>
>> The main idea is that since there's only one trunk branch, there
>> should be agreement on APIs and important topics to proceed
>>
> 
> ++1. So let's start that now. Since there is not agreement on APIs,
> how do we proceed from here? Or, in other words, how do achieve
> agreement on APIs?

http://incubator.apache.org/learn/rules-for-revolutionaries.html

Mostly we are talking about new APIs for new features that, once
agreed, can be added to the current version.

It is changes to existing APIs that are more problematic. The current
APIs will need to change occasionally (eg the Geronimo changes) and
will need to be a new point version (6.1, 6.5 - whatever).

We are already managing:
- 4.1.x (mainly security and the odd bug)
- 5.0.x (security only but needs some header work before release)
- 5.5.x (security, bugs, some back porting of features)
- 6.0.x (security, bugs & new features)

Maintaining, to various degrees, 4 branches is already a fair amount
of work for the team. I don't want to see more maintained branches
than absolutely necessary.

What this means is we need a set of agreed API changes for 6.0.x that
will eventually become 6.1.x/6.5.x. I see
http://incubator.apache.org/learn/rules-for-revolutionaries.html as
the way to get this agreement.

Mark

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

Re: [VOTE] Make released versions RTC

[Filip Hanik - Dev Lists]

Mark Thomas wrote:

On Sep 10, 2007, at 4:47 PM, Remy Maucherat wrote:



The main idea is that since there's only one trunk branch, there
should be agreement on APIs and important topics to proceed

  

++1. So let's start that now. Since there is not agreement on APIs,
how do we proceed from here? Or, in other words, how do achieve
agreement on APIs?



http://incubator.apache.org/learn/rules-for-revolutionaries.html
  
trunk was never a revolution, there werent even API changes, except 
annotations. The comet stuff was API additions, but 100% backwards 
compatible with the old stuff.
by now we are all familiar with the rules for revolutionaries, but that 
has never been the issue around here.



Mostly we are talking about new APIs for new features that, once
agreed, can be added to the current version.

It is changes to existing APIs that are more problematic. The current
APIs will need to change occasionally (eg the Geronimo changes) and
will need to be a new point version (6.1, 6.5 - whatever).

We are already managing:
- 4.1.x (mainly security and the odd bug)
- 5.0.x (security only but needs some header work before release)
- 5.5.x (security, bugs, some back porting of features)
- 6.0.x (security, bugs & new features)

Maintaining, to various degrees, 4 branches is already a fair amount
of work for the team. I don't want to see more maintained branches
than absolutely necessary.

What this means is we need a set of agreed API changes for 6.0.x that
will eventually become 6.1.x/6.5.x. I see
http://incubator.apache.org/learn/rules-for-revolutionaries.html as
the way to get this agreement.
  
actually, preferrably it would be the other way. API changes and new 
features go into trunk, and if deemed useful,agreed upon, they get 
backported to 6.0.x.
I find it not healthy to deal with API changes on dot releases (kind of 
like the digester), especially once a branch is labeled as a stable 
release branch.
stuff like that goes into trunk, to avoid necessary delays of security 
patches and bug fixes to go out as a release.


otherwise, you'll have revolutions in 6.0.x that turn into evolutions in 6.x

Filip

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

Harbor Beta REVa out for Tomcat

[Johnny Kewl]

Working like crazy on the Pojo application server, and having a lot of fun with 
it.
REVa involved mainly Internet optimization... and thats what I got to tell you 
about.

>From a techinical perspective it doesnt work like a URL class loader, it only 
>gets what the remote user is running and needs at "class level", we knew it 
>would be good but the results are terrific, and that's what's got me all 
>excited.

Its (sit down for this) better than a web site... ha ha.
Its more efficient to run a remote Java application than an entire web site.
For a single page... a web site "just" beats Harbor, but for something like a 
travel agency or airline booking system, Harbor wins.

Tomcat *is* now the best application server ever ha ha, which kind of 
explains the stunned silence I got on the Netbeans site.

I had a bash at some news releases
http://coolharbor.100free.com/news_releases.htm

Naturally the one is called Super-Pussy... 

DO NOT REPLY [Bug 43366] New: - Session Statistics command in manager fails with "Unknown command /sessions"

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

   Summary: Session Statistics command in manager fails with
"Unknown command /sessions"
   Product: Tomcat 6
   Version: 6.0.14
  Platform: Other
   URL: http://tomcat.apache.org/tomcat-6.0-doc/manager-
howto.html#Session%20Statistics
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Manager application
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


A documentation page for Tomcat 6 at
http://tomcat.apache.org/tomcat-6.0-doc/manager-howto.html#Session%20Statistics 
allows for the following command to be used in the manager:
http://localhost/manager/sessions?path=/ 

This used to work in Tomcat 5.
In Tomcat 6, the following error is returned:
FAIL - Unknown command /sessions 

I have created two different installations of Tomcat 6.0.14 (one on CentOS 5,
and one on Fedora 7). Both installations exhibit the same failure.

-- 
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 43356] - keystoreFile parameter, when specified as relative, is not treated relative to $CATALINA_BASE or catalina.base property for NioEndPoint

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|tomcat- |[EMAIL PROTECTED]
   |[EMAIL PROTECTED]  |




--- Additional Comments From [EMAIL PROTECTED]  2007-09-12 17:13 ---
thanks for reporting it, I will get that taken care of

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

[Mark Thomas]

Filip Hanik - Dev Lists wrote:
> Mark Thomas wrote:
>>> On Sep 10, 2007, at 4:47 PM, Remy Maucherat wrote:
>>>
>>>
 The main idea is that since there's only one trunk branch, there
 should be agreement on APIs and important topics to proceed

   
>>> ++1. So let's start that now. Since there is not agreement on APIs,
>>> how do we proceed from here? Or, in other words, how do achieve
>>> agreement on APIs?
>>> 
>>
>> http://incubator.apache.org/learn/rules-for-revolutionaries.html
>>   
> trunk was never a revolution, there werent even API changes, except
> annotations. The comet stuff was API additions, but 100% backwards
> compatible with the old stuff.
> by now we are all familiar with the rules for revolutionaries, but that
> has never been the issue around here.

There doesn't have to be an incompatible API change to make something
revolutionary. When several people have different views on how to
implement the same feature then that meets the definition of
revolutionary. Put each idea in a separate branch, let them evolve and
then let the community make the decision about what to merge with trunk.

>> Mostly we are talking about new APIs for new features that, once
>> agreed, can be added to the current version.
>>
>> It is changes to existing APIs that are more problematic. The current
>> APIs will need to change occasionally (eg the Geronimo changes) and
>> will need to be a new point version (6.1, 6.5 - whatever).
>>
>> We are already managing:
>> - 4.1.x (mainly security and the odd bug)
>> - 5.0.x (security only but needs some header work before release)
>> - 5.5.x (security, bugs, some back porting of features)
>> - 6.0.x (security, bugs & new features)
>>
>> Maintaining, to various degrees, 4 branches is already a fair amount
>> of work for the team. I don't want to see more maintained branches
>> than absolutely necessary.
>>
>> What this means is we need a set of agreed API changes for 6.0.x that
>> will eventually become 6.1.x/6.5.x. I see
>> http://incubator.apache.org/learn/rules-for-revolutionaries.html as
>> the way to get this agreement.
>>   
> actually, preferrably it would be the other way. API changes and new
> features go into trunk, and if deemed useful,agreed upon, they get
> backported to 6.0.x.

If there isn't any disagreement on the API or the implementation then
why not put the new feature straight into 6.0.x? I don't see a problem
with having some beta features in 6.0.x as long as they doesn't
interfere with the existing functionality.

> I find it not healthy to deal with API changes on dot releases (kind of
> like the digester), especially once a branch is labeled as a stable
> release branch.

API changes - I agree. API additions I have no problem with in a dot
release.

> stuff like that goes into trunk, to avoid necessary delays of security
> patches and bug fixes to go out as a release.
> 
> otherwise, you'll have revolutions in 6.0.x that turn into evolutions in
> 6.x

Anything that starts in 6.0.x and becomes revolutionary or is
perceived as revolutionary can be copied to a branch and reverted in
6.0.x. One of the nice aspects of svn is that it makes this so much
easier and cheaper than it was was cvs.

Mark

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

Re: [VOTE] Make released versions RTC

[Filip Hanik - Dev Lists]

Mark Thomas wrote:

Filip Hanik - Dev Lists wrote:
  

Mark Thomas wrote:


On Sep 10, 2007, at 4:47 PM, Remy Maucherat wrote:

   


The main idea is that since there's only one trunk branch, there
should be agreement on APIs and important topics to proceed

  
  

++1. So let's start that now. Since there is not agreement on APIs,
how do we proceed from here? Or, in other words, how do achieve
agreement on APIs?



http://incubator.apache.org/learn/rules-for-revolutionaries.html
  
  

trunk was never a revolution, there werent even API changes, except
annotations. The comet stuff was API additions, but 100% backwards
compatible with the old stuff.
by now we are all familiar with the rules for revolutionaries, but that
has never been the issue around here.



There doesn't have to be an incompatible API change to make something
revolutionary. When several people have different views on how to
implement the same feature then that meets the definition of
revolutionary. Put each idea in a separate branch, let them evolve and
then let the community make the decision about what to merge with trunk.
  
ok, so there wasn't several people, and the debated feature could have 
been taken out, but the veto specifically specified to leave it in, and 
never changed.

so again, I don't/didn't see anything revolutionary in trunk,

one has yet to point to a specific feature or .java file to declare the 
revolution


Filip
  

Mostly we are talking about new APIs for new features that, once
agreed, can be added to the current version.

It is changes to existing APIs that are more problematic. The current
APIs will need to change occasionally (eg the Geronimo changes) and
will need to be a new point version (6.1, 6.5 - whatever).

We are already managing:
- 4.1.x (mainly security and the odd bug)
- 5.0.x (security only but needs some header work before release)
- 5.5.x (security, bugs, some back porting of features)
- 6.0.x (security, bugs & new features)

Maintaining, to various degrees, 4 branches is already a fair amount
of work for the team. I don't want to see more maintained branches
than absolutely necessary.

What this means is we need a set of agreed API changes for 6.0.x that
will eventually become 6.1.x/6.5.x. I see
http://incubator.apache.org/learn/rules-for-revolutionaries.html as
the way to get this agreement.
  
  

actually, preferrably it would be the other way. API changes and new
features go into trunk, and if deemed useful,agreed upon, they get
backported to 6.0.x.



If there isn't any disagreement on the API or the implementation then
why not put the new feature straight into 6.0.x? I don't see a problem
with having some beta features in 6.0.x as long as they doesn't
interfere with the existing functionality.

  

I find it not healthy to deal with API changes on dot releases (kind of
like the digester), especially once a branch is labeled as a stable
release branch.



API changes - I agree. API additions I have no problem with in a dot
release.

  

stuff like that goes into trunk, to avoid necessary delays of security
patches and bug fixes to go out as a release.

otherwise, you'll have revolutions in 6.0.x that turn into evolutions in
6.x



Anything that starts in 6.0.x and becomes revolutionary or is
perceived as revolutionary can be copied to a branch and reverted in
6.0.x. One of the nice aspects of svn is that it makes this so much
easier and cheaper than it was was cvs.

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]

DO NOT REPLY [Bug 40001] - HTML pages should not use GET to restart web-apps.

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


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