Develop Reference

Spring boot declarative transaction management

I am working on an application written in Spring-Boot and JPA, the application has started from scratch. So I am thinking of introducing transaction management in it. There is entity and service layer in the application. Right now what I am thinking is that to go with Spring declarative transaction management. So, I have decided to put the #Transaction annotation on the top of the service layer itself as shown below, please advise is there any best approach to do the same also please make a note that I am using spring-boot-starter-data-jpa dependency itself
#Transactional
public class UserService {
}

Question is a bit too general, but your way of thinking is one of the standard and acceptable ways to work with declarative transaction management. I usually though do it per service method. This way you can specify if transaction is read only and some other parameters per particular service method which I think is more flexible.

It's not quite clear what your question is; do you just want someone to tell you that your approach is valid?
When you design a Spring application with a layered architecture, it is common to have the transaction boundaries on the service layer. The service layer then uses Spring Data repositories (which are in the data access layer). Your approach, where you use #Transaction annotations on the service layer, is a common way of doing this. So you are on the right track.

How to inject EntityManager in Java SE using #PersistenceContext (EclipseLink)

I have a client-server application that I made for a project at my university and I'm having problems with the database-JPA Cache synchronization. I'm using an application-managed EntityManager about which I found out from other posts that it's really hard to use because you always have to be careful to open and to close it.
The best solution which I found to this problem is to use a container-managed EntityManager, initialized using the #PersitenceContext annotation and this way I wouldn't have to worry about the EM opening and closing anymore.
So my real question is, how the injection of an EntityManager in Java SE using EclipseLink JPA is done, because I never passed the NullPointerException. I will attach some printscreens of an example of this operation and the way I think it should be done.
For my project I'm using jdk 1.8, basic jpa configuration(2.1) and EclipseLink 2.5.x as platform. On the DB side I'm using MySql-Server and no application server( this one has to be developed by me).
The persistence.xml file
The 2 classes which contain the example:
https://gyazo.com/a7b1a372875a259096dc220653cd5bcd

You cannot use the container managed persistence according to the used technologies listed by you because you do not have a container which could handle the injection. My understanding is that you are not in a JEE application server therefore you do not have an EJB container.
If you want to use JPA in a standalone application you can do 2 things:
Forget the injection and use the application managed persistence.
Use a spring container and you can still inject: How to inject JPA EntityManager using spring

Is JSF doesnt use Dependency Injection? [duplicate]

I'm a little confused by the mixed use of JSF2+Spring+EJB3 or any combination of those. I know one of the Spring principal characteristics is dependency injection, but with JSF managed beans I can use #ManagedBean and #ManagedProperty anotations and I get dependency injection functionality. With EJB3 I'm even more confused about when to use it along with JSF or if there is even a reason to use it.
So, in what kind of situation would it be a good idea to use Spring+JSF2 or EJB3+JSF2?
Until now I have created just some small web applications using only JSF2 and never needed to use Spring or EJB3. However, I'm seeing in a lot of places that people are working with all this stuff together.

