Re: [PATCH] CatalinaBlock.java

2001-02-12 Thread Sam Ruby

Remy Maucherat wrote:

 For these reasons, I'd like to see an official Avalon wrapper
 introduced in Tomcat 4.1, but not in Tomcat 4.0.  I also
 propose to remove the current Avalon wrapper from the Tomcat
 4.0 repository, to avoid the maintenance related issues.

+1

- Sam Ruby


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




Re: [PATCH] CatalinaBlock.java

2001-02-12 Thread Aaron Mulder

It's always going to be the case that the Avalon and Tomcat releases 
don't sync up perfectly.  How would you feel about making any Tomcat 
changes necessary to support the Avalon patch, but maintaining the 
Avalon block itself outside of the main Tomcat 4.0 module?  That way the 
Avalon support could be updated independently for new releases of Avalon 
*or* Tomcat.

Aaron

Remy Maucherat wrote:

 I'm -1 on applying the Avalon patch in the 4.0 tree.
 The rationale is :
 - Avalon isn't ready yet. It's still in alpha stage, and I fear there may be
 API changes in the pipeline.
 - TC 4.0 should be out before Avalon. If Avalon 3.1 evolves *after* TC 4.0
 is released, this would break the wrapper included in TC 4.0 and make it
 incompatible with the Avalon 3.1 production release, which would more or
 less force us to do a TC maintenance release.
 
 For these reasons, I'd like to see an official Avalon wrapper introduced in
 Tomcat 4.1, but not in Tomcat 4.0.
 I also propose to remove the current Avalon wrapper from the Tomcat 4.0
 repository, to avoid the maintenance related issues.
 
 The 4.1 repository should be recreated very soon, since TC 4.0 has gone back
 into feature freeze mode (but we want to fix the sealing violation problems
 reported by many people before).


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




Re: [PATCH] CatalinaBlock.java

2001-02-12 Thread Craig R. McClanahan

Aaron Mulder wrote:

 It's always going to be the case that the Avalon and Tomcat releases
 don't sync up perfectly.  How would you feel about making any Tomcat
 changes necessary to support the Avalon patch, but maintaining the
 Avalon block itself outside of the main Tomcat 4.0 module?  That way the
 Avalon support could be updated independently for new releases of Avalon
 *or* Tomcat.


That would be my preference.

I was thinking, it ought to be possible to create a
process/module/project/something that takes the output bits of a Tomcat 4.0 binary
distribution, and the output bits of an Avalon release, and combine them into an
Avalonized installation of Tomcat 4.0.  This is not a lot different than what
Henri does when he creates RPMs -- it is done external to the standard Tomcat
build process.

If we want to go this direction, what modifications does "making any Tomcat
changes necessary to support the Avalon patch" include?  (I haven't had a chance
to look at Jason's proposal in detail yet.)


 Aaron


Craig



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




Re: [PATCH] CatalinaBlock.java

2001-02-12 Thread Sam Ruby

Aaron Mulder wrote:

 It's always going to be the case that the Avalon and Tomcat releases
 don't sync up perfectly.  How would you feel about making any Tomcat
 changes necessary to support the Avalon patch, but maintaining the
 Avalon block itself outside of the main Tomcat 4.0 module?  That way the
 Avalon support could be updated independently for new releases of Avalon
 *or* Tomcat.

Avalon is currently in Alpha.  This means that their APIs are subject to
change.

Once they ever release (or rather, if they ever release grin), then I
have been told that their APIs will be stable, and they will try to
maintain version to version incompatibility.

My preference is that mainline subprojects (no, I don't have a definition
for that term, but Tomcat clearly qualifies) do not support Avalon until
then.  This is to prevent version incompatibility problems, and hopefully
motivate Avalon to a release (I can always dream, can't I?).

So, my vote is as Remy originally stated - keep this in 4.1; drop it for
now from 4.0.

- Sam Ruby


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




Re: [PATCH] CatalinaBlock.java

2001-02-12 Thread Thom May

* Sam Ruby ([EMAIL PROTECTED]) wrote on Mon Feb 12, 2001 at 01:39:07PM -0500:
 Aaron Mulder wrote:
 
  It's always going to be the case that the Avalon and Tomcat releases
  don't sync up perfectly.  How would you feel about making any Tomcat
  changes necessary to support the Avalon patch, but maintaining the
  Avalon block itself outside of the main Tomcat 4.0 module?  That way the
  Avalon support could be updated independently for new releases of Avalon
  *or* Tomcat.
 
 Avalon is currently in Alpha.  This means that their APIs are subject to
 change.
 
 Once they ever release (or rather, if they ever release grin), then I
 have been told that their APIs will be stable, and they will try to
 maintain version to version incompatibility.
^
I really _really_ hope you mean version compatability here :)
-Thom

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




Modules subproject ( was: Re: [PATCH] CatalinaBlock.java )

2001-02-12 Thread cmanolache

 
 Actually, I was thinking starting a modules subprojects for things like that
 in 4.1.

It would be really great to have a module subproject !!! 

( as long as it will host 3.3 modules too :-)

This will keep the release more focused on the core functionality, and
simplify the testing and release.


-- 
Costin


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




Re: [PATCH] CatalinaBlock.java

2001-02-11 Thread Jason Brittain


Sam Ruby wrote:
 
 Jason van Zyl wrote:
 
 
  While playing with Sam Ruby's gump I noticed that
the
  CatalinaBlock is out of sync with Avalon. Not sure
if
  staying right up-to-date is critical but here's
the
  patch anyway.
 
 
 Until Avalon ships, tracking to the current APIs is
the only way to go.
 
 I've committed the changes.  Thanks!
 
 - Sam Ruby

If you like that patch, you'll probably also like
the ones I sent in on Friday -- messages with the
title
"[PATCH] TC4: TomcatBlock on Avalon 3.1a1"..

Cheers.



=
Jason Brittain
[EMAIL PROTECTED]

__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

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




Re: [PATCH] CatalinaBlock.java

2001-02-11 Thread Remy Maucherat

 If you like that patch, you'll probably also like
 the ones I sent in on Friday -- messages with the
 title
 "[PATCH] TC4: TomcatBlock on Avalon 3.1a1"..

I'm -1 on applying the Avalon patch in the 4.0 tree.
The rationale is :
- Avalon isn't ready yet. It's still in alpha stage, and I fear there may be
API changes in the pipeline.
- TC 4.0 should be out before Avalon. If Avalon 3.1 evolves *after* TC 4.0
is released, this would break the wrapper included in TC 4.0 and make it
incompatible with the Avalon 3.1 production release, which would more or
less force us to do a TC maintenance release.

For these reasons, I'd like to see an official Avalon wrapper introduced in
Tomcat 4.1, but not in Tomcat 4.0.
I also propose to remove the current Avalon wrapper from the Tomcat 4.0
repository, to avoid the maintenance related issues.

The 4.1 repository should be recreated very soon, since TC 4.0 has gone back
into feature freeze mode (but we want to fix the sealing violation problems
reported by many people before).

Remy


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




Re: [PATCH] CatalinaBlock.java

2001-02-10 Thread Sam Ruby

Jason van Zyl wrote:

 While playing with Sam Ruby's gump I noticed that the
 CatalinaBlock is out of sync with Avalon. Not sure if
 staying right up-to-date is critical but here's the
 patch anyway.

Until Avalon ships, tracking to the current APIs is the only way to go.

I've committed the changes.  Thanks!

- Sam Ruby


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