If it's too easy to be true

There are a lot of Java EE demos, slides and even documentations out there which show how easy and awesome a use-case can be solved which used to be complex in the past.

The summary:
Don't trust such slides without checking it on your own, if they are published by someone who would like to sell you something. That also applies to open-source companies. Usually it isn't that simple.

The details (by example):
There are a lot of slides and examples out there which show how simple it is to write CDI producers for JPA entities and conversation scoped entity managers. Esp. some Seam folks are publishing it on a regular basis. At the beginning it sounds just awesome but it turns out that it doesn't work well in medium to large sized applications. If you write your small intranet application for organizing your after-work party for your small department, go with it. But in all other cases don't use it.

The problem is that you have two containers (JPA and CDI) which manage the lifecycle of one bean/entity. In some cases it works with @New but it's very dangerous at all. With a simple producer (just using @Produces) you get dependent scoped beans. In the best case you inject it in a request scoped bean and you get a request scoped entity and your persistence provider can handle proxies created by the CDI implementation you are using. But in this case you can directly inject the service in the request scoped bean and load the entity which is even simpler than writing a producer for it. Otherwise, you get problems because you have a session or conversation scoped or custom scoped JPA entity. An entity manager just doesn't work that well with those scopes because it isn't serializable. Hibernate and with some configuration maybe also some other persistence providers supports it and in this case e.g. session replication is possible but doesn't scale (because the state of an entity manager tends to get large) and you have again a vendor lock-in because not every JPA implementation can handle proxies used by the CDI implementation. If you are ok with a vendor lock-in, you can use better ORM frameworks than any JPA implementation can be at the moment. For example eBean is awesome and you can continue to use JPA annotations for mapping your entities. If you like to keep it portable and correct and scaling, you have to use a request scoped entity manager. So you get a detached entity and you have to merge it back on subsequent requests. At this point there is just no point in injecting an entity compared to injecting the service and loading the entity. Furthermore, the idea shown by such slides,... just works for simple cases which require one instance of an entity. Otherwise you have to create qualifiers and the result gets even more complex. Furthermore, you have to provide the id of the entity to such producers, so you have to store them in the same bean as the producer (-> learn more about Java EE or your project will fail) or you can provide it as parameter to the producer and CDI will inject it (-> you created two producers for a simple use-case which just works in simple scenarios -> think about it ;-) ).

The conclusion:
Think beyond very simple demos from the very beginning and don't trust others just because they are e.g. the vendor of something. It's their job that it looks simple and awesome to you. It's better if you look at real communities like Apache projects (catchword: "Community first") which create stuff because they need it for their own big (and real) projects. If you find something which is too good to be true, it's always a good idea to check if there is an Apache project which does similar stuff. Check their documentation (if there is one), JIRA and even source-code or directly send a question to the community. E.g. after checking the Wiki of CODI I found out that they added some similar information about conversation scoped entity managers. It's good to know that there are people out there who don't try to sell you something and provide solutions you can tend to trust immediately, because it doesn't make any difference for them if they have 100 or 100.000 users.