In a spring test there was the question:
"Would Spring Data JDBC dependency autoconfigure a Datasource and a JDBCTemplate?"
I would say no because, you need a database connector dependency like h2 or oracle right to autoconfigure a datasource? And a JDBCTemplate needs also always a datasource?
I suspect what you think is correct, also the wording is a litte off.
Strictly speaking Spring Data JDBC doesn't do any autoconfiguration at all.
Autoconfiguration is done by Spring Boot in cooperation with the Spring Boot Spring Data JDBC starter which depends on (i.e. includes the auotconfiguration done by the Spring Boot Starter JDBC
And that's the one actually autoconfiguring a Datasource and if a Datasource is available also provides/configures a JdbcTemplate.
In order to be able to configure a Datasource at the very least a JDBC Driver is required.
Depending on the environment (is it a in memory database or not, are you in a test execution or not) possibly also some configuration properties like a JDBC URL is required as well.
If you want to understand better what the conditions are for autoconfiguration I recommend the list of Spring Boot autoconfiguration classes.
If you search that list for e.g. "datasource" you'll find the relevant classes and links to their source code and annotations which I think are somewhat understandable even when you don't yet understand how Spring Boot works internally exactly.
Related
How can I use the Spring Data REST feature in AWS Lambda without using the SpringBoot dependencies which has TOMCAT and Other Heavy dependencies with it ?
My objective is to create a CRUD Lambda completely based on JSON (HATEOS - id possible)
but with minimalistic dependencies - so lambda can fire up easily
First things first: if you want to have a Lambda function which should start fast, you should not use Java (but depends on your use case). Here is a nice performance comparison between Java and Node.Js on Lambda.
If you still want to use Java and Spring Data REST, you should take a look at this AWS repository which provides a basic framework to instantiate Spring within Lambda. Based on that you should be able to add Spring Data REST.
We have a webapp that is currently running on one instance of Apache Tomcat with one database instance, but the increase in traffic will soon (probably) force us to resort to load-balancing several webapp instances, and we've run into a problem that seems to have no easy answer.
Currently our JDBC DataSource is configured as Resource-local, rather than Transactional, and after some searching, everyone recommends to use Transactional, which requires the use of a JTA provider. No real justification is used for why I don't just stick with the current scenario where we have a servlet filter catch any unhandled exceptions and rollback the active transaction. Besides that the only one I've found that is just a JTA provider (not with 5 more JEE technologies combined) and is still maintained is Bitronix. The other alternative is to move out of Tomcat and use Glassfish, since it is a full Java EE platform, and we also use JavaMail, JPA and JAX-RS.
Only one transaction scenario uses Serializable isolation level.
As for the database, we may be looking too far ahead to think of distributed storage like Postgres-XL or pgpool, but if we make the wrong choice now it will be harder to fix later.
My questions are as follows:
Do synchronous database replication tools and JTA complete each-other, hinder each-other or just perform the same consistency checks twice?
Do we need JTA if we only have one database, but multiple webapp instances?
Do we need JTA if we have multiple database and multiple webapp instances?
Should we just switch to Glassfish or something like TomEE?
Supposedly there are ways we can keep using Hibernate as our JPA under both. It would be tedious to have to rewrite all our native queries to use positional parameters because EclipseLink and OpenJPA don't support them. That little extra feature makes Hibernate worth choosing above all other JPAs for me.
i want to know is there any way to use spring cloud config client without spring boot in a spring web application.
i want to use spring cloud config with #Value annotation and i don't like to use spring cloud server rest api in my web application
i have tried what developers said in Spring Cloud Config Client Without Spring Boot link but it didn't work
Yes it's possible. You will have to add spring boot but don't have to really use it (we had it working in a non-springboot app). Check this code here https://github.com/4finance/micro-infra-spring/tree/master/micro-infra-spring-config . You don't need a config server then to use the properties. I don't have a code snippet for that but you would have to create manually a spring boot context in your just to make this work. Also check this answer - Spring Cloud Config Client Without Spring Boot . Even if you will make it work it doesn't mean that the ordering will be proper.
The suggested solution then is to actually use Spring Boot :)
I provided an answer here : Spring Cloud Config Client Without Spring Boot that can help you. It's a working prototype to load property sources from Zookeeper using Spring Cloud Config Zookeeper in a webapplication without Spring Boot.
I'm at design phase of my project and I have a doubt.
I'm modelling my system and I will use Spring Data JPA for persistence layer. Although, there is high chances of cloud deploy. Is it traumatic the portability from Spring Data JPA to Spring Clous AWS (RDS)? I didn't find direct metion about this kind of integration.
I'm trying to avoid a waste code in future.
Best Regards,
These are actually two separate things. Spring Cloud AWS JDBC will just configure a DataSource while Spring Data JPA is going to use it.
So you can use Spring Data JPA and you will be able to move your application to AWS without much efforts (basically just changing the way the DataSource is setup).
I'm beginner in OSGi, My project consists of developping and executing, within an OSGi container (apache felix; the distribuable jar), a persistence bundle (using jpa) and then communicating with the database (MySql) through a jpa provider (Hibernate).
I read about the jpa specification for OSGi, so, if I have correctly understood, I must use a JPA provider for OSGi implementing the OSGI jpa enterprise specification. this jpa provider will track for a registered persistence bundle to make an EntityManagerFactory for it ?
So what is the difference between using a jpa provider directly to create the EntityManagerFactory (Persistence.createEntityManagerFactory("xx")) or retrieving it from the registry :
serviceReferences = context.getServiceReferences(
EntityManagerFactory.class.getName(),
String.format("(%s=%s)",
EntityManagerFactoryBuilder.JPA_UNIT_NAME,
persistenceUnit));
I wouldn't like to use any container (apache karaf, geronimo, spring dm, ..) so, is it sufficient that I will instal and start in the OSGi container for example the "org.apache.aries.jpa.api" as an implementation of the OGSi enterprise jpa spec and then only retrieve an "EntityManagerFactory" service from the registry associated to my persistence unit name, or I should also register by myself a PersistenceProvider like HibernatePersistence to can declare it as "provider" in my persistence.xml file ?
I found many discussion in this topic here. I still having trouble, though
Thanks
OSGi is about services and services are extremely easy to consume in OSGi with the proper setup. You show a very old style example with service references and I do agree, in that model it is a lot easier to just use the old fashioned JPA way.
However, if you use Declarative Services, using services becomes very lightweight. You get injected with an EntityManagerFactory service that is completely prepared for you. The deployer could have tuned all kinds of settings with Config Admin, connection pools, another JPA provider, etc. It is a clear separation of concerns.
By not really knowing where this thing comes from and who implements it you get less assumptions in your code and your code will therefore be less error prone and more reusable. I principle, the fact that use Hibernate and MYSQL is completely irrelevant to most of your code. Yes, I do know that neither JPA nor SQL is very portable in practice but there are many aspects that are ignorant of the differences. It is the deployer that is then in the end responsible to put together the parts that work.
Now Declarative Services (DS) is of course an extra bundle but after using OSGi for 15 years now I declare any OSGi developer NOT using DS, well, let me not go too deep into that to keep it civil :-) If I would be back in the beginning of OSGi, DS would have been built into the framework, it is for the lowest level to program with.