Sahoo,
You understood my situation perfectly.
I understand now why the SiteDao was not injected into the User entity. Because the User entity comes from the EntityManager, CDI doesn't get a chance to handle it. So if that's the way it is, that's fine.
However, please allow me to get on my soapbox a bit. :) To me a great technology is one that, given a user of reasonable expertise, works exactly as the user expects it to (a.k.a. the "It Just Works!" quality).
From the perspective of a client of the model, there's little difference between, say, Site.getUsers() and Site.getActiveUsers(). The fact that Site.getUsers() is implemented under the hood as a JPA mapped relationship, whereas Site.getActiveUsers() is implemented as a JPQL query, should be hidden from model clients.
I've seen both the DAO and Repository patterns configured such that entity classes had references to them, and would expose their methods as entity methods for convenience. e.g. The Site entity might have a reference to UserDao, and expose UserDao.findByStatus() as Site.getActiveUsers(). This way, clients wouldn't even have to know about the UserDao under the hood.
So it would be nice if CDI could also inject into objects like entities returned from an EntityManager. I realize that may be beyond CDI's current capabilities, but I will not be the last developer scratching my head as to why, in cases like this one, CDI doesn't work as I expect it to. Granted, that may be partly naivete on my part, but maybe it's possible in a future CDI release.
As for decorators... I'm definitely no expert on them, but from what I know about the pattern in general, and from what I've read about its implementation in CDI, it seems like a stretch to apply it in this scenario. I'd rather not resort to decorators just as a hack around a CDI limitation.
Thanks again for your help,
-Dan
Message was edited by: theodan
Message was edited by: theodan
[Message sent by forum member 'theodan']
http://forums.java.net/jive/thread.jspa?messageID=396369