A. … In that case, if they were SEAM components, they will by default be in CONVERSATION scope. In cases where the domain object is needed only in specific sections (or pages) of the application, one can very well make the domain object conversation scope. However, that also means that the pages involved have to use the same conversation which may or may not be the case.

You should definitely always consider the scope you are outjecting to. In regards to domain objects, I assume you are referring to @Entity instances based on your comment. I would generally not make my @Entity instances Seam components as this does not provide much benefit IMO. @Entity instances are not intercepted and are not bijected. It is not necessary to make an @Entity a Seam component to outject it to the context.

The following quote is from the Seam Documentation:

Because entities have a persistent identity in addition to their contextual identity, entity instances are usually bound explicitly in Java code, rather than being instantiated implicitly by Seam.

If the Entity was instantiated implicitly by Seam the behavior you site is correct. The Entity would be bound to the Conversation context.

B. … You can still expose the UserProfile as a conversation-scoped variable using SEAM @Roles and @Role annotation. You could also provide a POJO which is conversation-scoped and has the UserProfile object in session scope injected into it.

Yes, you certainly can. This type of behavior is very desirable especially if you want to develop a user administration portion of your application for instance.

C. Another way to test the code presented towards the end could be to create a UserProfileDAO with precedence level of MOCK and hook …

Absolutely, this is the general approach and is always an option. However if I want to test my component in isolation, it is quite simple to test if I only have to provide the domain object it is looking for rather than having to create a mock that provides that object.

Once again, the blog above is a piece of art. So, keep them coming. And now, time for the comments.

A. In most J2EE applications that use databases, core domain objects tend to be persistent domain objects. In that case, if they were SEAM components, they will by default be in CONVERSATION scope. In cases where the domain object is needed only in specific sections (or pages) of the application, one can very well make the domain object conversation scope. However, that also means that the pages involved have to use the same conversation which may or may not be the case.

B. If the UserProfile object was being populated with roles and authentication information obtained from an external authentication mechanism like LDAP etc, then you most certainly would want to put the UserProfile object in SESSION scope to avoid repetitive calls to LDAP or prompting the user to login each time. You can still expose the UserProfile as a conversation-scoped variable using SEAM @Roles and @Role annotation. You could also provide a POJO which is conversation-scoped and has the UserProfile object in session scope injected into it.

C. Another way to test the code presented towards the end could be to create a UserProfileDAO with precedence level of MOCK and hook . Thisi way, you can ensure that your SEAM annotations have been specified correctly.