[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [servlet-dev] servlet.next 5.1. or 6.0
|
On 24/07/2021 03:18, Greg Wilkins wrote:
Mark et al,
If we have some months, then I'd very much like to deprecate/remove a
few more things along the lines of my Less is More
<https://webtide.com/less-is-more-servlet-api/> blog. Specifically:
* I would like to make cross context dispatch clearly an optional
feature, so a container could still be compliant even if it never
EVER returned non-null from `ServletContext.getContext(String)`
I generally agree that this adds a lot of complexity and that quite a
few features have been added to the API over the years without fully
defining the expected behaviour with a cross-context dispatch.
I'd be happy to see `ServletContext.getContext(String)` deprecated and
then dropped from the API (as you suggest in your blog) but I see two
potential issues with this.
1. The Jakarta Platform specification. I suspect such a change would be
problematic in the context of an EAR. Making it an optional feature
addresses this concern. We'd need to work out the details and the TCK
might need some tweaks but all of that should be doable.
2. If the behaviour is optional then we still need to define the
behaviour for all the cases that are currently problematic /
ill-defined. If the behaviour still needs to be defined, we don't gain
much by making it optional. There would still be benefits to container
implementations that don't want to support cross-context. Clearly Jetty
is one. Are there others? I'd say Tomcat is neutral on this. I don't
recall any discussions in the Tomcat community around this topic.
* Can we drop "Object Wrapper Identity"? That would be a breaking
change, but we'd be able to fix more broken async applications in
the process.
I don't know. The big question is to what extent do users wrap objects
in order to add functionality rather than to override existing
behaviour. To put it another way, how much stuff will this break?
If we go this route, do you anticipate a new API that would let users
add functionality that would be unaffected by any subsequent wrapping?
As to my original question, my current sense is that we are thinking 6.0
rather than 5.1.
Mark
