title: Best practice: Spring Autowired, concrete class, and Builder
body: <p>We have an interface:</p>
  
  <pre><code>public interface NotifyService {
  
    public void send();
  </code></pre>
  
  <p>And a class that implements it</p>
  
  <pre><code>public class EmailNotifyService implements NotifyService {
  
    private EmailBuilder _builder;
  
    @Autowired
    PersonRepository _personRepository;
  
    ... other Autowired Repositories ...
  
    public EmailNotifyService(EmailBuilder builder) {
     this._builder = builder;
    }
  
    public void send() {
      // send mail using _builder.getRecipient().getEmailAddress(), etc.
    }
  </code></pre>
  
  <p>We used to instantiate EmailNotifyService with a builder:</p>
  
  <pre><code>public class EmailBuilder {
  
    private Person _recipient;
  
    private EmailType _type;
  
    private Event _event;
  
    public EmailNotifyService build() {
      return new EmailNotifyService(this);
    }
  
    public EmailBuilder recipient(Person recipient) {
      this._recipient = recipient;
      return this;
    }
  </code></pre>
  
  <p>... and so on. But now, instead of using build() to create a new EmailNotifyService, we are trying to use Autowire with Spring instead. The problem is that everywhere else in our app, we are Autowiring interfaces, not classes. And from what I've read it's a good idea in general. In fact, I've tried rewriting the NotifyService to be an Abstract class, and then have EmailNotifyService just extend it. But Spring isn't Autowiring it correctly, it doesn't create a Proxy like it does for interfaces, and all of my Autowired fields are null.</p>
  
  <p>So it would seem we're stuck with Autowiring the NotifyService interface. Fine. What I can't get my head around is - how can I get the data I used to assign with the builder -- the Person, EmailType and Event -- into a Spring Autowired interface?</p>
  
  <p>I suppose I could change the interface definition to have a setPerson(), setEmailType(), etc., but apart from being really ugly, it defeats the purpose of using an interface in the first place. A different NotifyService (WebServiceNotifyService or RestNotifyService for example) night not have need for that info.</p>
  
  <p>Is there any elegant, best-practice way to do this?</p>
  
  <p>Thanks.</p>
  
  <p><strong>EDIT</strong></p>
  
  <p>I am using annotations, very little xml. And I am also using transaction management, which might explain why the abstract class isn't properly autowired? This is the only pertitnent info I have in xml:  </p>
  
  <pre><code>&lt;context:annotation-config /&gt;  
  &lt;context:component-scan base-package="com.myco.myapp" /&gt;  
  &lt;tx:annotation-driven transaction-manager="transactionManager"/&gt;  
  </code></pre>
  
  <p>What I mean when I say "autowiring isn't working correctly" is that when I try to autowire the abstract class, Spring doesn't seem to be creating a Proxy like it does for interfaces, and all the Autowired fields in my EmailNotifyService (PersonRepository, others ...) are null. When I use an interface, all the Autowired fields are wired correctly.  </p>
  
  <p>But my main problem is that I used to work explicitly with a concrete class, using a builder to create a new EmailNotifyService() directly, and pass it info -- Person, EmailType and Event. These are just normal beans. There are no setters/getters for them in EmailNotifyService but there are the EmailBuilder, which used to live inside EmailNotifyService. </p>
  
  <p>But now I am using the NotifyService interface, which knows nothing about Person, EmailType or Event. But I need this info in order for EmailNotifyService to work.  </p>
  
  <p>So my question is, if I use Spring to Autowire my EmailNotifyService like this:</p>
  
  <pre><code>@Autowired
  @Qualifier("email") // so Spring knows I want to use the EmailNotifyService implementation
  NotifyService _notifyService
  </code></pre>
  
  <p>How can I set the Person, EmailType and Event data, since NotifyService knows nothing about them?</p>
  
  <p>Currently we are using the mailer service within a web app but theoretically the mailer service should be able to work stand-alone. Regardless, I don't see how request scoped beans can help me here.</p>