Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat4 and Tomcat 5

[Jeanfrancois Arcand]

Remy Maucherat wrote:


Costin Manolache wrote:


Glenn Nielsen wrote:



Remy Maucherat wrote:


Glenn Nielsen wrote:



With Tomcat 4.1 released many tomcat developers have been reticent to
add new features
to its codebase for a number of reasons.  All the development 
going on
in Tomcat 5 and
wanting to keep the number of codebase's where bug fix patches 
have to
be applied to a
minimum.

There are alot of ideas for new features that I would like to see end
up in a Tomcat 4.2
release. Especially since we don't know when the Servlet 2.4/JSP 2.0
specs will be finalized
so that Tomcat 5 can be released.

There isn't that much difference in the core of catalina between the
Servlet 2.3 and
Servlet 2.4 specs. It might be possible to change the
jakarta-tomcat-catalina codebase
to make it neutral to what Servlet spec is implemented.  Then this
codebase could be
used for future Tomcat 4 and Tomcat 5 development.  And we then 
have a
common codebase
for applying bug fix patches.

This seems to fit in with the direction we have been going where
different components
are kept in different code bases. naming, connectors, jasper, etc.

Comments?



This is hard to do (Catalina has never been written to allow facades).
Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 facade.




Right, I am aware of that. There isn't that much difference between
Servlet 2.3
and Servlet 2.4.  Having a common codebase for both would make 
addition of
new non spec related features easier and bug fix patching easier.



There are new methods in interfaces, etc. It won't be easy, I tried 
that ( for 2.2/2.3 ).

I agree with your idea of having common code between tomcat4 and tomcat5
( and tomcat3 ) - j-t-c is the best place to do that.

If we agree on a hook mechanism at coyote level - i.e. move auth* and 
other
hooks to implement Action or similar interface - then a lot of stuff 
can be moved to j-t-c ( or j-t-modules ) and be common. All auth*, 
mapping,
security - and we already have connectors and Request. 


I'm coming, I'm coming with a proposal :-)




That will also simplify the codebase in j-t-catalina - i.e. the code 
will
be more focused on implementing the servlet spec.


Yes, probably moving some code would be a nice solution. I'd prefer 
j-t-modules for that use, personally. 

Euh...I also like the module idea, but I share Remy's view and I doubt 
about having a single o.a.c workspace for all Servlet specs (starting 
2.3 & 2.4). Without facade, I don't see how we can achieve that. I would 
prefer having a shared workspace for everything except stuffs related to 
Servlet. Something like:

o.a.catalina (basic web server stuff)
o.a.catalina.servletEngine (where the Servlet spec is implemented)

or something like that. That probably what Facade meansMaybe I'm 
dreaming ;-). We should really think of having an extension mechanism 
where module can be added easily. The solution resides probably by 
having a consistent hook mechanism...




There needs to be someplace where new features can be added to the 
Tocmat
4 branch. You have been against adding new features to Tomcat 4 head,
creating a Tocmat 4.2 branch for developement, and now against making
j-t-catalina common to both Tomcat 4 & 5.



I think adding features in j-t-c was allways open, and so will be for
a potential j-t-module.

The reason for the negative votes on 4.2 was simple - if you find 3 
people to vote +1 on 4.2 ( i.e. who are interested in working on it 
), then
I don't see any reason not to do it.
I can hardly find time to work on 5.0 ( and thanks to Bill I don't 
have to
worry about 3.3 :-), and we have a lot of stuff on the todo list. That
shouldn't stop a 4.2 effort - if it gets at least the minimum 3 
committers.
I voted -0, I think Remy will change the vote to -0 as well. My -0 
means: I don't have time or interest in that, and I would preffer
that the features are done in 5.0 - but if 3 committers have this itch
I won't stop it.


This is a conspiracy ;-) I already voted -0 ;-) 

-0. I would prefer concentrating my works on 5.0 since I don't see a 
major difference between 4.2/5.0.  

-- Jeanfrancois



Remy


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat4 and Tomcat 5

[Remy Maucherat]

Costin Manolache wrote:

Glenn Nielsen wrote:



Remy Maucherat wrote:


Glenn Nielsen wrote:



With Tomcat 4.1 released many tomcat developers have been reticent to
add new features
to its codebase for a number of reasons.  All the development going on
in Tomcat 5 and
wanting to keep the number of codebase's where bug fix patches have to
be applied to a
minimum.

