<commit_before><!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd"  [ ]>

<chapter id="producermethods">
 
  <title>Producer methods</title>
  
  <para>Producer methods let us overcome certain limitations that arise when the Web Bean manager, 
  instead of the application, is responsible for instantiating objects. They're also the easiest 
  way to integrate objects which are not Web Beans into the Web Beans environment. (We'll meet
  a second approach in <xref linkend="xml"/>.)</para>

  <para>According to the spec:</para>

  <blockquote>

    <para>A Web Beans producer method acts as a source of objects to be injected, where:</para>

    <itemizedlist>
      <listitem>
        <para>the objects to be injected are not required to be instances of Web Beans,</para>
      </listitem>
      <listitem>
        <para>the concrete type of the objects to be injected may vary at runtime or</para>
      </listitem>
      <listitem>
        <para>the objects require some custom initialization that is not performed by the 
        Web Bean constructor</para>
      </listitem>
    </itemizedlist>

  </blockquote>

  <para>For example, producer methods let us:</para>

  <itemizedlist>
    <listitem>
      <para>expose a JPA entity as a Web Bean,</para>
    </listitem>
    <listitem>
      <para>expose any JDK class as a Web Bean,</para>
    </listitem>
    <listitem>
      <para>define multiple Web Beans, with different scopes or initialization, 
      for the same implementation class, or</para>
    </listitem>
    <listitem>
      <para>vary the implementation of an API type at runtime.</para>
    </listitem>
  </itemizedlist>

  <para>In particular, producer methods let us use runtime polymorphism with 
  Web Beans. As we've seen, deployment types are a powerful solution to the problem 
  of deployment-time polymorphism. But once the system is deployed, the Web Bean 
  implementation is fixed. A producer method has no such limitation:</para>

<programlisting role="JAVA"><![CDATA[@SessionScoped
public class Preferences {
    
    private PaymentStrategyType paymentStrategy;
    
    ...
    
    @Produces @Preferred 
    public PaymentStrategy getPaymentStrategy() {
        switch (paymentStrategy) {
            case CREDIT_CARD: return new CreditCardPaymentStrategy();
            case CHEQUE: return new ChequePaymentStrategy();
            case PAYPAL: return new PayPalPaymentStrategy();
            default: return null;
        } 
    }
    
}]]></programlisting>

  <para>Consider an injection point:</para>

<programlisting role="JAVA"><![CDATA[@Preferred PaymentStrategy paymentStrat;]]></programlisting>

  <para>This injection point has the same type and binding annotations as the producer
  method, so it resolves to the producer method using the usual Web Beans injection 
  rules. The producer method will be called by the Web Bean manager to obtain an instance 
  to service this injection point.</para>.

<section>
  <title>Scope of a producer method</title>

  <para>The scope of the producer method defaults to <literal>@Dependent</literal>, and so
  it will be called <emphasis>every time</emphasis> the Web Bean manager injects this field 
  or any other field that resolves to the same producer method. Thus, there could be 
  multiple instances of the <literal>PaymentStrategy</literal> object for each user session.</para>

  <para>To change this behavior, we can add a <literal>@SessionScoped</literal> annotation 
  to the method.</para>
  <commit_msg>WBRI-281<commit_after><!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd"  [ ]>

<chapter id="producermethods">
 
  <title>Producer methods</title>
  
  <para>Producer methods let us overcome certain limitations that arise when the Web Bean manager, 
  instead of the application, is responsible for instantiating objects. They're also the easiest 
  way to integrate objects which are not Web Beans into the Web Beans environment. (We'll meet
  a second approach in <xref linkend="xml"/>.)</para>

  <para>According to the spec:</para>

  <blockquote>

    <para>A Web Beans producer method acts as a source of objects to be injected, where:</para>

    <itemizedlist>
      <listitem>
        <para>the objects to be injected are not required to be instances of Web Beans,</para>
      </listitem>
      <listitem>
        <para>the concrete type of the objects to be injected may vary at runtime or</para>
      </listitem>
      <listitem>
        <para>the objects require some custom initialization that is not performed by the 
        Web Bean constructor</para>
      </listitem>
    </itemizedlist>

  </blockquote>

  <para>For example, producer methods let us:</para>

  <itemizedlist>
    <listitem>
      <para>expose a JPA entity as a Web Bean,</para>
    </listitem>
    <listitem>
      <para>expose any JDK class as a Web Bean,</para>
    </listitem>
    <listitem>
      <para>define multiple Web Beans, with different scopes or initialization, 
      for the same implementation class, or</para>
    </listitem>
    <listitem>
      <para>vary the implementation of an API type at runtime.</para>
    </listitem>
  </itemizedlist>

  <para>In particular, producer methods let us use runtime polymorphism with 
  Web Beans. As we've seen, deployment types are a powerful solution to the problem 
  of deployment-time polymorphism. But once the system is deployed, the Web Bean 
  implementation is fixed. A producer method has no such limitation:</para>

<programlisting role="JAVA"><![CDATA[@SessionScoped
public class Preferences {
    
    private PaymentStrategyType paymentStrategy;
    
    ...
    
    @Produces @Preferred 
    public PaymentStrategy getPaymentStrategy() {
        switch (paymentStrategy) {
            case CREDIT_CARD: return new CreditCardPaymentStrategy();
            case CHEQUE: return new ChequePaymentStrategy();
            case PAYPAL: return new PayPalPaymentStrategy();
            default: return null;
        } 
    }
    
}]]></programlisting>

  <para>Consider an injection point:</para>

<programlisting role="JAVA"><![CDATA[@Preferred PaymentStrategy paymentStrat;]]></programlisting>

  <para>This injection point has the same type and binding annotations as the producer
  method, so it resolves to the producer method using the usual Web Beans injection 
  rules. The producer method will be called by the Web Bean manager to obtain an instance 
  to service this injection point.</para>

<section>
  <title>Scope of a producer method</title>

  <para>The scope of the producer method defaults to <literal>@Dependent</literal>, and so
  it will be called <emphasis>every time</emphasis> the Web Bean manager injects this field 
  or any other field that resolves to the same producer method. Thus, there could be 
  multiple instances of the <literal>PaymentStrategy</literal> object for each user session.</para>

  <para>To change this behavior, we can add a <literal>@SessionScoped</literal> annotation 
  to the method.</para>
  
{'fraction_non_alphanumeric': 0.0870904508541025, 'fraction_numerical': 0.0015401848221786615, 'mean_word_length': 3.4065391733497843, 'pattern_counts': {'":': 0, '<': 151, '<?xml version=': 0, '>': 151, 'https://': 0, 'lorem ipsum': 0, 'www.': 2, 'xml': 4}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5198495', 'n_tokens_mistral': 2039, 'n_tokens_neox': 1891, 'n_words': 786}