spring 拾遗
1.@PostConstruct VS
init-method
1.1 both BeanPostProcessor
1.2 @PostConstruct
is a JSR-250 annotation while init-method
is Spring's way of having an initializing method.
1.3 If you have a @PostConstruct
method, this will be called first before the initializing methods are called.
1.4 If your bean implements InitializingBean and overrides afterPropertiesSet
, first @PostConstruct
is called,
then the afterPropertiesSet
and then init-method
.
2.
EntityManagerFactory emf = ... EntityManagerHolder holder = (EntityManagerHolder)TransactionSynchronizationManager.getResource(emf); EntityManager em = holder.getEntityManager();
3.MethodValidationPostProcessor
A convenient BeanPostProcessor
implementation that delegates to a JSR-303 provider for performing
method-level validation on annotated methods.
4.LocalSessionFactoryBean
FactoryBean
that creates a Hibernate SessionFactory
. This is the usual way to set up a shared Hibernate
SessionFactory in a Spring application context; the SessionFactory can then be passed to Hibernate-based
data access objects via dependency injection.
5.LocalContainerEntityManagerFactoryBean
FactoryBean
that creates a JPA EntityManagerFactory
according to JPA's standard container bootstrap contract.
This is the most powerful way to set up a shared JPA EntityManagerFactory in a Spring application context;
the EntityManagerFactory can then be passed to JPA-based DAOs via dependency injection. Note that
switching to a JNDI lookup or to a LocalEntityManagerFactoryBean
definition is just a matter of configuration!
6.SharedEntityManagerCreator
Delegate for creating a shareable JPA EntityManager
reference for a given EntityManagerFactory
.
A shared EntityManager will behave just like an EntityManager fetched from an application server's JNDI
environment, as defined by the JPA specification. It will delegate all calls to the current transactional
EntityManager, if any; otherwise it will fall back to a newly created EntityManager per operation.
For a behavioral definition of such a shared transactional EntityManager, see PersistenceContextType.TRANSACTION
and its discussion in the JPA spec document. This is also the default being used for the annotation-based PersistenceContext.type()
.
14.3.5 Transaction management strategies
Both TransactionTemplate
and TransactionInterceptor
delegate the actual transaction handling to a PlatformTransactionManager
instance, which can be a HibernateTransactionManager
(for a single Hibernate SessionFactory
, using a ThreadLocal
Session
under
the hood) or a JtaTransactionManager
(delegating to the JTA subsystem of the container) for Hibernate applications. You can
even use a customPlatformTransactionManager
implementation. Switching from native Hibernate transaction management to
JTA, such as when facing distributed transaction requirements for certain deployments of your application, is just a matter
of configuration. Simply replace the Hibernate transaction manager with Spring’s JTA transaction implementation. Both
transaction demarcation and data access code will work without changes, because they just use the generic transaction
management APIs.
For distributed transactions across multiple Hibernate session factories, simply combine JtaTransactionManager
as a transaction
strategy with multiple LocalSessionFactoryBean
definitions. Each DAO then gets one specific SessionFactory
reference passed into
its corresponding bean property. If all underlying JDBC data sources are transactional container ones, a business service can
demarcate transactions across any number of DAOs and any number of session factories without special regard, as long as it
is using JtaTransactionManager
as the strategy.
7.
Caused by: org.springframework.beans.factory.BeanCreationException: Could not autowire field: private com.ys.scs.performance.PerformanceService
com.ys.scs.vip.MemberCardService.performanceService; nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException:
Error creating bean with name 'performanceService': Bean with name 'performanceService' has been injected into other beans [resetTaskPerformanceService,billAdaptorService]
in its raw version as part of a circular reference, but has eventually been wrapped. This means that said other beans do not use the final version of the bean.
This is often the result of over-eager type matching - consider using 'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.
该问题出现的原因是:在正常加载完依赖后,因为 @Async
注解的出现,又需将该 Bean 代理一次,然后 Spring 发现该 Bean 已经被其他对象注入,
且注入的是没被代理过的版本,于是报错。@Lazy注解可以解决