You can retrieve Seam components in your entities through the context but I would not generally recommended it as it reduces testability. Essentially entities can contain (and should in my opinion) contain your business logic, but when it comes to 'Service' invocations these are intended to be performed at the Service Level with Seam. In all cases I have run into this is really not an issue and I have successfully developed applications following the patterns of DDD with DI frameworks that follow this approach (including Seam).
Also, keep in mind that entities are only Seam components when they are instantiated implicitly by Seam. This could lead to some odd scenarios if DI were present as entities are often explicitly created.
thanks for your answer. Actually IMO your are right, in saying entities should contain the
business logic. If we speak of services, we could also speak of helper or utility classes that might be nice to be declared and auto-injected as seam contextual components, I think.
Sure, there are cases where you don't want to invoke services, in the good old anti-pattern sort of way, from within the entities, but rather from the Service or Application Layer.
But on the other hand, there are cases, where tying up services or utility classes in the entities itself provides for a neater programming model indeed. By not allowing DI on entities we constrain the programmer unnecessarily, IMO.
Anyway, I can surely circumvent that restriction (as I see it). I don't know what other people think of it, but I would love to have DI expanded to all classes of the model and not restrict it to certain types of beans, though I don't exactly know what would have to be done to do so.
Maybe I could file a feature request (or would I get grilled if I did so? :)) By the way, is there any official way for feature requests to get voted on?
thanks + greetings, sven