Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
"A lot of incompatibilities" is an exaggeration. If we just let or
Request, Response, Session and Cookie extend the corresponding http
servlet ones, we would just get a few minor incompatibilities that IMO
would be rather minor in comparison with the benefits of using a
standardized API.
:) exaggeration is better than downplaying (not implying that you're
doing this here). With "a lot of" I meant for the users. I know a lot of
code where a request.getSession() is called and stored in a variable of
type o.a.c.e.Session. If we change the signature of this, well all these
places have to be changed.
But as you outlined, it is not that hard to do the changes.
It is of course a trade of, but I think we gaining much more than we lose.
Doesn't
eclipse have this out-refactoring feature (or whatever it is called)?
Where you add a refactoring description to a new jar and through this
description the client code is automatically refactored?
No idea, sounds great though.
So to summarize, it would be a great benefit to let our environment
abstractions extend the http servlet ones and the cost would be low. So
it is time to do it.
I still think we should release before those changes.
I think we should consider the time plan for these changes and for the
release orthogonal.
Grek has to respect GSoC project deadlines, so we cannot just ask him to
wait. OTH, he or others cannot do major changes close to releases. If we
have a clear release plan with fixed release dates, this shouldn't be to
much of a problem. We'll have a code freeze a week before a release. If
Grek doesn't think that his ongoing piece of work will be finished
before the code freeze, he has to work in a branch. Also work during the
freeze will need to be in a branch. Then he can merge again after the
release.
This will of course be a little bit inconvenient. But much better than
waiting until after the release.
/Daniel
