Our application currently using 3 different servlet mapping syntax, wondering if there's a benefit to setting them all up one way aside from personal preference on the syntax of the routing.
1. <servlet> and <servlet-mapping> tags in web.xml pointing to Java class which extends HttpServlet, all requests go into service() method. This is built into JDK?
2. @WebServlet annotation on class, routes requests into doGet() or doPost() methods, requires javax.servlet-api dependency.
3. @RestController, @RequestMapping/@GetMapping/@PostMapping annotation, routes requests directly into individual methods, requires spring-framework dependency and apparently custom initializer class setup.

On 4/5/2022 11:31 AM, e.d.pro...@gmail.com wrote:
> Our application currently using 3 different servlet mapping syntax, wondering if there's a benefit to setting them all up one way aside from personal preference on the syntax of the routing.
> 1. <servlet> and <servlet-mapping> tags in web.xml pointing to Java class which extends HttpServlet, all requests go into service() method. This is built into JDK?
> 2. @WebServlet annotation on class, routes requests into doGet() or doPost() methods, requires javax.servlet-api dependency.
> 3. @RestController, @RequestMapping/@GetMapping/@PostMapping annotation, routes requests directly into individual methods, requires spring-framework dependency and apparently custom initializer class setup.

I believe that as usual consistency is more important than what is
chosen.

I would:
* use the Spring annotations for Spring web services as that is the
standard for those
* decide on either web.xml or @WebServlet for anything not Spring web
service

Arne

PS: All the servlet stuff is part of Java EE / Jakarta EE not part
of Java SE / JDK.

> I believe that as usual consistency is more important than what is
> chosen.
>
> I would:
> * use the Spring annotations for Spring web services as that is the
> standard for those
> * decide on either web.xml or @WebServlet for anything not Spring web
> service
>
> Arne

Consistency is the first issue, as I pulled together decades of old code into one clean maven project with many modules. Some modules create wars, some create jars. Two of the war modules have spring framework config files. I'm wondering if we'll see benefits in setting all modules up for Spring, as we're modifying literally all the code anyway doing linting and unit tests, or if it makes any sense to use all Spring controllers in 2 modules and clean the rest up with a different style. There's literally one class using the servlet-mapping servlet, I don't see any upside to that syntax, the rest that aren't Spring are using WebServlet. All I know is the different syntax, I'm not aware of functional or performance benefits of any style choice.

On 4/5/2022 9:41 PM, e.d.pro...@gmail.com wrote:
>> I believe that as usual consistency is more important than what is
>> chosen.
>>
>> I would:
>> * use the Spring annotations for Spring web services as that is the
>> standard for those
>> * decide on either web.xml or @WebServlet for anything not Spring web
>> service

> Consistency is the first issue, as I pulled together decades of old
> code into one clean maven project with many modules. Some modules
> create wars, some create jars. Two of the war modules have spring
> framework config files. I'm wondering if we'll see benefits in
> setting all modules up for Spring, as we're modifying literally all
> the code anyway doing linting and unit tests, or if it makes any
> sense to use all Spring controllers in 2 modules and clean the rest
> up with a different style. There's literally one class using the
> servlet-mapping servlet, I don't see any upside to that syntax, the
> rest that aren't Spring are using WebServlet. All I know is the
> different syntax, I'm not aware of functional or performance benefits
> of any style choice.

If you only have one servlet using web.xml then I would change that
to annotation. There should not be any runtime performance difference
after startup. I don't remember if the annotations support all the
functionality in web.xml, but if the annotation support the
functionality you need then you are good.

Regarding cleanup - are you planning to stay on servers
(Tomcat or JBoss or whatever) or are you planning on moving
entirely to SpringBoot or are you planning to do both?
That may influence the road forward a lot.

Arne

> If you only have one servlet using web.xml then I would change that
> to annotation. There should not be any runtime performance difference
> after startup. I don't remember if the annotations support all the
> functionality in web.xml, but if the annotation support the
> functionality you need then you are good.
>
Definitely, if the old web.xml doesn't add functionality we want to get rid of that one.
I don't know if it's worth adding the spring framework functionality for web servlets to modules that don't have it other than the syntax sugar of mapping one url directly to a method.

> Regarding cleanup - are you planning to stay on servers
> (Tomcat or JBoss or whatever) or are you planning on moving
> entirely to SpringBoot or are you planning to do both?
> That may influence the road forward a lot.
>
> Arne

Yeah I looked at spring boot, seems like that's for using spring as the web server. We are running on tomcat, planning to move to AWS which I believe also runs it on tomcat (in a docker container?).
We have a local test configuration of tomcat in eclipse, someone else handles setting up the servers.

"e.d.pro...@gmail.com" <e.d.programmer@gmail.com> writes:

>> Regarding cleanup - are you planning to stay on servers (Tomcat or
>> JBoss or whatever) or are you planning on moving entirely to
>> SpringBoot or are you planning to do both? That may influence the
>> road forward a lot.
>>
>> Arne
>
> Yeah I looked at spring boot, seems like that's for using spring as
> the web server. We are running on tomcat, planning to move to AWS
> which I believe also runs it on tomcat (in a docker container?). We
> have a local test configuration of tomcat in eclipse, someone else
> handles setting up the servers.

AWS has almost all the deployment options. You can deploy a war or a
jar. If you are planning to use AWS configured Tomcat (like
elasticbeanstalk option) then go for war build. Springboot bundles the
servlet container and outputs a jar. This can be run on any machine
where you have standard JRE installed.