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注解可以解决