JPA field access vs property access

For field access, you do not need have set or get method. You specify field. But for property, you use set and get to set value.

After reading "IT Managers confession"

Today I found a very interesting book about IT manager, below are the some points I got from that book:

• Good team knows how to handle their manager, train the manager to do things their way.
  
• As a manager, if you do not like someone and you can not get rid of him/her, then it is better promote him/her to another position, so he/she can leave the group. But keep the good people with you.
• Find a Yancey man who can speak for you. He has excellent communication skill , he can talk regular language to customers and stake holders. But you need him to follow you, speak your mind not his own mind. That is hard.
  
• Looking Busy:

1. arrival early and leave late does not mean you hard, you can leave in the middle.
2. Using MS project to create a lot of report.
3. A lot of meeting and crisis management.
4. Ask your developer to send everything for you to approval.
5. visit other department regularly.
6. find any chances to complain too many emails.
   

• 
  

Spring JPA annotation transaction.

It has been weeks I could not figure out why I can not use annotation based transaction control, and it forced me to use programmatic transaction control. Today I found this post from theserverside, which explains everything.


it's caused by the use of the BeanFactory instead of an ApplicationContext, which is used inside the unit test, behind the scene when using the AbstractJpaTests base class.

If you change your Main class to

Code:

public class Main {

public static void main(String[] args) {
ApplicationContext ctx = new ClassPathXmlApplicationContext("context/testContext.xml");
PersonDAO dao=(PersonDAO)ctx.getBean("personDAO");

Person p=new Person();
p.setFirstName("testName");
dao.save(p);
}
}

it will work.

The reason for that is a slightly different behavior between a BeanFactory and an ApplicationContext when it comes to BeanPostProcessors. From the Spring reference manual:

It is important to know that a BeanFactory treats bean post-processors slightly differently than an ApplicationContext. An ApplicationContext will automatically detect any beans which are defined in the configuration metadata which is supplied to it that implement the BeanPostProcessor interface, and register them as post-processors, to be then called appropriately by the container on bean creation. Nothing else needs to be done other than deploying the post-processor in a similar fashion to any other bean. On the other hand,
when using a BeanFactory implementation, bean post-processors explicitly have to be registered, with code
like this:

ConfigurableBeanFactory factory = new XmlBeanFactory(...);
// now register any needed BeanPostProcessor instances
MyBeanPostProcessor postProcessor = new MyBeanPostProcessor();
factory.addBeanPostProcessor(postProcessor);
// now start using the factory

This explicit registration step is not convenient, and this is one of the reasons why the various
ApplicationContext implementations are preferred above plain BeanFactory implementations in the vast majority of Spring-backed applications, especially when using BeanPostProcessors

That's the whole reason, why your PersistenceAnnotationBeanPostProcessor never got loaded and therefore couldn't do its work!

From dzone.com: Three Questions About Each Bug You Find

Three Questions About Each Bug You Find

I really love this timeless Tom Van Vleck article from 1989. It teaches us to ask ourselves:

Three Questions About Each Bug You Find

Those questions being:

1. Is this mistake somewhere else also?
2. What next bug is hidden behind this one?
3. What should I do to prevent bugs like this?

When I first read these rules, I was foolish enough to think:

'Cute, But Too Obvious! i do this intuitively all the time.'

But watch yourself closely! I've caught myself out on occasion, and maybe you will too.

I'm making an effort to be more explicit about the three questions. Maybe i'll end up fixing related problem

My first blog

Today it is the first time I have a blog, I guess I will spend some of my spare time at this blog in the future.