8 Replies Latest reply on Feb 10, 2010 9:13 PM by nickarls

    Weld + JSF - strange behavior

    vadger

      Hello,


      I'm a newbie in Weld and CDI. Can anybody explain the following behavior.


      Here is my controller


      @RequestScoped
      //@Named
      //@Stateless
      @ManagedBean
      public class MyBean implements Serializable {
      
          public MyBean() {
              System.err.println("**** MyBean constructor");
          }
      
          private String hello;
      
          public void sayHello() {
              System.err.println("*** sayHello: " + this.hello);
              FacesContext.getCurrentInstance().addMessage(null, new FacesMessage("Goood..."));
              FacesContext.getCurrentInstance().addMessage(null, new FacesMessage(this.hello));
          }
      
          public String getHello() {
              return hello;
          }
      
          public void setHello(String hello) {
              this.hello = hello;
              System.err.println("***** HELLO: " + this.hello);
          }
      }
      



      And view


      <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
      <html xmlns="http://www.w3.org/1999/xhtml"
            xmlns:h="http://java.sun.com/jsf/html"
            xmlns:f="http://java.sun.com/jsf/core"
            xmlns:ui="http://java.sun.com/jsf/facelets">
          <h:head>
              <title>Facelet Title</title>
          </h:head>
          <h:body>
              <f:view>
                  <h:form>
                      <div style="color: green">
                          <h:messages id="messages"/>
                      </div>
                      <h:inputText value="#{myBean.hello}"/>
                      <h:commandButton action="#{myBean.sayHello}" value="Click me"/>
                  </h:form>
              </f:view>
          </h:body>
      </html>
      



      When I'm using pure JSF loading the page I'm getting in console output:




      SEVERE: **** MyBean constructor



      Submitting the form:




      SEVERE: **** MyBean constructor
      SEVERE: ***** HELLO: Hello, world
      SEVERE: *** sayHello: Hello, world
      



      Quite logical.


      If instead of @ManagedBean I'm using @Named annotation (of course adding beans.xml in WEB-INF) I'm getting quite strange behavior.


      Loading the page




      SEVERE: **** MyBean constructor



      Submitting the form:




      SEVERE: **** MyBean constructor
      SEVERE: **** MyBean constructor
      SEVERE: **** MyBean constructor
      SEVERE: **** MyBean constructor
      SEVERE: ***** HELLO: Hello, world
      SEVERE: **** MyBean constructor
      SEVERE: *** sayHello: null
      SEVERE: **** MyBean constructor



      The bean is created 4 times, then the setter is invoked, after that again the bean is created and sayHello method is invoked and lastly the bean again is created (redirect?).


      If I add @Stateless annotation the behavior is changing a little (data is not lost)



      Loading the page




      SEVERE: **** MyBean constructor



      Submitting the form:





      SEVERE: **** MyBean constructor
      SEVERE: **** MyBean constructor
      SEVERE: **** MyBean constructor
      SEVERE: **** MyBean constructor
      SEVERE: ***** HELLO: Hello, world
      SEVERE: **** MyBean constructor
      SEVERE: *** sayHello: Hello, world
      SEVERE: **** MyBean constructor




      Why is the bean too often created?


      I'm using Glassfish v3 that comes with Netbeans 6.8.


      Regards,
      Vadim


        • 1. Re: Weld + JSF - strange behavior
          nickarls

          The only explanation that I can think of that you are using the JSF @RequestScoped and not the CDI one and CDI thinks it's dependent scoped...

          • 2. Re: Weld + JSF - strange behavior
            vadger

            I removed @RequestScoped but the behavior didn't change.

            • 3. Re: Weld + JSF - strange behavior
              nickarls

              Remove JSF @RequestScoped, put in CDI @RequestScoped

              • 4. Re: Weld + JSF - strange behavior
                vadger

                Thanks, does work as expected.


                Form submit




                SEVERE: **** MyBean cdi constructor
                SEVERE: ***** HELLO: Hello, world
                SEVERE: *** sayHello: Hello, world




                But if I use @Stateless instead of @RequestScoped:


                Form submit




                SEVERE: **** MyBean cdi stateless constructor
                SEVERE: **** MyBean cdi stateless constructor
                SEVERE: **** MyBean cdi stateless constructor
                SEVERE: **** MyBean cdi stateless constructor
                SEVERE: ***** HELLO: Hello, world
                SEVERE: **** MyBean cdi stateless constructor
                SEVERE: *** sayHello: Hello, world
                SEVERE: **** MyBean cdi stateless constructor




                Quite complicated form submit cycle.

                • 5. Re: Weld + JSF - strange behavior
                  nickarls

                  Well, if it's @Stateless, it isn't @RequestScoped and you end up with lots of calls...

                  • 6. Re: Weld + JSF - strange behavior
                    vadger

                    So from the performance point of view it's better not to use session beans if the needed functionality can be achieved without them.

                    • 7. Re: Weld + JSF - strange behavior
                      asookazian

                      Vadim Gerassimov wrote on Feb 10, 2010 13:27:


                      So from the performance point of view it's better not to use session beans if the needed functionality can be achieved without them.


                      Is this true (or only in the case of SLSB vs. JavaBean)?  I hope not...

                      • 8. Re: Weld + JSF - strange behavior
                        nickarls

                        Scope is more important from business logic point of view. Lot's of calls doesn't automatically mean bad performance too, you have to look at the big picture. You might want to start out with POJOs, but with EJB 3.1 the line is even further blurred.