There are alot of ideas for new features that I would like to see end
up in a Tomcat 4.2
release. Especially since we don't know when the Servlet 2.4/JSP 2.0
specs will be finalized
so that Tomcat 5 can be released.

There isn't that much difference in the core of catalina between the
Servlet 2.3 and
Servlet 2.4 specs. It might be possible to change the
jakarta-tomcat-catalina codebase
to make it neutral to what Servlet spec is implemented.  Then this
codebase could be
used for future Tomcat 4 and Tomcat 5 development.  And we then have a
common codebase
for applying bug fix patches.

This seems to fit in with the direction we have been going where
different components
are kept in different code bases. naming, connectors, jasper, etc.

Comments?



This is hard to do (Catalina has never been written to allow facades).
Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 facade.



Right, I am aware of that. There isn't that much difference between
Servlet 2.3
and Servlet 2.4.  Having a common codebase for both would make addition of
new non spec related features easier and bug fix patching easier.



There are new methods in interfaces, etc. It won't be easy, I tried that 
( for 2.2/2.3 ).

I agree with your idea of having common code between tomcat4 and tomcat5
( and tomcat3 ) - j-t-c is the best place to do that.

If we agree on a hook mechanism at coyote level - i.e. move auth* and other
hooks to implement Action or similar interface - then a lot of stuff 
can be moved to j-t-c ( or j-t-modules ) and be common. All auth*, mapping,
security - and we already have connectors and Request.

That will also simplify the codebase in j-t-catalina - i.e. the code will
be more focused on implementing the servlet spec.

Yes, probably moving some code would be a nice solution. I'd prefer 
j-t-modules for that use, personally.

There needs to be someplace where new features can be added to the Tocmat
4 branch. You have been against adding new features to Tomcat 4 head,
creating a Tocmat 4.2 branch for developement, and now against making
j-t-catalina common to both Tomcat 4 & 5.



I think adding features in j-t-c was allways open, and so will be for
a potential j-t-module.

The reason for the negative votes on 4.2 was simple - if you find 3 people 
to vote +1 on 4.2 ( i.e. who are interested in working on it ), then
I don't see any reason not to do it. 

I can hardly find time to work on 5.0 ( and thanks to Bill I don't have to
worry about 3.3 :-), and we have a lot of stuff on the todo list. That
shouldn't stop a 4.2 effort - if it gets at least the minimum 3 committers.
I voted -0, I think Remy will change the vote to -0 as well. 
My -0 means: I don't have time or interest in that, and I would preffer
that the features are done in 5.0 - but if 3 committers have this itch
I won't stop it.

This is a conspiracy ;-) I already voted -0 ;-)

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat4 and Tomcat 5

[Remy Maucherat]

Glenn Nielsen wrote:

> Remy Maucherat wrote:
>
>> Glenn Nielsen wrote:
>>
>>> With Tomcat 4.1 released many tomcat developers have been reticent 
to add new features
>>> to its codebase for a number of reasons.  All the development going 
on in Tomcat 5 and
>>> wanting to keep the number of codebase's where bug fix patches have 
to be applied to a
>>> minimum.
>>>
>>> There are alot of ideas for new features that I would like to see 
end up in a Tomcat 4.2
>>> release. Especially since we don't know when the Servlet 2.4/JSP 
2.0 specs will be finalized
>>> so that Tomcat 5 can be released.
>>>
>>> There isn't that much difference in the core of catalina between 
the Servlet 2.3 and
>>> Servlet 2.4 specs. It might be possible to change the 
jakarta-tomcat-catalina codebase
>>> to make it neutral to what Servlet spec is implemented.  Then this 
codebase could be
>>> used for future Tomcat 4 and Tomcat 5 development.  And we then 
have a common codebase
>>> for applying bug fix patches.
>>>
>>> This seems to fit in with the direction we have been going where 
different components
>>> are kept in different code bases. naming, connectors, jasper, etc.
>>>
>>> Comments?
>>
>>
>>
>>
>> This is hard to do (Catalina has never been written to allow 
facades). Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 
facade.
>
>
>
>
> Right, I am aware of that. There isn't that much difference between 
Servlet 2.3
> and Servlet 2.4.  Having a common codebase for both would make 
addition of new
> non spec related features easier and bug fix patching easier.
>
>>
>> I'd like to point out that Jasper 2 from TC 5 is diverging from 
Jasper 2 from TC 4.1 very very quickly. Do you want a common codebase 
and some facades for that too ? ;-)
>>
>
> No. The JSP 2 spec changes from JSP 1.2 are so extensive it doesn't make
> sense to do so, also jasper is primarily implementing the JSP spec.
> Whereas the core of catalina is where all the non spec related 
features get added.


