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.
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
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.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am working on evaluating Spring Web Flow for handling conversational flows in the web application that is currently used. Currently, the web application that we are using using is a custom company made MVC framework that was developed 10+ years back when there was no Spring MVC or Struts etc. There is a ControllerServlet in the application which is currently doing the work of managing the requests, similar to DispatcherServlet of Spring MVC.
Now, we want to take advantage of the Spring Web Flow features and renew the application and ease the developers life. I would like to know from all you people out here who had similar experiences in the past of migrating legacy MVC application to Spring Web Flow.
Please suggest the configurations and / or changes which I should be looking at to take this into right direction.
Some of the questions which come naturally to my mind are:
Configuration changes to web.xml? or adding a spring related xml file?
Any changes that we need to make to the JSP's? I am assuming Spring Web Flow will require me to make changes in the JSP's. What do you guys feel?
How could we get rid of the ControllerServlet? or better yet ask the ControllerServlet to refer to Spring Web-Flow for all the requests?
If Spring Web Flow is replacing the ControllerServlet, what happens to all the code that is written in it? what equivalenet of Spring Web Flow do we need to write?
Thanks,
Yogendra
Why replace, you can perfectly use Spring Web Flow (and/or Spring MVC for that matter) alongside your own MVC framework. You only have to be careful when you are crossing boundaries between the 2.
What we did in such a scenario was introduce a DispatcherServlet for only handling the Spring Web Flow request and everything else was handled as before. So you basically have 2 servlets instead of 1.
Another solution would/could be to replace your own servlet with a DispatcherServlet and let all requests for the old part of the application delegate to your own ControllerServlet, for this you could use the ServletWrappingController of Spring MVC.
Benefit of the last approach is that you could create a HandlerInterceptor which could move some stuff around from your own MVC framework to SWF and vice-versa.
In each and every car you would need to change the pages that use Spring Web Flow to use the Spring tag libraries so that form can be properly handled, for pages that aren't used/served by Spring Web Flow everything can remain the same.
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 9 years ago.
Improve this question
Now I am reading "Begining Java EE 7". And I was wondered that Java EE 7 is a good stack of technologies, it includes CDI, bean validation, JSF for web tier and other specifications.
So I got a question:
Why should I study Spring framework if Java EE 7 exists and covers all capabilities which Spring implements?
I will share little bit of what I know about using Spring. You are right by saying that Java EE 7 has all the technologies to help solve the problems.
Well Spring just enhances these capabilities and makes life more easier for a developer.
As an example when you use Spring MVC framework you can use Spring UI tags to create your JSP and those tags in turn can help you map the values directly to your controller. By controller I mean the Java class which is invoked when you do form submit. It also helps you to validate the form data.
This can be achieved using the Servlet technology also but Spring lets you focus on business logic and it takes care of these.
In my experience as a developer its good to know and understand Java EE 7 but frameworks like Spring utilize some of the best practices and patterns to make life easier for developers.
Would like to hear the opinions from others as well.
Hope this helps.
I think that one simply should know both of them. Spring has a huge community and is used widely, but Java EE is now going forward too, using many technologies that are in Spring in its latest versions.
However, it is incorrect to say that Java EE covers all the fields that Spring does. In my opinion Spring still has something that could make the difference, if you work in particular domains, such as mobile (Spring mobile), social (Spring social), navigation flows management (Spring Webflow) and others.
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 9 years ago.
Improve this question
I have a legacy financial application which is written using EJB2.1(Making use of Entity Beans, Stateless Session Beans and Couple of MDBs).
I want to migrate the application to latest Java EE or Spring framework. The application consists of around 400 entities and Entity beans are mainly used for Creating and Updating.
For the viewing part a separate DAO layer is there and I don't want to touch that part.Also I want to keep the business logic written in service beans as it is very complex to re write.
i.e., I simply want to replace the ORM part of the system. The application is making use of JTA transactions.
Sorry to ask a very high level question, but which technology I can use to replace the ORM.
Spring/Hibernate
Java EE
The primary considerations for the application would be scalability, performance also ease of deployment.
I just want opinions on who have used these technologies, I don't want to start a war between 'evangelists'.
If you find the input is not suffcient please ask me I can provide more details.
the argument here is really between EJB-3.x versus Spring/Hibernate the first caveat being that one does not necessarily mutually exclude the other. (annotations, container, testing, etc.)
there's lots of support in migrating to EJB 2.1 to EJB 3.x and lots of toolsets to assist. one of the principal challenges that i've seen with EJB is integration testing outside the container. (for example. in a continuous integration environment) There are JTA solutions, JNDI solutions and others to support but on the whole, i've found that there is more 'out-of-container' testing support on the Spring migration path than Java EE. that said, there are foundation frameworks such as Arquillian from JBoss designed to support this.
so i would suggest you look at EJB 2.1 to EJB 3 migration paths and then look at the Arquillian framework for integration testing support
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.