You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Glenn Nielsen <gl...@mail.more.net> on 2002/11/11 06:44:35 UTC
JSPC refactoring/documentation
Based on problems reported by users of JSPC Remy made a proposal
to deprecate it.
This resulted in a number of people responding that they used JSPC
and strongly felt it should be kept.
There did seem to be some consensus that JSPC could beneifit from
a review and refactoring to make it easier to use.
It could also benefit from better documentation if it is to remain
part of Tomcat.
Perhaps those who so strongly support JSPC should take the lead to
review, refactor, simplify, and better document JSPC. Perhaps a
JSPC-HOWTO for the Tomcat docs once the refactoring is completed?
This could be part of a Tomcat 4.2 development effort.
There has been some discussion about other possible new features.
Some new features/changes that have been discussed:
A SecurityManager XML Policy file that allows secure delegation
to web applications for setting their own policies (within a sandbox).
Using JMX to instrument Tomcat for production runtime monitoring.
Possibly a JSPC refactoring.
Audit the SecurityManager web application sandbox.
Are there other changes/features that could be part of Tomcat 4.2 development?
I have a laundry list of smaller issues I would like to address. Nothing major.
Regards,
Glenn
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSPC refactoring/documentation
Posted by Remy Maucherat <re...@apache.org>.
Jon Scott Stevens wrote:
> on 2002/11/11 10:10 AM, "Remy Maucherat" wrote:
>
>
> >I'm now independent and unemployed, so I'm not aware of the Sun
> >schedules for the spec anymore :-P
>
>
> I'm sorry to hear that Remy.
Yeah, I miss knowing the schedule ;-)
Don't worry too much, I'm on vacation at the moment. Finding OSS related
jobs is quite hard, OTOH (but I don't think this will surprise anyone :) ).
>
>
> >Probably within 3-6 months given J2EE
> >1.4 is in beta. The rule is we cannot release a stable version of 5.0.x
> >until the specs are final.
>
>
> I have to disagree here with the 'rules'. Tomcat is an open source project
> as well as the spec. We are not bound by those terms. Jason, please
> correct
> me if I am wrong.
The idea is that one cannot claim to implement a spec which doesn't
exist yet. I don't know what the contract actually says (I suppose I
could check).
We probably will not be in a position to release a stable version of
Tomcat 5 anytime soon if we keep our current feature additions plan, so
it doesn't matter much.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSPC refactoring/documentation
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 2002/11/11 10:10 AM, "Remy Maucherat" <re...@apache.org> wrote:
> I'm now independent and unemployed, so I'm not aware of the Sun
> schedules for the spec anymore :-P
I'm sorry to hear that Remy.
> Probably within 3-6 months given J2EE
> 1.4 is in beta. The rule is we cannot release a stable version of 5.0.x
> until the specs are final.
I have to disagree here with the 'rules'. Tomcat is an open source project
as well as the spec. We are not bound by those terms. Jason, please correct
me if I am wrong.
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSPC refactoring/documentation
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Glenn Nielsen wrote:
>
>
>
> >If I understand correctly, what you are saying above is that Tomcat 4
> >development should be frozen except for bug fixes and all changes and new
> >features go in
> >Tomcat 5? Is that a correct summary? If so I think it is premature
> to do
> >so, especially since a production quality version of Tomcat 5 could
> take 6
> >months.
>
>
> The real problem is the new servlet/jsp spec and implementation. All the
> extra code is reasonably stable.
>
> I don't know how hard it would be to separate the servlet-specific
> classes,
> and use the same codebase for a 4.x release.
There's also the problem that some modules with API dependencies are
getting really big (Jasper 2), so there's less interest to have that
capability. At least the really tricky code (the connectors) is now in
common. So we can't get back to the Tomcat 4.0 situation.
>
> IMHO - if you get 3 +1 votes for 4.2 - I won't opose it ( meaning people
> willing to work on it ). I am spending all my free time on 5.0 and ant
> ( I
> only review the excelent commits that Bill makes in 3.3, sorry I can't
> help
> more).
>
+1. This seems reasonable. If this gets some interest (and is indeed
needed), I would like to have mentioned in the release plan that
relevant patches have to be ported to 5.0, to avoid maintenance problems
in the upcoming release cycle.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSPC refactoring/documentation
Posted by Costin Manolache <cm...@yahoo.com>.
Glenn Nielsen wrote:
> If I understand correctly, what you are saying above is that Tomcat 4
> development should be frozen except for bug fixes and all changes and new
> features go in
> Tomcat 5? Is that a correct summary? If so I think it is premature to do
> so, especially since a production quality version of Tomcat 5 could take 6
> months.
The real problem is the new servlet/jsp spec and implementation. All the
extra code is reasonably stable.
I don't know how hard it would be to separate the servlet-specific classes,
and use the same codebase for a 4.x release.
IMHO - if you get 3 +1 votes for 4.2 - I won't opose it ( meaning people
willing to work on it ). I am spending all my free time on 5.0 and ant ( I
only review the excelent commits that Bill makes in 3.3, sorry I can't help
more).
> If we are just maintaining Tomcat 4.1 (bug fixes), I would be willing to
> port any bug fixes to the Tocmat 4.1 branch into a Tocmat 4.2 development
> branch. And when a 4.2 branch is ready, willing to act as the release
> manager if you are not interested in doing so.
Propose a vote then.
Again - if 3 committers are willing to work on 4.2, then probably there
is a need for it. I would prefer the features to be done on 5.0 ( or 3.3
:-), but everyone should deal with his itches.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSPC refactoring/documentation
Posted by Fredrik Westermarck <fr...@mdh.se>.
Costin Manolache wrote:
>>The problem that I and others have experienced is that proposals and/or
>>patches, by non-committers, don't get discussed or voted about.
> You have to keep pushing.
Well I did, but the next person might not. In that case the community as
a whole may miss important features or ideas.
> If you send patches and proposals you can
> become a committer - and then you'll start ignoring patches and proposals
> :-)
If I was a committer I wouldn't feel good about ignoring patches and
proposals. By the way isn't ignoring patches/proposals the opposite of
what a committer is supposed to do?
> I'm sorry - but everyone is very short on time.
Yes, I do know that and respect that.
> Is there any concrete feature that you need in 4.1 but is not implemented ?
Not anymore. :)
> What's important ( IMO ) is that at the moment it seems more people are
> actively working on 5.0, so its easier to get things changed there.
> 4.1 is stable - and it's normal to be a high resistence to bigger changes.
I didn't know that Tomcat 4 (as it seems now) wasn't to be actively
maintained and improved. I thought Tomcat 5 goal was to improve Tomcat 4
and implement the new Servlet- and JSP-specs.
Maybe the community has to be told that 4.1 is in 'high resistence'-mode
so that ppl know that they should test their apps with 5.0 if they want
or is waiting for new features that have been proposed.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSPC refactoring/documentation
Posted by Donald Ball <db...@rhoworld.com>.
On 11/12/2002 at 4:03 PM Costin Manolache wrote:
>Fredrik Westermarck wrote:
>
>> The problem that I and others have experienced is that proposals and/or
>> patches, by non-committers, don't get discussed or voted about.
>
>You have to keep pushing. If you send patches and proposals you can
>become a committer - and then you'll start ignoring patches and proposals
>:-)
I know you mean that in jest, but I have two big problems with what you
said:
1. Simply sending patches and proposals is enough to become a committer? On
the other apache projects on which I've worked, several months of
consistent quality patches and involvement on the lists is necessary to
achieve committer status.
2. Committers ignore patches and proposals from non-committers - though
said with smilies, does seem to be the status quo, from my personal
experience and that of others. Do you not see this as a problem?
Not every guy who finds (and patches!) a bug in tomcat has the time or
interest to become a committer (nor should they), and I don't think you
should require that before their patches have a chance to get in. I know
that no one ever has enough time to do everything, and staying on top of
patch submissions can be a chore, yes. With enough committers, and tomcat
certainly seems to have enough, you can manage - make it a rotating chore
to scan the developers list, tell patchers that they should contact the
module authors directly, use bugzilla to manage the patch queue, etc.,
etc., etc.
>I'm sorry - but everyone is very short on time. If you have a real
interest
>in tomcat the best solution is to send patches, insist on getting them
>accepted and become a committer. I think many people here will tell you
>it's not that hard.
Therein lies the rub. Not every joe that comes up with a patch for tomcat
should get committer access, in my eyes. Nor should the tomcat developers
ignore contributed patches. There's got to be a better way.
- donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSPC refactoring/documentation
Posted by Costin Manolache <cm...@yahoo.com>.
Fredrik Westermarck wrote:
> The problem that I and others have experienced is that proposals and/or
> patches, by non-committers, don't get discussed or voted about.
You have to keep pushing. If you send patches and proposals you can
become a committer - and then you'll start ignoring patches and proposals
:-)
I'm sorry - but everyone is very short on time. If you have a real interest
in tomcat the best solution is to send patches, insist on getting them
accepted and become a committer. I think many people here will tell you
it's not that hard.
>>>Since I'm not aware of the TC 5.0 requirements regarding the JDK and
>>>such I might be wrong here but...
>> AFAIK - JDK1.3.
>> ( it should work fine with JDK1.2, but I don't think it is tested that
>> much ).
>
> Should...
Are you on JDK1.2 ?
Is there any concrete feature that you need in 4.1 but is not implemented ?
>> TC5.0 should be backward compatible.
>
> Should... Yes I also tell my customers that it should work, even if you
> never can be 100% sure. :-)
Download the milestones, test your application - and if it doesn't work
submit bug reports or patches.
It is quite possible to have a change between minor releases that would
brake your app. You can never know if it is not tested.
What's important ( IMO ) is that at the moment it seems more people are
actively working on 5.0, so its easier to get things changed there.
4.1 is stable - and it's normal to be a high resistence to bigger changes.
It's a case-by-case decision - if a feature is extremely important
and you have good arguments to convince 2-3 committers and you have the
patch - than it's very likely it'll be accepted ( including for 4.0 or
3.3).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSPC refactoring/documentation
Posted by Fredrik Westermarck <fr...@mdh.se>.
Costin Manolache wrote:
>>Do you actually mean that a new feature will only be added if there is
>>enough committers that need the feature? Does this apply only to 4.1.x?
> Well... In theory it should apply to all tomcat features, or at
> least to important ones - they must be first proposed on the list,
> discussed, and then voted. We use 'lazy consensus' ( i.e. commit
> first and wait for -1 ) a bit too much.
Well there is quite a difference between needs and accepts.
The problem that I and others have experienced is that proposals and/or
patches, by non-committers, don't get discussed or voted about.
>>Since I'm not aware of the TC 5.0 requirements regarding the JDK and
>>such I might be wrong here but...
> AFAIK - JDK1.3.
> ( it should work fine with JDK1.2, but I don't think it is tested that
> much ).
Should...
>>My guess is that many users will not be able to switch to TC 5.0 when it
>>is released since their applications might have to be modified and in
>>many cases also be unable to switch since their application might not be
>>tested with the required JDK.
> TC5.0 should be backward compatible.
Should... Yes I also tell my customers that it should work, even if you
never can be 100% sure. :-)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSPC refactoring/documentation
Posted by Costin Manolache <cm...@yahoo.com>.
Fredrik Westermarck wrote:
> Do you actually mean that a new feature will only be added if there is
> enough committers that need the feature? Does this apply only to 4.1.x?
Well... In theory it should apply to all tomcat features, or at
least to important ones - they must be first proposed on the list,
discussed, and then voted. We use 'lazy consensus' ( i.e. commit
first and wait for -1 ) a bit too much.
I was refering to the proposed tomcat 4.2 release. It needs at least
3 +1 votes - i.e. committers who are willing to spend time on it.
> Since I'm not aware of the TC 5.0 requirements regarding the JDK and
> such I might be wrong here but...
AFAIK - JDK1.3.
( it should work fine with JDK1.2, but I don't think it is tested that
much ).
> My guess is that many users will not be able to switch to TC 5.0 when it
> is released since their applications might have to be modified and in
> many cases also be unable to switch since their application might not be
> tested with the required JDK.
TC5.0 should be backward compatible.
> If so wouldn't it be better if new features could be implemented into TC
> 4.x?
The real question is who is going to do that. As I said, if there are people
who need it and are willing to do the work - then it'll happen.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSPC refactoring/documentation
Posted by Fredrik Westermarck <fr...@mdh.se>.
Costin Manolache wrote:
>>I consider 4.1.x can recieve bug fixes and minor feature additions
>>(example: the JNDI realm new feature which just got added,
>>optimisations, etc ...), similar to HTTPd 2.0. This is consistent with
>>the patches I and others have been applying, the release process we've
>>been following, and so on.
>
>
> +1
>
> If there is enough interest and committers that need that feature -
> I see no problem with that.
Do you actually mean that a new feature will only be added if there is
enough committers that need the feature? Does this apply only to 4.1.x?
Since I'm not aware of the TC 5.0 requirements regarding the JDK and
such I might be wrong here but...
My guess is that many users will not be able to switch to TC 5.0 when it
is released since their applications might have to be modified and in
many cases also be unable to switch since their application might not be
tested with the required JDK.
If so wouldn't it be better if new features could be implemented into TC
4.x?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSPC refactoring/documentation
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> I consider 4.1.x can recieve bug fixes and minor feature additions
> (example: the JNDI realm new feature which just got added,
> optimisations, etc ...), similar to HTTPd 2.0. This is consistent with
> the patches I and others have been applying, the release process we've
> been following, and so on.
+1
If there is enough interest and committers that need that feature -
I see no problem with that.
As procedure, I think it would be nice to announce the new features
before commiting them.
IMO the best way to improve this in future is to separate the 'core'
and modules, or at least have a separate directory for add-on features
and modules. This way the 'core' release can be frozen, but new features
can be easily added. Given the backward compatibility it is even possible
to even share the modules for multiple tomcat versions ( probably some
doc should mention if it was tested with 4.0, 4.1 or 5.0 ).
This may also increase the release cycle and reduce the load for the RM
( or at least allow the load to be spread - since modules could be
released separately ).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSPC refactoring/documentation
Posted by Remy Maucherat <re...@apache.org>.
Glenn Nielsen wrote:
> Remy Maucherat wrote:
>
> > Glenn Nielsen wrote:
> >
>
> > I'm now independent and unemployed, so I'm not aware of the Sun
> > schedules for the spec anymore :-P Probably within 3-6 months given
> > J2EE 1.4 is in beta. The rule is we cannot release a stable version of
> > 5.0.x until the specs are final.
> >
> > Rémy
> >
>
> If I understand correctly, what you are saying above is that Tomcat 4
> development
> should be frozen except for bug fixes and all changes and new features
> go in
> Tomcat 5? Is that a correct summary? If so I think it is premature to
> do so,
> especially since a production quality version of Tomcat 5 could take 6
> months.
>
> If we are just maintaining Tomcat 4.1 (bug fixes), I would be willing to
> port
> any bug fixes to the Tocmat 4.1 branch into a Tocmat 4.2 development
> branch.
> And when a 4.2 branch is ready, willing to act as the release manager if
> you are
> not interested in doing so.
I consider 4.1.x can recieve bug fixes and minor feature additions
(example: the JNDI realm new feature which just got added,
optimisations, etc ...), similar to HTTPd 2.0. This is consistent with
the patches I and others have been applying, the release process we've
been following, and so on.
You may want to clarify your intentions, and since this release process
has been going on for 6+ months, I fail to see how you could be
surprised at how things are getting done ;-)
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSPC refactoring/documentation
Posted by Remy Maucherat <re...@apache.org>.
John Trollinger wrote:
> Has there or will there be any type of requirement gathering on jspc
> refactoring.
>
> I would like to help refactor this but would like to know what options
> need to be supported / added and which ones to remove.
Everyone has apparently different opinions on what features should be in
jspc. I think a poll should be made to sort it out ;-)
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: JSPC refactoring/documentation
Posted by John Trollinger <ja...@trollingers.com>.
Has there or will there be any type of requirement gathering on jspc
refactoring.
I would like to help refactor this but would like to know what options
need to be supported / added and which ones to remove.
John
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSPC refactoring/documentation
Posted by Glenn Nielsen <gl...@mail.more.net>.
Remy Maucherat wrote:
> Glenn Nielsen wrote:
>
>> Remy Maucherat wrote:
>>
>> > Bill Barker wrote:
>> >
>> >
>> >
>> > I think we have too many dev branches already, and this is causing
>> > maintenance problems. I'd like to have those things go in either 4.1
>> > or 5.0. Esp the jspc refactoring ;-) jspc is currently broken in 4.1
>> > and not really usable to a normal Tomcat user, it needs to be fixed in
>> > 4.1.x. Please :)
>> >
>>
>> Doing development in the 4.1 branch would limit the ability to do bug
>> fix releases on 4.1. Perhaps if an effort to resolve all know 4.1
>> bugs was made we would see the number of bug reports for 4.1 decrease.
>> That would make a 4.2 development branch easier to do while still
>> maintaining 4.1.
>>
>> We could try to keep the time 4.2 is in development to a minimum,
>> perhaps a couple of months. Once 4.2 was released the 4.1 branch
>> could be retired with all bug fixes going in 4.2 (HEAD).
>>
>> Why not wait and see if there are more signficant changes/new features
>> proposed for a possible 4.2 release. And if there are committers willing
>> to assist porting bug fixes between the branches while 4.2 is under
>> development.
>
>
>
> So far, I'm not in favor of a 4.2 branch, as I would like to avoid
> fragmentation. If:
> - 4.1 is put in a security-fix only mode
> - all new features are ported to 5.0
> - all relevant bugfixes are ported to 5.0
> Then fragmentation cannot happen, and I would be in favor of it, and
> could maybe RM it (since I wouldn't be doing anything on 4.1), if 4.2 is
> proven to be useful.
>
> On the features list:
> - A SecurityManager XML Policy file that allows secure delegation
> to web applications for setting their own policies (within a sandbox):
> as far as I can remember, this recieved negative feedback. This is sort
> of something which IMHO should be part of a future JDK. I don't really
> see what it has to do with Tomcat (except if would be a useful JDK
> feature to use). It could be developped in the Commons sandbox if you're
> interested.
> - jspc: it should be done in 4.1 (it is not really usable at the moment
> unless you know the code). Even if it's a major refactoring, we have to
> do it there *or* we have to remove the feature for now. Given the
> different view everyone has on jspc (and me who doesn't really care
> about what it does ;-) ), I think someone should start a poll on which
> committers would vote.
> - Using JMX to instrument Tomcat for production runtime monitoring: I
> have no idea what you want to do. I think it might be better in 5.0.
> - Audit the SecurityManager web application sandbox: This has been done
> in 5.0, and the result could be ported to 4.1, esp if the sandbox is
> somewhat deficient.
>
>>
>> > I'd also like to point out that the servlet API changes are very
>> > limited, and it will be possible to use Tomcat 5.0 with the Jasper
>> > from Tomcat 4.1. So I think "major" new features should go in the 5.0
>> > codebase.
>> >
>> > Rémy
>> >
>>
>> What is a realistic timeline for 5.0 being released?
>
>
>
> I'm now independent and unemployed, so I'm not aware of the Sun
> schedules for the spec anymore :-P Probably within 3-6 months given J2EE
> 1.4 is in beta. The rule is we cannot release a stable version of 5.0.x
> until the specs are final.
>
> Rémy
>
If I understand correctly, what you are saying above is that Tomcat 4 development
should be frozen except for bug fixes and all changes and new features go in
Tomcat 5? Is that a correct summary? If so I think it is premature to do so,
especially since a production quality version of Tomcat 5 could take 6 months.
If we are just maintaining Tomcat 4.1 (bug fixes), I would be willing to port
any bug fixes to the Tocmat 4.1 branch into a Tocmat 4.2 development branch.
And when a 4.2 branch is ready, willing to act as the release manager if you are
not interested in doing so.
Regards,
Glenn
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSPC refactoring/documentation
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Remy Maucherat" <re...@apache.org> wrote:
>>> I'd also like to point out that the servlet API changes are very
>>> limited, and it will be possible to use Tomcat 5.0 with the Jasper
>>> from Tomcat 4.1. So I think "major" new features should go in the 5.0
>>> codebase.
>>>
>>
>> What is a realistic timeline for 5.0 being released?
>
> I'm now independent and unemployed, so I'm not aware of the Sun
> schedules for the spec anymore :-P Probably within 3-6 months given J2EE
> 1.4 is in beta. The rule is we cannot release a stable version of 5.0.x
> until the specs are final.
Regarding servlets, the JSR-154 Spec Lead did not inform us yet of any
deadline... I know that Sun wants to have it out "soonish", but there are
still quite few bits and bobs to sort out (like friggin' schema).
If you have questions regarding JSR-154 (requirements/info/...) contact me
as I'm still the official representative for the ASF on the JCP expert
group.
Have fun...
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSPC refactoring/documentation
Posted by Remy Maucherat <re...@apache.org>.
Glenn Nielsen wrote:
> Remy Maucherat wrote:
>
> > Bill Barker wrote:
> >
> >
> >
> > I think we have too many dev branches already, and this is causing
> > maintenance problems. I'd like to have those things go in either 4.1
> > or 5.0. Esp the jspc refactoring ;-) jspc is currently broken in 4.1
> > and not really usable to a normal Tomcat user, it needs to be fixed in
> > 4.1.x. Please :)
> >
>
> Doing development in the 4.1 branch would limit the ability to do bug
> fix releases on 4.1. Perhaps if an effort to resolve all know 4.1
> bugs was made we would see the number of bug reports for 4.1 decrease.
> That would make a 4.2 development branch easier to do while still
> maintaining 4.1.
>
> We could try to keep the time 4.2 is in development to a minimum,
> perhaps a couple of months. Once 4.2 was released the 4.1 branch
> could be retired with all bug fixes going in 4.2 (HEAD).
>
> Why not wait and see if there are more signficant changes/new features
> proposed for a possible 4.2 release. And if there are committers willing
> to assist porting bug fixes between the branches while 4.2 is under
> development.
So far, I'm not in favor of a 4.2 branch, as I would like to avoid
fragmentation. If:
- 4.1 is put in a security-fix only mode
- all new features are ported to 5.0
- all relevant bugfixes are ported to 5.0
Then fragmentation cannot happen, and I would be in favor of it, and
could maybe RM it (since I wouldn't be doing anything on 4.1), if 4.2 is
proven to be useful.
On the features list:
- A SecurityManager XML Policy file that allows secure delegation
to web applications for setting their own policies (within a sandbox):
as far as I can remember, this recieved negative feedback. This is sort
of something which IMHO should be part of a future JDK. I don't really
see what it has to do with Tomcat (except if would be a useful JDK
feature to use). It could be developped in the Commons sandbox if you're
interested.
- jspc: it should be done in 4.1 (it is not really usable at the moment
unless you know the code). Even if it's a major refactoring, we have to
do it there *or* we have to remove the feature for now. Given the
different view everyone has on jspc (and me who doesn't really care
about what it does ;-) ), I think someone should start a poll on which
committers would vote.
- Using JMX to instrument Tomcat for production runtime monitoring: I
have no idea what you want to do. I think it might be better in 5.0.
- Audit the SecurityManager web application sandbox: This has been done
in 5.0, and the result could be ported to 4.1, esp if the sandbox is
somewhat deficient.
>
> > I'd also like to point out that the servlet API changes are very
> > limited, and it will be possible to use Tomcat 5.0 with the Jasper
> > from Tomcat 4.1. So I think "major" new features should go in the 5.0
> > codebase.
> >
> > Rémy
> >
>
> What is a realistic timeline for 5.0 being released?
I'm now independent and unemployed, so I'm not aware of the Sun
schedules for the spec anymore :-P Probably within 3-6 months given J2EE
1.4 is in beta. The rule is we cannot release a stable version of 5.0.x
until the specs are final.
Rémy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSPC refactoring/documentation
Posted by Glenn Nielsen <gl...@mail.more.net>.
Remy Maucherat wrote:
> Bill Barker wrote:
>
>> >Based on problems reported by users of JSPC Remy made a proposal
>> >to deprecate it.
>> >
>> >This resulted in a number of people responding that they used JSPC
>> >and strongly felt it should be kept.
>> >
>> >There did seem to be some consensus that JSPC could beneifit from
>> >a review and refactoring to make it easier to use.
>> >
>> >It could also benefit from better documentation if it is to remain
>> >part of Tomcat.
>> >
>> >Perhaps those who so strongly support JSPC should take the lead to
>> >review, refactor, simplify, and better document JSPC. Perhaps a
>> >JSPC-HOWTO for the Tomcat docs once the refactoring is completed?
>> >
>> >
>> >This could be part of a Tomcat 4.2 development effort.
>> >There has been some discussion about other possible new features.
>> >
>> >Some new features/changes that have been discussed:
>> >
>> >A SecurityManager XML Policy file that allows secure delegation
>> >to web applications for setting their own policies (within a sandbox).
>> >
>> >Using JMX to instrument Tomcat for production runtime monitoring.
>> >
>> >Possibly a JSPC refactoring.
>> >
>> >Audit the SecurityManager web application sandbox.
>> >
>> >Are there other changes/features that could be part of Tomcat 4.2
>>
>> development?
>>
>>
>> >From previous posts, I gather that Remy isn't interested in RMing a 4.2
>> release. Unless Remy jumps in and tells me that I don't know what I'm
>> talking about :), the biggest change would be to find someone to
>> volunteer
>> to RM it.
>
>
>
> I think we have too many dev branches already, and this is causing
> maintenance problems. I'd like to have those things go in either 4.1 or
> 5.0. Esp the jspc refactoring ;-) jspc is currently broken in 4.1 and
> not really usable to a normal Tomcat user, it needs to be fixed in
> 4.1.x. Please :)
>
Doing development in the 4.1 branch would limit the ability to do bug
fix releases on 4.1. Perhaps if an effort to resolve all know 4.1
bugs was made we would see the number of bug reports for 4.1 decrease.
That would make a 4.2 development branch easier to do while still maintaining 4.1.
We could try to keep the time 4.2 is in development to a minimum,
perhaps a couple of months. Once 4.2 was released the 4.1 branch
could be retired with all bug fixes going in 4.2 (HEAD).
Why not wait and see if there are more signficant changes/new features
proposed for a possible 4.2 release. And if there are committers willing
to assist porting bug fixes between the branches while 4.2 is under
development.
> I'd also like to point out that the servlet API changes are very
> limited, and it will be possible to use Tomcat 5.0 with the Jasper from
> Tomcat 4.1. So I think "major" new features should go in the 5.0 codebase.
>
> Rémy
>
What is a realistic timeline for 5.0 being released?
Regards,
Glenn
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSPC refactoring/documentation
Posted by Remy Maucherat <re...@apache.org>.
Bill Barker wrote:
> >Based on problems reported by users of JSPC Remy made a proposal
> >to deprecate it.
> >
> >This resulted in a number of people responding that they used JSPC
> >and strongly felt it should be kept.
> >
> >There did seem to be some consensus that JSPC could beneifit from
> >a review and refactoring to make it easier to use.
> >
> >It could also benefit from better documentation if it is to remain
> >part of Tomcat.
> >
> >Perhaps those who so strongly support JSPC should take the lead to
> >review, refactor, simplify, and better document JSPC. Perhaps a
> >JSPC-HOWTO for the Tomcat docs once the refactoring is completed?
> >
> >
> >This could be part of a Tomcat 4.2 development effort.
> >There has been some discussion about other possible new features.
> >
> >Some new features/changes that have been discussed:
> >
> >A SecurityManager XML Policy file that allows secure delegation
> >to web applications for setting their own policies (within a sandbox).
> >
> >Using JMX to instrument Tomcat for production runtime monitoring.
> >
> >Possibly a JSPC refactoring.
> >
> >Audit the SecurityManager web application sandbox.
> >
> >Are there other changes/features that could be part of Tomcat 4.2
>
> development?
>
>
> >From previous posts, I gather that Remy isn't interested in RMing a 4.2
> release. Unless Remy jumps in and tells me that I don't know what I'm
> talking about :), the biggest change would be to find someone to volunteer
> to RM it.
I think we have too many dev branches already, and this is causing
maintenance problems. I'd like to have those things go in either 4.1 or
5.0. Esp the jspc refactoring ;-) jspc is currently broken in 4.1 and
not really usable to a normal Tomcat user, it needs to be fixed in
4.1.x. Please :)
I'd also like to point out that the servlet API changes are very
limited, and it will be possible to use Tomcat 5.0 with the Jasper from
Tomcat 4.1. So I think "major" new features should go in the 5.0 codebase.
Rémy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSPC refactoring/documentation
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Glenn Nielsen" <gl...@mail.more.net>
To: <to...@jakarta.apache.org>
Sent: Sunday, November 10, 2002 9:44 PM
Subject: JSPC refactoring/documentation
> Based on problems reported by users of JSPC Remy made a proposal
> to deprecate it.
>
> This resulted in a number of people responding that they used JSPC
> and strongly felt it should be kept.
>
> There did seem to be some consensus that JSPC could beneifit from
> a review and refactoring to make it easier to use.
>
> It could also benefit from better documentation if it is to remain
> part of Tomcat.
>
> Perhaps those who so strongly support JSPC should take the lead to
> review, refactor, simplify, and better document JSPC. Perhaps a
> JSPC-HOWTO for the Tomcat docs once the refactoring is completed?
>
>
> This could be part of a Tomcat 4.2 development effort.
> There has been some discussion about other possible new features.
>
> Some new features/changes that have been discussed:
>
> A SecurityManager XML Policy file that allows secure delegation
> to web applications for setting their own policies (within a sandbox).
>
> Using JMX to instrument Tomcat for production runtime monitoring.
>
> Possibly a JSPC refactoring.
>
> Audit the SecurityManager web application sandbox.
>
> Are there other changes/features that could be part of Tomcat 4.2
development?
>
>From previous posts, I gather that Remy isn't interested in RMing a 4.2
release. Unless Remy jumps in and tells me that I don't know what I'm
talking about :), the biggest change would be to find someone to volunteer
to RM it.
Once I have my webapps working with 4.1 (the hold-up is basically porting
custom Realm stuff at the moment), I'm sure I'll have a wish-list ;).
> I have a laundry list of smaller issues I would like to address. Nothing
major.
>
> Regards,
>
> Glenn
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>