I haven't actually worked with JSR-330 injection. I got started before all that, when about the best alternative was the Spring Framework and have been disappointed in that the official standard is not only largely incompatible with that, but also seems to lack some of the abilities that Spring has.
Nonetheless, the basic ideas are the same, so I'll try and fake it.
Actually, I use DAOs as single-table CRUD/Finder components (or occasionally with parent/child sets) and have a separate persistence service layer that allows me to work with complex table interrelationships. The actual Transaction boundary is at the Service layer methods and application code never invokes DAOs directly.
Spring automatically injects the EntityManager into my DAOs. I'm pretty sure that EJB3 has a similar mechanism (haven't looked in a while) and I'm reasonably sure that SPI could do the same. Simplifies things a bit and avoids the need for service lookups that hard-code properties into beans that don't need them.
So in conformance with common practice with EJB-like technologies, I'd have a findAll() method to retrieve the List of TV_tvshows. Spring has a @Transactional annotation, so the logic would be simpler than yours. I'm not 100% certain that a "SELECT" should even need a transaction, although quirks in some environments make me unwilling to flatly say so. A "commit" is supposed to trigger a database update, and SELECT is read-only.
Your
JSF Model object (EventBean) isn't a JSF-friendly POJO. The method named "test" cannot be used as a bean property because JSF expects POJO get/set methods Something more like this:
Although for performance and reliability reasons, you'd actually want to cache the find method's results instead of fetching them every time getTvshows() was invoked.
Those are just general design observations, though. I cannot clearly envision what you have connected where so that you get the exception. Try posting the actual stack trace. We can generally make sense of foreign-language error messages.