Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [servlet-dev] Big ticket items for Servlet 6 / Jakarta EE 10?


On Wed, 16 Dec 2020 at 03:33, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:

With regard to CDI scopes and servlets,  I think it would be a really REALLY bad idea to try and support scopes for servlets and filters.
A request scoped servlet would essentially be much the same as a javax.servlet.SingleThreadModel servlet - which was a bad idea then and is still a bad idea now.  It added needless complexity to the container whose cost was/is paid by all users regardless when most do not use SingleThreadModel.
I fear that trying to get similar support for CDI built into the core container will have similar no-taxation-without-representation issues.


It should not add any complexity, other than delegating to CDI to create the Servlet. If the Underlying object is RequestScoped then the Servlet container does not have to do any additional work, it just forwards requests to the proxy it has been handed and the CDI container takes care of the details

That said, there is no way we will be recommending different scopes for Servlets, the real value here in addition to injection is that you get interceptor support, so you can just add @Transactional to your servlet and it will work as you expect. Scope support is basically a by-product of this, and not something that is particularly interesting IMHO.
 
I understand that scoped CDI may well be a good way to assemble an application, but I just don't think it is a good way to always assemble a protocol handler.   Why is this level of integration needed to be supported in the servlet container itself.   If a web framework based on CDI wants request scoped servlets, then it is free to write a CdiServlet mapped to "/" that will use CDI to manage it's own Servlet instances that it can delegate requests to.


The servlet container has a need to create and decorate instances of Servlets, Filters and Listeners in order to perform it's core functionality.   I'm totally OK with making it possible for the container to out-source the creation and decoration of those components to frameworks like CDI, but only to meet the needs of the Container for the specified lifecycle of those components.    This is entirely different to turning the servlet container into a CDI based web framework that can dynamically create servlet instances for requests - such features may well be compelling, but they can be implemented as a Framework and not as part of the container.   

Integrating web frameworks into servlets has been and will be a mistake.  Instead we should integrate capabilities required by frameworks in general.  A Servlet and Filters are already plugable behaviours that can be used by a CDI based framework to achieve scoped request handling without the need for the container itself to be away of request scopes.


The Servlet container does not need to do anything, just call the service method on the Servlet the CDI container has provided. Basically as long as you have a way to delegate creation of the Servlet to CDI then this is all that is needed from the containers point of view, support for scopes and interceptors is wired into the object that the CDI container creates, and is totally opaque to the Servlet container.

Stuart
 
 
regards















On Tue, 15 Dec 2020 at 02:18, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,

On Tue, Dec 15, 2020 at 1:55 AM Stuart Douglas <sdouglas@xxxxxxxxxx> wrote:
So the real issue here is that if you don't have self interception (i.e. if interceptors are implemented via proxies rather than subclassing) the doGet() method would not be intercepted? 

Yes, that's the main issue indeed.

It would be nice-to-have to only have to implement an interface and not inherit from an abstract class, but that's not the key problem really.

 
If that is the case then we could just add something to the spec that says that if the HttpServlet is a CDI bean and does not override the service() method then interception must be supported for these methods, and leave it
as an implementation detail as to how it is actually implemented. The easiest way would just be to install some kind of proxy Servlet, where each doX method delegates directly to the actual method on the underlying Servlet bean.

Indeed, that would get us there. A simple (reflective) check using getDeclaringClass() would easily give you back whether the service() method was overriden or not.

Thanks for this idea!

Kind regards,
Arjan


 

Stuart


Kind regards,
Arjan


 

Stuart

On Mon, 14 Dec 2020 at 11:30, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,

On Wed, Sep 2, 2020 at 3:21 AM Stuart Douglas <sdouglas@xxxxxxxxxx> wrote:

Wouldn't it make more sense to just allow traditional Servlet's to be CDI beans? We do this in Quarkus, which means that scopes, interceptors etc work as you would expect. In Quarkus you can just add @Transactional to a Servlet and it will just work.

Having thought about this on and off for the last 3 months, what about a single extra addition to allowing traditional Servlets to be CDI beans, and that's to make the methods in the base Servlet interface default methods?

That would allow us to have a Servlet just implementing that base interface, avoiding the service() method that calls the doGet etc methods directly, which could circumvent the interceptors.

That would give us:

@WebServlet("/foo/bar")
public class MyServlet implements Servlet {
        
    public void doGet(HttpServletRequest req, HttpServletResponse res) {
        // ...
    }
} 

That would require no new API. Only a convention that the container calls the Java method with name ["do" + http method].

Thoughts?

Kind regards,
Arjan Tijms


 
_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev
_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev
_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev
_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev


--
_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev

Back to the top