I mentioned Jasper since it was in your list of components in common.

>> Connectors is in common, because of the set of facades used in Coyote.
>>
>> I have no interest in that project, and see no point in trying to 
extend the life of the old API (given that the new one is quite similar).
>>
>> -0 from me (ie, go ahead if there's some developer interest; of 
course, implementation details will need to be discussed further).
>>
>> Remy
>>
>
> There needs to be someplace where new features can be added to the 
Tocmat 4 branch.
> You have been against adding new features to Tomcat 4 head, creating 
a Tocmat 4.2 branch for
> developement, and now against making j-t-catalina common to both 
Tomcat 4 & 5.


I am not against it (I would have been -1). I just think it is not such 
a great idea, so as it stands, I do not support it and don't plan to help.

BTW, I have been regularly adding features to 4.1.x, excluding the 
features which change existing behavior or lead to API changes (of 
course, given your recent posts, I guess you don't really know what 
occurred in tomcat-dev in the last 2 months). Please read the commits 
and the changelog.

> If this is what you want then perhaps you should propose a VOTE to 
freeze all work on
> Tomcat 4 except for bug fixes.  And I mean all work.  If the 
community votes to do that
> then I will stop asking and perhaps go review the rules for 
revolutionaries.


Glenn, I do not understand what is it that is not in 4.1 that you would 
want to add. Costin posted a comment the last time you mentioned 4.2 (I 
think it was one month ago), and I fully agree with it.

If you want to make a proposal, including a revolution, please do so. As 
is, my personal opinion is that having a common j-t-catalina between 4.x 
and 5.x is not doable from a technical standpoint (given that we have 
limited development resources), and even not desirable, as some API 
changes will be needed to make Catalina faster (right now, mapping and 
auth are really slow, and will need access to j-t-c/util objects to have 
acceptable speed and GC behavior).

Another possibility, given that the API 2.4 is close from 2.3, is that 
we release j-t-catalina as part of a 4.2 release, and advertise it as 
supporting servlets 2.3.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat4 and Tomcat 5

[Remy Maucherat]

Glenn Nielsen wrote:

Remy Maucherat wrote:


Glenn Nielsen wrote:


With Tomcat 4.1 released many tomcat developers have been reticent to 
add new features
to its codebase for a number of reasons.  All the development going 
on in Tomcat 5 and
wanting to keep the number of codebase's where bug fix patches have 
to be applied to a
minimum.

There are alot of ideas for new features that I would like to see end 
up in a Tomcat 4.2
release. Especially since we don't know when the Servlet 2.4/JSP 2.0 
specs will be finalized
so that Tomcat 5 can be released.

There isn't that much difference in the core of catalina between the 
Servlet 2.3 and
Servlet 2.4 specs. It might be possible to change the 
jakarta-tomcat-catalina codebase
to make it neutral to what Servlet spec is implemented.  Then this 
codebase could be
used for future Tomcat 4 and Tomcat 5 development.  And we then have 
a common codebase
for applying bug fix patches.

This seems to fit in with the direction we have been going where 
different components
are kept in different code bases. naming, connectors, jasper, etc.

Comments?



This is hard to do (Catalina has never been written to allow facades). 
Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 facade.



Right, I am aware of that. There isn't that much difference between 
Servlet 2.3
and Servlet 2.4.  Having a common codebase for both would make addition 
of new
non spec related features easier and bug fix patching easier.


I'd like to point out that Jasper 2 from TC 5 is diverging from Jasper 
2 from TC 4.1 very very quickly. Do you want a common codebase and 
some facades for that too ? ;-)


No. The JSP 2 spec changes from JSP 1.2 are so extensive it doesn't make
sense to do so, also jasper is primarily implementing the JSP spec.
Whereas the core of catalina is where all the non spec related features 
get added.

I mentioned Jasper since it was in your list of components in common.


Connectors is in common, because of the set of facades used in Coyote.

I have no interest in that project, and see no point in trying to 
extend the life of the old API (given that the new one is quite similar).

