Is it possible to use Hibernate with Annotations, without Spring framework for a command line application.
Right now i have spring with hibernate configured for command line application.I have main function which received data and it calls other (namely 'storeDB') object to get AbstractApplicationContext context and save the data.
Like to bring up the hibernate first ( bring up hibernate framework,
connecting to DB) and like to wait for a socket to process the data.
Can it be configured through java configuration than XML
configuration
and is it possible do in Hibernate(with annotation) without Spring?
Yes of course you can:
Use Hibernate annotations (without XML configuration) to setup your database connections and map
your entities to your database, for further information about it take a look at:
Hibernate with Annotation.
TutorialsPoint Hibernate - Annotations tutorial.
Use only Hibernate without Spring in a Java Application to manage your persistence strategies, because they are two independents frameworks:
You can see from the Hibernate Definition that:
Hibernate ORM enables developers to more easily write applications whose data outlives the application process. As an Object/Relational Mapping (ORM) framework, Hibernate is concerned with data persistence as it applies to relational databases (via JDBC).
And from the Spring project definition that:
The Spring Framework provides a comprehensive programming and configuration model for modern Java-based enterprise applications - on any kind of deployment platform. A key element of Spring is infrastructural support at the application level: Spring focuses on the "plumbing" of enterprise applications so that teams can focus on application-level business logic, without unnecessary ties to specific deployment environments.
Conclusion:
As you can see Hibernate and Spring are two differents frameworks that handles differents levels of Java Applications.
Related
There's a straight-forward way of using redis, jdbc, etc as persistence for spring sessions with minimal configuration but due to some serialization issue which I have been facing in that approach, I am thinking of having a custom implementation to intercept the session and then write implementations for save and retrieval of the session in redis and spring security take care of everything else.
Currently, in my application (thymeleaf based frontend), I have integrated spring-security for a form-based authentication.
Just to mention, the issue I am facing and which is what I am trying to avoid, is that with the config based persistence approach, I am getting serialisation exceptions for the model classes which I am using in various views. I am not understanding why session layer is trying to persist other POJOs along with just the session. Tye solution was to have those POJOs implement Serializable but this was also required to be done for library classes as well.
I am trying to understand various dependencies of spring boot.
I have come across three of them:
spring-boot-starter-data-rest
spring-boot-starter-data-jpa
spring-boot-starter-data-jdbc
I would like to know the difference between the three. Tried searching online documents, which say the three are almost related to spring data. how to resolve the confusion?
To add in here I have also found an another dependency
spring-boot-starter-web-services. I think it supports both SOAP and REST. Its just my assumption, I waiting for an explanation
spring-boot-starter-data-jpa is used to access your database with JPA (Java Persistence API)
spring-boot-starter-data-jdbc is used to access your data with jdbc (Java Database Connectivity)
the difference between JPA and JDBC is the level of abstraction. JDBC is more low level, JPA is more 'magic'
and spring-boot-starter-data-rest is used to provide Rest Endpoints on top of your Spring Data repositories.
To do this, you just annotate your spring data repository with a RepositoryRestResource annotation and direct Spring MVC creates the Restful endpoints.
#RepositoryRestResource(collectionResourceRel = "people", path = "people")
public interface PersonRepository extends PagingAndSortingRepository<Person, Long> {
List<Person> findByLastName(#Param("name") String name);
}
This is very handy if you do very CRUD like (Create, Read, Update, Delete) applications.
JPA means "Java Persistence API". It's for querying or saving data in relational databases using object-relational mapping.
REST means "REpresentational State Transfer". It's a style for creating web services that leverages HTTP verbs, a simpler alternative to SOAP.
JDBC starter uses the Spring JdbcTemplate to query or save data in relational databases without relying on object-relational mapping. You write SQL and ask the JdbcTemplate class to execute it in the database using JDBC.
I would say JPA and JDBC starters should be mutually exclusive: either one or the other.
You use REST only if you're writing web services. These may or may not query or persist data in a relational database. I would expect to see both the REST starter and a persistence starter in a pom if a REST service needed persistent data.
Three very different starters.
You ask why Spring Boot has a REST data starter parent that combines the two. In a word: convenience.
Specification
Each tenant has their own database which handles users in greater detail, and there needs to exist a central database which handles:
Tokens (OAuth2)
Users (limited level of detail)
Mapping users to their database
Problem
I've found solutions for multi-tenancy which allows me to determine the datasource depending on the user. However, I'm not sure how I can also link certain crud repositories to this central datasource, and others to variable datasources.
Another solution involved updating the properties file, and using a configuration server (i.e. via git) to trigger #RefreshScope annotated configs. Though I'm not sure if this can work for Datasources, or if this could cause problems later on.
Extra Context
I'm using Spring Boot and Hibernate heavily in this project.
This blog gives a very good tutorial on how to do it.
After a lot of research it looks like hibernate just isn't built for doing that, but by manually writing the schema myself I can inject that into new tenant databases using native queries.
I also had a problem with MS Server DBs, as they don't allow simply appending ;createDatabaseIfNotExist to the JDBC URL, which meant even more native queries (Moving the project over to use MySQL anyway, so this is no longer a problem.)
From what I have read so far, Propagation.REQUIRES_NEW makes use of transaction suspension capabilities in most common Java EE containers (JBoss, Glassfish, etc.)
However, as we're running Spring Data inside Vert.x, which is container-less, I'd like to find a definitive answer as to whether REQUIRES_NEW is supported in this scenario, or if we will have to use another approach for this.
You can use Spring #Transactional annotations out of a JavaEE container. It will work well if you only use a database.
If you mix transactional components (a relational database and a message broker) then you need a transaction manager, which is often only available in JavaEE container.
I'm not a Spring or SpringBoot expert but I am pretty sure it's not difficult nowadays to add a transaction manager to a Spring/Tomcat project.
As for running Spring Data in Vert.x, it will work fine if you deploy this code in worker verticles. Check out the spring-worker sample in the vertx-examples repository on GitHub
What role is Spring taking in Struts + Spring + Hibernate?
Spring provides many different "modules" and different programmers will use different parts of Spring.
However, commonly in this sort of stack, you will see Spring being used as a provider of
An inversion of control container for dependency injection
An abstraction to Hibernate called "HibernateTemplate"
Framework classes for simplifying Aspect Oriented Programming
Transaction support, often "declaratively" via the IoC container and AOP.
Well, Hibernate handles the persistence part, JSP handles your GUI, Struts controls the flow between pages/actions/etc, and Spring can manage all your beans which contain the main business logic, instead of using EJB. Plus it can simplify the coding of your Hibernate DAO's and transaction managing.
Instead of having to code your Locator to obtain some EJB through JNDI and all that stuff, you can just get the Spring ApplicationContext and ask for the bean you need. All the beans defined in Spring can be interconnected. If you have to connect one of your beans to an external EJB through JNDI you can even do so without any code (Spring offers a JNDI proxy object which obtains the reference you give it and returns it as an object with the interface you specify). This can help you simplify unit testing of all those beans and change the config without recoding anything; you can use one of Spring's PlatformTransactionManagers to manage a DataSource or point it to a J2EE container's JTA manager; define your own pooled DataSource or use your container's DataSource published through JNDI, etc.
Well to add;
(Views and Controllers) Struts for its extensive JSP features with Struts tags and web request handling features
(Service and application management) Spring to handle the ORM and service layers with its excellent dependency injections,etc.
(ORM with db independence) Hibernate for well proven ORM