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
Related
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 3 years ago.
Improve this question
Can someone share the experience of converting existing spring application to Quarkus
Existing spring application has dependencies with 1) Swagger 2) Oracle Jdbc Driver 3)Logging framework 4) Spring auto wiring
It depends if you want to generate native executable or not.
In JVM mode:
we have a Swagger extension based on OpenAPI that gets you the Swagger UI in dev mode (https://quarkus.io/guides/openapi-swaggerui-guide). If you want to use Swagger itself, well, you should be able to include it without any issue.
the Oracle JDBC driver should work out of the box
logging wouldn't be an issue. We come with JBoss Logging which has several adapters for other frameworks.
we have a Spring compatibility extension for autowiring that translates the Spring annotations to CDI: https://quarkus.io/guides/spring-di-guide
And then, there's the GraalVM native executable mode. And then comes the bad news: I don't think the Oracle JDBC driver will work for now. We don't have an extension for it and I'm pretty sure it won't work out of the box for now.
But Quarkus has benefits even in JVM mode, so it would be worth it anyway.
If you start this journey, we're interested in feedback, either on the mailing list or in GitHub issues.
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 4 years ago.
Improve this question
I don't get the benefit of using Spring instead of just using regular Java EE, and I think the reason is I don't have a good grasp of some of benefits of the design principles that Spring employs (dependency injection, etc.).
For example I don't understand what benefits we get by adding #Bean, #Component #Autowired and #Repository annotations.
My question is not what do those annotations do, the question is more what are the principles that Spring makes the implementation of easier or more effective?
Dependency injection is a fantastic pattern. It often allows you to easily unit test components that would otherwise require complicated mocking or stubbing.
It's worth stating that it's possible to use dependency injection without handing the object lifecycle and "wiring" over to a container. I always use dependency injection. However I would only consider using a dependency injection framework for a large project. For instance, last year I wrote a ~2k line webserver in Java and chose not to use "managed" dependency injection. My team agreed that this arrangement provided all the architectural benefits of dependency injection without the drawbacks of a DI framework (bloat, boilerplate, reflection, etc). However if it was 200k lines I may have made a different choice.
Since you're asking about the benefits of Spring and not DI/IoC in general, I have to say that I think Spring is poorly designed. The history of Spring goes hand in hand with the history of antipatterns and bad abstractions that have plagued the Enterprise Java community. To be fair, engineers that I respect have told me that Spring Boot is better. Certainly try it out, you will gain perspective on what does or doesn't work. But maybe also consider other options that adhere to the UNIX philosophy by focusing just on dependency injection.
Spring makes it easy to create Java enterprise applications. It
provides everything you need to embrace the Java language in an
enterprise environment, with support for Groovy and Kotlin as
alternative languages on the JVM, and with the flexibility to create
many kinds of architectures depending on an application’s needs. As of
Spring Framework 5.0, Spring requires JDK 8+ (Java SE 8+) and provides
out-of-the-box support for JDK 9 already.
Read the manual:
https://docs.spring.io/spring/docs/5.1.4.BUILD-SNAPSHOT/spring-framework-reference/
There are tons of useful information.
My question is not what do those annotations do, the question is more
what are the principles that Spring makes the implementation of easier
or more effective?
IoC container, many projects and integrations, Spring Boot with the embedded servlet container. Many built-in features.
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 8 years ago.
Improve this question
I am going to develop a new web application of medium complexity. Right now I am somewhat comfortable with JSF and hibernate, but I have never used JSF and hibernate together before.
I just wanted to ask if it is good practice to use JSF (for both the view layer and handling business logic) and hibernate (for persistence) without Spring as a middle layer.
The reason why I am asking this is I don't know anything about the Spring framework and my customer wants development of the application to start as early as possible.
There are many ways to use Hibernate. Using JSF together with CDI beans, EJB and accessing the database via JPA (in other words doing things the Java EE 7 way) just works. I've worked with both EclipseLink + JSF & Hibernate + JSF and they're basically the same.
Hibernate can sometimes cause troubles with Lazy Initiliazation, where EclipseLink works just fine. This actually happened to me. But this issue has been already fixed from certain version, you only need to add a single property in persistence.xml.
I used EclipseLink on Glassfish and right now I am shortly using Hibernate with WildFly.
I don't think its a good idea to use only JSF and Hibernate. Spring at least gives some help towards persistence and other things you might need.
There are a lot of boilerplate have to write. This has become better with the later versions of JSF though.
But if you don't want to use Spring, take a look at Delta Spike which will provide some glue and more which makes integration a lot easier.
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 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.