-0 from me (ie, go ahead if there's some developer interest; of 
course, implementation details will need to be discussed further).

Remy


There needs to be someplace where new features can be added to the 
Tocmat 4 branch.
You have been against adding new features to Tomcat 4 head, creating a 
Tocmat 4.2 branch for
developement, and now against making j-t-catalina common to both Tomcat 
4 & 5.

I am not against it (I would have been -1). I just think it is not such 
a great idea, so as it stands, I do not support it and don't plan to help.

BTW, I have been regularly adding features to 4.1.x, excluding the 
features which change existing behavior or lead to API changes (of 
course, given your recent posts, I guess you don't really know what 
occurred in tomcat-dev in the last 2 months). Please read the commits 
and the changelog.

If this is what you want then perhaps you should propose a VOTE to 
freeze all work on
Tomcat 4 except for bug fixes.  And I mean all work.  If the community 
votes to do that
then I will stop asking and perhaps go review the rules for 
revolutionaries.

Glenn, I do not understand what is it that is not in 4.1 that you would 
want to add. Costin posted a comment the last time you mentioned 4.2 (I 
think it was one month ago), and I fully agree with it.

If you want to make a proposal, including a revolution, please do so. As 
is, my personal opinion is that having a common j-t-catalina between 4.x 
and 5.x is not doable from a technical standpoint (given that we have 
limited development resources), and even not desirable, as some API 
changes will be needed to make Catalina faster (right now, mapping and 
auth are really slow, and will need access to j-t-c/util objects to have 
acceptable speed and GC behavior).

Another possibility, given that the API 2.4 is close from 2.3, is that 
we release j-t-catalina as part of a 4.2 release, and advertise it as 
supporting servlets 2.3.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat4 and Tomcat 5

[Glenn Nielsen]

Remy Maucherat wrote:

Glenn Nielsen wrote:


With Tomcat 4.1 released many tomcat developers have been reticent to 
add new features
to its codebase for a number of reasons.  All the development going on 
in Tomcat 5 and
wanting to keep the number of codebase's where bug fix patches have to 
be applied to a
minimum.

There are alot of ideas for new features that I would like to see end 
up in a Tomcat 4.2
release. Especially since we don't know when the Servlet 2.4/JSP 2.0 
specs will be finalized
so that Tomcat 5 can be released.

There isn't that much difference in the core of catalina between the 
Servlet 2.3 and
Servlet 2.4 specs. It might be possible to change the 
jakarta-tomcat-catalina codebase
to make it neutral to what Servlet spec is implemented.  Then this 
codebase could be
used for future Tomcat 4 and Tomcat 5 development.  And we then have a 
common codebase
for applying bug fix patches.

This seems to fit in with the direction we have been going where 
different components
are kept in different code bases. naming, connectors, jasper, etc.

Comments?


This is hard to do (Catalina has never been written to allow facades). 
Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 facade.


Right, I am aware of that. There isn't that much difference between Servlet 2.3
and Servlet 2.4.  Having a common codebase for both would make addition of new
non spec related features easier and bug fix patching easier.



I'd like to point out that Jasper 2 from TC 5 is diverging from Jasper 2 
from TC 4.1 very very quickly. Do you want a common codebase and some 
facades for that too ? ;-)


No. The JSP 2 spec changes from JSP 1.2 are so extensive it doesn't make
sense to do so, also jasper is primarily implementing the JSP spec.
Whereas the core of catalina is where all the non spec related features get added.


Connectors is in common, because of the set of facades used in Coyote.

I have no interest in that project, and see no point in trying to extend 
the life of the old API (given that the new one is quite similar).

-0 from me (ie, go ahead if there's some developer interest; of course, 
implementation details will need to be discussed further).

Remy


There needs to be someplace where new features can be added to the Tocmat 4 branch.
You have been against adding new features to Tomcat 4 head, creating a Tocmat 4.2 branch for
developement, and now against making j-t-catalina common to both Tomcat 4 & 5.

If this is what you want then perhaps you should propose a VOTE to freeze all work on
Tomcat 4 except for bug fixes.  And I mean all work.  If the community votes to do that
then I will stop asking and perhaps go review the rules for revolutionaries.

Regards,

Glenn



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat4 and Tomcat 5

[Remy Maucherat]

Remy Maucherat wrote:

Glenn Nielsen wrote:


