Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I want to automate the generation of the API documentation in a spring-boot project, for which I see two options:
springdoc-openapi: works by examining an application at runtime to infer API semantics based on spring configurations, class structure and various annotations
OpenAPI Generator: generates code from an OpenAPI specification - at least the models and interfaces that will be implemented by the REST controllers
What I don't like about springdoc-openapi is that it pollutes the code with a bunch of annotations to describe the API.
On the other hand, I don't feel quite comfortable with OpenAPI Generator generating the models as a special requirement could come up where I'd have to customize the models in such a way that I wouldn't have control to do it.
I know there is not such thing as a best approach, but I'd like to know what other people think works best for them.
This is borderline opinion-based, but this is my take on this. I always use springdoc and rely on the generated documentation based on the annotations. The main reason is that it is easier to maintain the documentation if it is side by side with the code itself. If you change the code then it is easier not to forget to change the documentation. If you are worried about polluting the code, you could use an interface where you would add all the needed annotations, but then you would increase the possibility of forgetting to update the documentation.
The other approach I don't really like is because I prefer to have the code "generating" the documentation and not the other way around. To me, code is king and as such, it should lead the way.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
When do we use spring boot templates?
I understand that they're used with templating engines such as thymeleaf but I'm confused as to when to use them.
For example;
Is this merely for testing purposes and once published we're done and ignore the templates and the web designer / developer has to implement the service or is this something that's part of our application and can't be removed?
Because, to me, it wouldn't make sense for us to pile all of our website html/css/etc inside the same package / project folder that we use to deal with server side stuff?
There is no such thing as Spring Boot templates. Spring Boot integrates with different templating engines where Thymeleaf is one of the (more popular) possible choices.
With Thymeleaf you render the HTML on the server side using a combination of Java code (in the Spring MVC #Controller classes) and the HTML based Thymeleaf templates. The rendered HTML is then returned to the browser where it is rendered into what the user sees.
As such, it makes perfectly sense to package it as part of the Spring Boot application, as it is what runs on the server.
No, it's certainly not just for testing purposes. If you use them, you will use them as part of the application in production too. It is part of your application.
Because, to me, it wouldn't make sense for us to pile all of our website html/css/etc inside the same package / project folder that we use to deal with server side stuff?
why would you use same folder for each? Usually you split them into different folders, even when using Thymeleaf or some other template engine.
If you are actually asking about using javascript frameworks to create your frontend and combining that to a spring app, maven-frontend-plugin is often used.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
All the tutorials on spring.io are now all spring-boot centric. I'm not interested in converting existing projects to boot, and am not particularly interested in using boot for new projects, the "Takes an opinionated view of building Spring applications..." project statement isn't particularly encouraging.
Given this, I'm wondering where all the tutorials are for using spring without boot. Sure, the docs are great but those old tutorials were great.
Hopefully, with Google help, it is easy to find the excellent tutorials from mkyong. The reference manual (ok, not a tutorial) contains also a good deal of examples.
But you are right, it is easy to find javadoc and reference manuals for older Spring versions, but I could not find any tutorial on spring.io without spring-boot.
Edit (per m4rtin's comment) :
For a true beginner that would want to avoid spring-boot (want to deploy to a real container for example), they can be used alone. They can be used also as a way to skip the spring-boot part along with a more up to date tutorial from spring.io. I mean : spring-boot is just a way to automagically build a skeletal application including application contextes, and it is used for that in recent tutorials. But you can always create the skeletal application without spring-boot (with the use of the older mkyong tutorials) and then add the other components to follow a newer tutorial. Of course, it is a more advanced use, but it is the way I did for recently try some parts of Spring (other than the basic framework) because I am used to my old own tomcat and do not really like boot.
Of course if you only want to try something that you will throw away as soon as completed, the right way is probably to fully follow the new tutorials and use boot.
One can never please everyone.
When adding plain Spring samples people will start asking question why DataSources don't work or their activemq setup doesn't work (people usually don't takes days to figure it out, if it doesn't work < 5m a guide/project/sample is crap even if the error is their own).
The same for XML and JavaConfig for years the argument was that Spring == XML Hell (just take a look at their samples was often overheard/-read) now that is Java based config (a road that even Java EE is taking) it isn't ok either.
The Spring Boot guides allow you to focus on the core content at hand, instead of all the necessities/complexities around them. Nonetheless I do agree that some basic plain Spring Framework guides should exist. You might wan to comment on this issue
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Closed 9 years ago.
Improve this question
What is a lightweight framework? Why it is saying that codeigniter is lightweight?
Here is a post i found on coderanch.com :
The term "lightweight" refers to the conceptual weight of a framework.
Lightweight frameworks like Spring have minimal impact to an
application. That is, it does not require as many code changes to
incorporate them into your application as does the more heavyweight
frameworks like EJB. When you create an EJB, you have to deal with
several interfaces and it is pretty clear by looking at the code that
an EJB is tightly coupled to the J2EE framework. On the other hand, a
POJO is usually blissfully unaware that it is being used in the Spring
Framework. Spring is minimally-invasive. There are also claims that it
should not be a very difficult task to take Spring out and replace it
with another similar framework.
With lightweight frameworks, you do not have to think too much about
the underlying framework because there really isn't much code to write
that explicitly ties you in with the "plumbing". On the other hand,
traditional J2EE development with EJB entails writing a lot of
"plumbing" code which weighs you down conceptually.
Hope it helps.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I've seen JSTL have many functions like
fn:contains()
fn:containsIgnoreCase()
fn:endsWith()
fn:escapeXml()
fn:indexOf()
fn:join()
fn:length()
fn:replace()
fn:split()
fn:startsWith()
fn:substring()
fn:substringAfter()
fn:substringBefore()
fn:toLowerCase()
fn:toUpperCase()
fn:trim()
While in Struts2 we don't have such functionality for UI. So integrating JSTL with Struts2 can utilize these functionalities.
But I don't know whether it is a good practice to do so.
There's no reason not to use JSTL in an S2 app, but there may not be any reason to use it, either.
The S2 response wrapper provides JSP EL access to the value stack, so accessing action properties isn't an issue. OGNL can be relatively slow, but it's also far more powerful than JSP EL. Whether or not much of that power belongs in the view layer, however, is debatable, and may influence your decision.
Use whatever taglib provides the functionality you need, recognizing there are tradeoffs whichever direction you go. The bulk of OGNL's security issues have been resolved, AFAIK.
Yes you can use JSTL with Struts, Spring and any other Java EE-compliant framework. You will find it advantageous to use with el(expression language). I highly recommend doing so if you use Java EE.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am pretty new to the concept of dependency injection and we are currently writing an web app using JSF and maybe Primefaces. We are currently evaluating whether to use Spring or EJB3. I was realy close to choose Spring, but then I heard about CDI. Can you give us some hints, which could be the best for the following situation:
We are currently pretty new to the J2EE world and don't know if we will use Glassfish or JBoss (or can simply stick to Tomcat).
The web app is basically a prototype for an enterprise CRUD application that needs to be able to handle complex business logic. We want to focus on "adaptability", as some requirements are not clear and will be decided about a year later (when we know if we can still use the prototype).
We can't use Hibernate, as we will have to write pretty complex SQL Statements. Currently we made good experiences with the SQL abstraction in Spring.
Maybee I am currently comparing apples and oranges, but there are just too many information's, if you are new to j2ee. I think that EJB's are the standard defined through JCP, Spring is the standard defined by the market and CDI is a standard that is also defined by the JCP to do what Spring can do. But I am most certainly wrong ;-).
Thx,
iuiz
Lincoln Baxter does an excellent job explaining the technical differences in this article: http://ocpsoft.com/java/spring-to-java-ee-a-migration-guide-cdi-jsf-jpa-jta-ejb/ Long story short: both Spring and CDI will both be able to provide dependency injection. One is a Java EE standard, the other a commonly known technology. Glassfish and JBoss both run Spring apps and CDI apps without problem. As far as not being able to use Hibernate, it's not the case that you cannot use native SQL within Hibernate. Save your team a lot of extra dead-simple CRUD code if you can.