Here&#39;s some additional feedback I received from a community member a while back...to merge it into this thread.<div><br></div><div>(begin feedback)</div><div><br></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><span class="Apple-style-span" style="border-collapse: collapse; color: rgb(51, 51, 51); font-family: arial, sans-serif; font-size: 13px; ">...from being burned from 3 seam based customers with apps and maintenance.  The &quot;Home&quot; or any other name should be just be put into a grave and slowly cast away to sea ;).  It is too heavy and complicated and just about anything inherited (extends) truly causes heartache[Favor Composition over inheritance: Effective Java]. The current seam home has a few super classes above the home and when you try to unit test it (the standard definition of unit-testing including isolation) you get the &quot;No Active Application Context Found (if I remember it right).  That happens because it is tightly coupled with the application.  But not to be hard on Home, I do realize the history of the home object and know it was developed when EL had no parameters. So I have learned a lot since then and I here are some things that I can impart to Seam 3.  <br>

<br>1. My &quot;Home&quot; now is a &quot;ServiceBean&quot;, and I have one for each &quot;Major&quot; <span class="il" style="background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: rgb(255, 255, 204); color: rgb(34, 34, 34); background-position: initial initial; background-repeat: initial initial; ">entity</span>, see below.  I have really stewed over this over months and months, and the &quot;Home&quot; of &quot;ServiceBean&quot; should be kept small, focused, reusable, tested and untouched.  It&#39;s only task is to update, persist, possibly remove, or some other functions that are required.  In my example below I have custom close action.  Notice also that although these beans are stateful that doesn&#39;t mean everything should be, so in these methods I have the parameter of what is being needed to be updated, and not a field.  In other words I don&#39;t have @In private Job job, I opted for public boolean update(job).  Mostly because, again, I want to make this service bean reusable so whether I have a #{newJob}, #{copyOfAJob}, or #{managedJob} or whatever component of job I need to work on I only need one jobServiceBean to cater to all my jobs, in whatever conversation I am using.  I also fire events from here if I need to do that.   After this is tested, and what I need I usually don&#39;t touch it anymore.  If I need to enhance I either use a decorator pattern around it, or enhance it in an @Observer.  I&#39;ll email about that later.<br>

<br>@Name(&quot;jobServiceBean&quot;)<br>@Scope(ScopeType.CONVERSATION)<br>public class JobServiceBean implements JobService {<br>    private EntityManager entityManager;<br>    private StatusMessages statusMessages;<br>
<br>
    @In<br>    public void setEntityManager(EntityManager entityManager) {<br>        this.entityManager = entityManager;<br>    }<br><br>    @In<br>    public void setStatusMessages(StatusMessages statusMessages) {<br>        this.statusMessages = statusMessages;<br>

    }<br><br>    public boolean update(Job job) {<br>        this.entityManager.flush();<br>        this.statusMessages.add(<a href="http://statusmessage.severity.info/" target="_blank" style="color: rgb(61, 84, 89); ">StatusMessage.Severity.INFO</a>, &quot;Successfully updated job {0}&quot;, job.getName());<br>

        return true;<br>    }<br><br>    public boolean close(Job job) {<br>        job.setJobStatus(JobStatus.CLOSED);<br>        this.entityManager.flush();<br>        this.statusMessages.add(<a href="http://statusmessage.severity.info/" target="_blank" style="color: rgb(61, 84, 89); ">StatusMessage.Severity.INFO</a>, &quot;Successfully closed job {0}&quot;, job.getName());<br>

        return true;<br>    }<br>}<br><br>2. One thing you may have noticed from above that there is no &#39;instance&#39; field with corresponding getters or setters like the old &#39;Home&#39;.   So the ServiceBean in my case is not a full crud, but CUD + your own business methods. That&#39;s because that too should be decoupled because we never know the source of the object is.  Is the object created from a factory? from a copy? is it a mapped component, a managed component?  Creation of objects or loading of objects, or the manufacturing of objects from factories should be separate from the &quot;home&quot; or in my case the &quot;ServiceBean&quot;.</span><br>

<br></div><div>(end feedback)</div><div><br>-- <br><div>Dan Allen</div>Principal Software Engineer, Red Hat | Author of Seam in Action<br>Registered Linux User #231597<br><br><div><a href="http://www.google.com/profiles/dan.j.allen#about" target="_blank">http://www.google.com/profiles/dan.j.allen#about</a><br>

<a href="http://mojavelinux.com" target="_blank">http://mojavelinux.com</a><br><a href="http://mojavelinux.com/seaminaction" target="_blank">http://mojavelinux.com/seaminaction</a><br></div><br>
</div>