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 Mon, 14 Dec 2020 at 21:05, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,

On Monday, December 14, 2020, Stuart Douglas <sdouglas@xxxxxxxxxx> wrote:
I don't really like this idea of a 'magic method signature' that you need to exactly match. It's not really intuitive and it does not really match the way anything else in Jakarta EE (or Java in general) works.

Technically methods that respond to _expression_ Language bindings kinda work like that, as do several testing frameworks in plain Java.
 
 

IMHO if you are going to have an endpoint that services HTTP requests it should either be annotated or implement an interface method,

I’m certainly not against that myself, just thought people were more against adding additional types.

 
and I am kinda hesitant about adding additional annotation support to the Servlet spec as Jakarta already has an annotation based HTTP spec. 

So that leaves an interface as the only option for you?

Any suggestions for a name? HttpServlet would be perfect, but is taken.

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?

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.

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

Back to the top