First of all, Spring and EJB(+JTA) are competing technologies and usually not to be used together in the same application. Choose the one or the other. Spring or EJB(+JTA). I won't tell you which to choose, I will only tell you a bit of history and the facts so that you can easier make the decision.
Main problem they're trying to solve is providing a business service layer API with automatic transaction management. Imagine that you need to fire multiple SQL queries to perform a single business task (e.g. placing an order), and one of them failed, then you would of course like that everything is rolled back, so that the DB is kept in the same state as it was before, as if completely nothing happened. If you didn't make use of transactions, then the DB would be left in an invalid state because the first bunch of the queries actually succeeded.
If you're familiar with basic JDBC, then you should know that this can be achieved by turning off autocommit on the connection, then firing those queries in sequence, then performing commit() in the very same try in whose catch (SQLException) a rollback() is performed. This is however quite tedious to implement everytime.
With Spring and EJB(+JTA), a single (stateless) business service method call counts by default transparently as a single full transaction. This way you don't need to worry about transaction management at all. You do not need to manually create EntityManagerFactory, nor explicitly call em.getTransaction().begin() and such as you would do when you're tight-coupling business service logic into a JSF backing bean class and/or are using RESOURCE_LOCAL instead of JTA in JPA. You could for example have just the following EJB class utilizing JPA:
#Stateless
public class OrderService {
#PersistenceContext
private EntityManager em;
#EJB
private ProductService productService;
public void placeOrder(Order newOrder) {
for (Product orderedproduct : newOrder.getProducts()) {
productService.updateQuantity(orderedproduct);
}
em.persist(newOrder);
}
}
If you have a #EJB private OrderService orderService; in your JSF backing bean and invoke the orderService.placeOrder(newOrder); in the action method, then a single full transaction will be performed. If for example one of the updateQuantity() calls or the persist() call failed with an exception, then it will rollback any so far executed updateQuantity() calls, and leave the DB in a clean and crisp state. Of course, you could catch that exception in your JSF backing bean and display a faces message or so.
Noted should be that "Spring" is a quite large framework which not only competes EJB, but also CDI and JPA. Previously, during the dark J2EE ages, when EJB 2.x was extremely terrible to implement (the above EJB 3.x OrderService example would in EJB 2.x require at least 5 times more code and some XML code). Spring offered a much better alternative which required less Java code (but still many XML code). J2EE/EJB2 learned the lessons from Spring and came with Java EE 5 which offers new EJB3 API which is even more slick than Spring and required no XML at all.
Spring also offers IoC/DI (inversion of control; dependency injection) out the box. This was during the J2EE era configured by XML which can go quite overboard. Nowadays Spring also uses annotations, but still some XML is required. Since Java EE 6, after having learned the lessons from Spring, CDI is offered out the box to provide the same DI functionality, but then without any need for XML. With Spring DI #Component/#Autowired and CDI #Named/#Inject you can achieve the same as JSF does with #ManagedBean/#ManagedProperty, but Spring DI and CDI offers many more advantages around it: you can for example write interceptors to pre-process or post-process managed bean creation/destroy or a managed bean method call, you can create custom scopes, producers and consumers, you can inject an instance of narrower scope in an instance of broader scope, etc.
Spring also offers MVC which essentially competes JSF. It makes no sense to mix JSF with Spring MVC. Further Spring also offers Data which is essentially an extra abstraction layer over JPA, further minimizing DAO boilerplate (but which essentially doesn't represent the business service layer as whole).
See also:
What exactly is Java EE?
JSF Controller, Service and DAO
#Stateless beans versus #Stateful beans

There's no real easy answer here as Spring is many things.
On a really high level, Spring competes with Java EE, meaning you would use either one of them as a full stack framework.
On a finer grained level, the Spring IoC container and Spring Beans compete with the combination of CDI & EJB in Java EE.
As for the web layer, Spring MVC competes with JSF. Some Spring xyzTemplate competes with the JPA interfaces (both can use eg Hibernate as the implementation of those).
It's possible to mix and match; eg use CDI & EJB beans with Spring MVC, OR use Spring Beans with JSF.
You will normally not use 2 directly competing techs together. Spring beans + CDI + EJB in the same app, or Spring MVC + JSF is silly.

Using Hibernate ORM without Spring

I'm writing a JavaFX Application which previously use Spring/QueryDSL for DI and persistence.
I'm hoping to move to using either Dagger or Guice (instead of spring) and Hibernate ORM.
I have noticed that Spring offers some nice functionality on top of hibernate, such as transaction management via #Transactional.
Are there other means of avoiding "boilerplate code" such as opening sessions, beginning transactions, committing transactions and closing sessions via some sort of hibernate configuration? Or are these features I'm really only going to get if I use Spring?

Guice has #Transactional support for JPA providers such as Hibernate using guice-persist, Dagger does not mention support for this.
If you are using Hibernate as your JPA provider, using Spring with #Transactional would probably be the most natural fit for building your backend. You would find a loss less documentation, examples, blog posts, books and online help in general using other alternatives than with Spring/Hibernate.

How does a java web project architecture look like without EJB3?

A friend and I are building a fairly complex website based on java. (PHP would have been more obvious but we chose for java because the educational aspect of this project is important to us)
We have already decided to use JSF (with richfaces) for the front end and JPA for the backend and so far we have decided not to use EJB3 for the business layer.
The reason we've decided not to use EJB3 is because - and please correct me if I am wrong - if we use EJB3 we can only run it on a full blown java application server like jboss and if we don't use EJB3 we can still run it on a lightweight server like tomcat. We want to keep speed and cost of our future web server in mind.
So far I've worked on two Java EE projects and both used the full stack with
web
business logic
factories/persistence service
entities
with every layer a seperate module.
Now here is my question, if you dont use EJB3 in the business logic layer. What does the layer look like? Please tell what is common practice when developing java web projects without ejb3? Do you think business logic layer can be thrown out altogether and have business logic in the backing beans? If you keep the layer, do you have all business methods static? Or do you initialize each business class as needed in the backing beans in every session as needed?

EJB3 is split into two layers:
persistance (JPA, old Entity beans)
business logic (old Session beans)
You can have the same architecture, without using explicitely EJB3.
Persistance
JPA is very close to Hibernate. We use, and prefer it to JPA.
The annotations come from JPA, but there is no need for a container, it's not really EJB.
Business
Spring also is very close to the Business layer of EJB3. With many more capabilities...
Some even say they are better than EJB3 !! ;-) They say that EJB3 was created from these two solutions (but still have to reach at their level on many points!).

EJB enhanced a lot over the last 5 years. Especially with version 3 they became a lot more lightweight.
Java EE 6 has a web-profile that makes it possible to even run on a tomcat server a Java EE stack. http://www.oracle.com/technetwork/java/javaee/resources-jsp-139799.html
Further it is possible to install all the necessary components on tomcat:
http://tomee.apache.org/apache-tomee.html
I have an example project including EJBs on github that shows how to use them:
https://github.com/ManuelB/facebook-recommender-demo
Further I would recommend the screencasts of Adam Bien:
http://www.adam-bien.com/roller/abien/
If redeployment times are the reason why you aren't using EJB you should look into:
http://zeroturnaround.com/software/jrebel/
To still answer your question you should look into the following Java Web Frameworks as EJB alternatives:
Apache Wicket https://wicket.apache.org/
Apache Tapestry http://tapestry.apache.org/
The play framework http://www.playframework.com/
Spring http://projects.spring.io/spring-framework/

People that don't use EJB usually use Spring or another dependency injection framework. JSF allows you to create beans and wire them together, however it would be better to use this only for the UI and use Spring for your business layer. A lot of information is available for integrating JSF with Spring.