Jakarta EE jax-rs jersey 3.0.1 myresource api
powered by Embedded Jetty 11.0.2 tested on jdk-16+36.Oracle recommend using the latest JVM, because only the latest JVM has all the security fixes.
Your Mission should you choose to accept, is to develop an application using Jakarta JSP and Jax-rs using this archetype which will generate the skeleton application for you. All you have to do is create a JSP home page and link the jaxrs jersey resource with the JSP page as I have done so. You must use the jakarta EE libs, must follow EE specification,not allowed to hack. You may update the jetty version in the pom.xml file from 11.0.0.beta* to jakarta production version 11.0.0 , 11.0.1, 11.0.2. Once you upload application on to this free heroku website your mission is complete. You will find the full instructions here see section 1.5 of the official Jakarta website. The advance challenge is to set up the same project as hot deployment development platform in Jetty version 11.0.2.The final phase of the advance challenge requires you to do a pull request.
mvn archetype:generate -DarchetypeArtifactId=jersey-heroku-webapp \ -DarchetypeGroupId=org.glassfish.jersey.archetypes -DinteractiveMode=false \ -DgroupId=com.example -DartifactId=simple-heroku-webapp -Dpackage=com.example \ -DarchetypeVersion=3.0.1
The final advance challenge is to place a either or static or dynamic resource in src/main/webapp directory but have the application server execute a dynamic Java class. Then figure out which versions of Jetty does it and which versions of Tomcat does it and which do not. Why is the comparison between Jetty and Tomcat having to be made, what does it tell you ? This challenge is considered beyond the intellect of a developer who is unable comprehend all the subtleties of design in an Industrial Strength Application.
For consistent performing application even under stress, For your application to be indeed an industrial Strength application,commercial grade, your considerations are connection pooling , loading balancing, perfect database design. The perfect database design is referring to the fact when the EJB entity bean or any other Data Access Object is mapping to a database table row(s). You may have to use javax.sql on occasions when the operation is a bit more complex than your bog standard CRUD. The perfect database design can easily be achieved when using the Microservices paradigm. Which components you choose for your application logic to negotiate these obstacles is just a choice. However you will only be in a position to choose if you know and fully understand the meaning of two words interprocess and intraprocess.
A Bean is an intraprocess (tightly coupled) and an Enterprise Java Bean is an interprocess (loosley coupled). This is really easy to understand when you look at the diagram. The bean can be seen as tightly coupled with the JSP running in the same container. Meanwhile the EJB runs in its own EJB server so it is loosely coupled. The reason this is very important knowledge for application developers is because both of these components are designed to hold business logic, the intended audience is non other than the application developer.
For the EJB to be loosley coupled it doesn't have to run in a remote JVM as can be seen in this diagram, this diagram was first published in 1999, yet you can still apply it to Jakarta EE. incidentally the Intranet is tightly coupled and secure. when the client and server are communicating,the Internet uses a loosley coupled communication algorithm hence it is stateless. With these concepts in mind then you can clearly see and appreciate, many new APIs is a result of Recycling of the intraprocess or interprocess of the old APIs. I have no doubt similar Concept Recycling can also be found not only in the interpretive Java Virtual machine but also the real machines.
I knew I would be one of a very few people who would understand the definition of bean and E-Bean because I had just been looking at the diagram earlier in another book. What was the chance of anybody else doing the same. This diagram was put together with a collaboration between 12-15 engineers. The reason I had two source of material on the same topic is because it is my belief that if I didn't understand an Information Technology topic, it is entirely due to the subject not being explained to me properly by the source.
I put my belief of having multiple sources on the same top to the test. My belief that I did not understand not because I couldn't, but because there was a failure explain/introduce the subject properly. My test involved asking Java EE "experts" if they would be kind enough to explain interprocess and intraprocess. In their opinion an intraprocess runs in the same JVM and an interprocess runs in a remote JVMs. The binding has nothing to do with. One told me to get lost because they do not have time to discuss rudimentary and basic concepts. I have two sources which concur with each other and on that basis I would have to say the Java EE "experts" are incorrect in their understanding of this particular subject.
In the field of application development, where there is great reliance on other people's platforms and APIs, there is no question in my mind, the language must be interpretive so that it is possible to track down an anomaly. In the event there is a concern of decompiling classes then one can put the algorithm in a C dll and interface with it in Java. Of course if there is an anomaly in the dll then tracing the bug is not possible by another application developer who doesn't have access to the source.
I think it is important to understand these concepts because then, you as an application developer will not get confused by new technologies or new buzz words or even claims of new inventions Vying for your attention, when it is really a recycling of the same old concepts. The US department's conclusion of the software crisis was due to 400+ programming languages, which was then solved by replacing the 400+ programming languages with one programming language, ADA. There was a time it appeared as if Java had more than 400+, APIs and features one had to learn before being able to build Applications.
The book which stated a Bean is an intraprocess(tight coupled) and an Enterprise Bean an interprocess (loosely coupled) also stated that networks is a very simple concept known only to a few. I think I am one of them few. I am one of the few because one of my HND computing course teachers was an Assembly language programmer who couldn't understand why there was so little demand for Assembly language, so he turned to teaching,he said it was a very easy language to programme. Easy for him but people preferred not to write any code meaning OOP using OOM because it needs a lot of focus and concentration.
Java Jini-Javaspaces was a competing paradigm of EJBs, a primary example of API recycling. I think there is room for further trimming of the JakartaEE turning it into a lean machine Application developer's dream machine. If JakartaEE doesn't do the trimming simply follow the Microservices Paradigm which does the trimming for you.
If you want a reason why you should you use professional products with professional support rather than purely open source just take up this challenge which asks you to add one JSP to the archetype.