I have some questions about Spring Boot and Hibernate.
I discussed with one developer and he said me he compile his Rest Api, developed with Spring Boot, in Jar and used the tomcat server provided by Spring Boot and deploy the jar on the server. But in my case, i use the war packaging and i deploy on my tomcat server but he said it’s less performing.
I don’t know why and i asking me if you developed in microservices your Resp Api with Spring boot and you use his solution, do you create multiple tomcat instance ?
About hibernate, i used HQL for some queries and he said me it’s bad way because it’s dangerous with Sql injection, it’s true ?
I need some answers of people who can advice me.
Sorry if my english, it’s not great and thank you very much, in advance, for your answer.
In the Java Cloud space there are 2 major directions:
Java EE:
Create a Docker base image which includes a Java EE application/ web server such (e.g. Tomcat, WildFly, GlassFish,...)
Create a (thin) WAR file
Create a Docker image based on your base image which deploys the WAR file to the application server
Spring Boot:
Create a single JAR file using the Spring Boot Maven Plugin
Create a Docker image which executes the JAR file
I guess you could also mix the two approaches (create a Spring Boot WAR file), but the single JAR file approach is much more common with Spring Boot (I'm currently using this approach).
Some Java EE experts such as Adam Bien promote the first approach (less dependencies, smaller WAR files, smaller Docker images, more standard APIs (though what "standard" means is currently changing with the transition from Java EE to Jakarta EE)).
I can't tell you which one has a higher performance. Either way there will be one server started per Docker image.
Regarding Hibernate and SQL injection:
I'm not using HQL but JPQL, but in the end it's more or less the same as with JDBC: Don't string concatenate queries with input from the user. Always use some kind of prepared statements with variables to format the user input.
If you are using spring boot you implement more or less a standalone application (even if it´s a webapplication), therefore yes there will be an own embedded tomcat, jetty, whatever instance for each spring boot application.
SQL injection has nothing to do with the way how you deploy an application, it´s only a question how you create your HQL queries.
However, that´s an interesting discussion. In our company we are quite old fashioned and create an WAR file of our webapplication, and deploy it on our Glassfish server where serveral other web applications are running under the same instance.
Florian
Related
I'm working in an old web application which is using Struts-1 with Hibernate. There we're using full-fledged functionality of struts1 with ActionServlet as the front controller, struts-config.xml as configuration file etc. We are using tomcat-9 for deploying and running the war file. Now there's a requirement to use Rest-API in the application for which I need to introduce Spring Boot in the application for the first time.
I'm little confused, is it really possible to correlate Springboot with Struts1 ??
If yes, then How can I achieve that? Can anyone help me what will be the possible configuration changes, which new files I need create and How they both can work in the application??
Springboot has embedded tomcat right? then, how these two different technologies will work together? I need an overall idea for this. Please help.
We're running a Spring Batch Web-Application for Importing CSV Files into a Database. This Web-Application is currently evolving and is constantly extended by new jobs.
the current update procedure looks like this:
1. Write new Code
2. Build a war file
3. Deploy the newly build war file and replace the whole Web Application on the Tomcat Webserver
This might bring us into trouble, when the running system is currently importing / writing Files to the Database.
I wanted to know if there is a smart way to maybe upgrade the spring batch jobs seperately ?
I already thought about splitting the Project into many different Web-Applications but this might be a lot of overhead with all the libraries bundled into the war file(s).
Are there any best practices for building that sort of Application ?
Thanks for your Help !
This packaging model is known to cause a lot of issues like the one you are facing. I recommend to package your jobs as separate jars and make your application launch those jobs in separate processes. With this model, you can deploy/upgrade jobs without impacting the web application used to launch them.
For the record, Spring Batch Admin suffered from this packaging model (as described here) and the recommended replacement is Spring Cloud Data Flow (which uses the model I described previously)
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 4 years ago.
Improve this question
Spring boot is not adopted in our organisation.
The disadvantages cited are bloated jars, less control and flexibility.
I have tried to investigate above points but so far they dont seem valid.
bloated jars - The spring blog states that a simple web server
can be launched with 10 MB of heap.
less control and flexibility - Netflix uses spring
boot.Moreover,when I did some poc's, I didnt face flexibility issues.
I wanted to know if there are any mistakes in assesment.
1)Any examples on the loss of control/flexibility will be helpfull.
2)What are the anti patterns we need to be aware so the bloated jars issue dosent happen.
It is often a question of concern and responsability. With Spring boot, the developper team has full control of the deployed environment, including the servlet container configuration. And the production team has nothing to tweak.
Without Spring boot, the developper team has only control over the web application. And the production can/has to tweak the servlet container configuration. When you have a large number of different web apps, it can make sense to let the knowledge on that part only in the production team. In that case, you would not use Spring boot.
On the other end, if the hosting is externalized, Spring boot allows to give a full package.
So both approaches can be used but they target different organizations.
Bloated Jars - I think this can be fixed by properly maintaining the jars using a build tool like maven (But, yes there are some instances where you may need to add a lot of jars just because spring needs it)
Less control and flexiblity - I think this is usually with control freaks who want to control each and every piece of code they write. If you are okay with what spring provides already, this shouldn't be an issue.
I believe that the biggest disadvantage that you might encounter using spring is using it without understanding what value it might add to your project.
It might be completely not aligned with your requirements and it is possible that you will configure everything by yourself at some point, when you think, you should not have started with spring itself.
Ask your self a few questions,
You can create standalone java application? Why Spring at the first place? What value it adds to your project?
Spring has embedded tomcat, jetty, so no need to build a war. But, what if you have to build war anyway? Little config will do the trick but it's not any major advantage. Also, when you start it as a java service, what happens to your service if somehow the java process got killed?
What if you have many legacy spring modules? What if you need to patch it up? This will increase the jar count as well as legacy classes count. Are you sure want to convert this into a spring-boot application?
What if spring autoconfig configuration is not aligning with your requirements
And, I myself used spring-boot for a few of our production applications, which are mostly standalone REST API services and, haven't faced any issues with it.
Some best practices will be,
Use spring-boot mostly for microservices instead of a single complete (MVC) web application (I always use it to build the standalone REST API and build the UI with ReactJS and NodeJS).
Build your spring-boot app as a docker image and deploy using some kubernates cluster (kubernates will take care of failed docker containers and deploying to new containers) for maximum uptime.
Always keep only the jars required by your project and remove unwanted jars.
Any examples on the loss of control/flexibility will be helpfull.
You need familiarity on the life cycle of a bean in a Spring Boot application. Not knowing this might hinder your experience in spring boot. This will force you to structure your beans to prevent circular dependencies and other problems.
In Spring Security, configuring your other login methods is not really that intuitive.
In Spring Data JPA, repo classes requires you to name the methods in a specific way to perform queries. Locking/releasing data rows is also not straightforward.
etc...
What are the anti patterns we need to be aware so the bloated jars issue dosent happen.
Review the dependency tree of your jars. Make sure to add dependencies only in the modules they are needed. Also, remove dependencies you don't need.
I'm just new with drools and web development, I'm just wondering if how can i integrate Drools in a Web Application, I'm using JSP and Servlet technology if I'm not mistaken with the term. I'm also planning of using MVC pattern not SpringMVC.
What I already done is:
Downloaded Drools and jBPM as plug-in in eclipse ( Able to create a Drools Project as a proof)
Already create a Dynamic Web Project, running and using Tomcat as a server
My question is where should i put Drool library for me to use the rules depends on the user's input in a JSP? Or if i missing something kindly tell me.
In general, libraries (jar files) should be put in the WEB-INF/lib folder of your web application, which can then be packaged as a whole in a .war file. Tomcat (or whichever servlet container you decide to use) will then load them in the classpath as part of its webapp initialisation. Drools might require specific configuration to tell it where it will find the rule files to load them, check the Drools documentation for that.
I can assure you it works from within a web app and also within an application using the Spring framework. I've seen it work with web services using JAX-WS (Apache CXF) with Spring on Tomcat exposing web services which use Drools to determine what business logic to apply.
What if you don't want to start a separate project for grails but instead sneak it into an existing webapp?
I have to build an admin interface/crud for some new entities and thought it would be a perfect way to learn grails.
I'm trying to make one application with a Grails app and a Spring app.
I've tried to sneak the Grails App into the Spring one, but this is "impossible". It's easier to sneak the Spring app into the Grails app. Grails knows what Spring is, but Spring has no idea of what Grails is.
In this article you can find useful information about how to use your hibernate mapping files or annotations in Grails, so you don't have to remap everything. Also you can use all your java clases (put them into src/java). You can put the beans defined in the ApplicationContext.xml in conf/spring/resources.xml. You can leave them in ApplicationContext, but I've had some problems.
I don't have ended the job (almost) and it looks good.
It would be hard to "sneak it in" unless the existing app has the correct dir structure that maps exactly to how grails likes it - after all, convention over config is where the power of grails comes from.
You can try doing the admin interface as a "seperate" app to the original/existing spring app, and map the existing database to the grails domain objects. though i m not sure how you would run them side by side easily without more information on the existing app. It is possible definitely though.
I agree that building your admin interface is a good exercise to learn Grails, and also agree with the previous answer that Grails is difficult if not impossible to integrate with an existing Spring application. You could probably get it done, but the headache would not be worth it.
Grails is built on top of Hibernate for its ORM, so if you're already using Hibernate with this Spring app you can work this to your advantage. It's not too difficult to configure a Grails app to use pre-existing Hibernate models, and this is explained well in Grails documentation.
So, I'd recommend building up your admin console as an independent Grails app but make use of the Hibernate models you already have, if in fact you've used Hibernate.