With Tomcat 4.1 released many tomcat developers have been reticent to 
add new features
to its codebase for a number of reasons.  All the development going on 
in Tomcat 5 and
wanting to keep the number of codebase's where bug fix patches have to 
be applied to a
minimum.

There are alot of ideas for new features that I would like to see end 
up in a Tomcat 4.2
release. Especially since we don't know when the Servlet 2.4/JSP 2.0 
specs will be finalized
so that Tomcat 5 can be released.

There isn't that much difference in the core of catalina between the 
Servlet 2.3 and
Servlet 2.4 specs. It might be possible to change the 
jakarta-tomcat-catalina codebase
to make it neutral to what Servlet spec is implemented.  Then this 
codebase could be
used for future Tomcat 4 and Tomcat 5 development.  And we then have a 
common codebase
for applying bug fix patches.

This seems to fit in with the direction we have been going where 
different components
are kept in different code bases. naming, connectors, jasper, etc.

Comments?


This is hard to do (Catalina has never been written to allow facades). 
Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 facade.

I'd like to point out that Jasper 2 from TC 5 is diverging from Jasper 2 
from TC 4.1 very very quickly. Do you want a common codebase and some 
facades for that too ? ;-)

Connectors is in common, because of the set of facades used in Coyote.

I have no interest in that project, and see no point in trying to extend 
the life of the old API (given that the new one is quite similar).

-0 from me (ie, go ahead if there's some developer interest; of course, 
implementation details will need to be discussed further).

I'd like to add that these comments only apply to a portion of the code 
in j-t-catalina. A significant amount of code is independent (the 
stores, the auth, the realms, etc, etc), and could be put in that 
legendary j-t-modules repository ;-)

I don't see how j-t-jasper could be independent of the API (nor the rest 
of j-t-catalina); at least not without a prohibitive amount of work.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat4 and Tomcat 5

[Remy Maucherat]

Glenn Nielsen wrote:

With Tomcat 4.1 released many tomcat developers have been reticent to 
add new features
to its codebase for a number of reasons.  All the development going on 
in Tomcat 5 and
wanting to keep the number of codebase's where bug fix patches have to 
be applied to a
minimum.

There are alot of ideas for new features that I would like to see end up 
in a Tomcat 4.2
release. Especially since we don't know when the Servlet 2.4/JSP 2.0 
specs will be finalized
so that Tomcat 5 can be released.

There isn't that much difference in the core of catalina between the 
Servlet 2.3 and
Servlet 2.4 specs. It might be possible to change the 
jakarta-tomcat-catalina codebase
to make it neutral to what Servlet spec is implemented.  Then this 
codebase could be
used for future Tomcat 4 and Tomcat 5 development.  And we then have a 
common codebase
for applying bug fix patches.

This seems to fit in with the direction we have been going where 
different components
are kept in different code bases. naming, connectors, jasper, etc.

Comments?

This is hard to do (Catalina has never been written to allow facades). 
Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 facade.

I'd like to point out that Jasper 2 from TC 5 is diverging from Jasper 2 
from TC 4.1 very very quickly. Do you want a common codebase and some 
facades for that too ? ;-)

Connectors is in common, because of the set of facades used in Coyote.

I have no interest in that project, and see no point in trying to extend 
the life of the old API (given that the new one is quite similar).

-0 from me (ie, go ahead if there's some developer interest; of course, 
implementation details will need to be discussed further).

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat4 and Tomcat 5

[Glenn Nielsen]

With Tomcat 4.1 released many tomcat developers have been reticent to add new features
to its codebase for a number of reasons.  All the development going on in Tomcat 5 and
wanting to keep the number of codebase's where bug fix patches have to be applied to a
minimum.

There are alot of ideas for new features that I would like to see end up in a Tomcat 4.2
release. Especially since we don't know when the Servlet 2.4/JSP 2.0 specs will be finalized
so that Tomcat 5 can be released.

There isn't that much difference in the core of catalina between the Servlet 2.3 and
Servlet 2.4 specs. It might be possible to change the jakarta-tomcat-catalina codebase
to make it neutral to what Servlet spec is implemented.  Then this codebase could be
used for future Tomcat 4 and Tomcat 5 development.  And we then have a common codebase
for applying bug fix patches.

This seems to fit in with the direction we have been going where different components
are kept in different code bases. naming, connectors, jasper, etc.

Comments?

Regards,

Glenn


--
To unsubscribe, e-mail:   
For additional commands, e-mail: