1 Reply Latest reply on Jun 25, 2008 2:22 PM by Benjamin Graf

    Statful Bean and Interface

    Tomas Cerny Novice

      I have a question about current state of session beans in Seam 2.0.3.CR1


      • Does stateless bean have to implement interface that has @Local annotation?

      1. Example DVD store ShoppingCart does not have @Local

      2. Example SeamBay AuctionAction does not have an interface

      • When I am supposet to you it? Isn't it EJB requirement?


      • When to implement serializable?

      1. Example SeamBay AuctionAction does

      2. Example DVD store EditCustomerAction does not

      • I guess this should be implemented everytime in session bean (and attached objects)?


      • Why I ask?

      1. Time to time I get serialization exception connected with EJBclass eaeea-23ea.... not found.

      • This might be because I might call new XXXAction() instead of calling Component.getInstance() (I guess you create a proxy?)

      1. @Remove annotation has problems sometimes too

      I just want to clarify these things because I am completely sure about them. I would also put this in the documentation I have tried to find it there but unsuccessfully.

      Thank you Tomas

        • 1. Re: Statful Bean and Interface
          Benjamin Graf Novice

          Here some short answers for your questions:


          Does stateless bean have to implement interface that has @Local annotation?

          Yes, of course. Since your are using EJB 3.0 you need for every SLSB and SFSB a @Local or @Remote annotated interface. This will change in the future with EJB 3.1 and so called LocalBeans.

          If @Local is missed in the seam examples this must be a bug!


          When to implement serializable?

          The Serializeable Interface should be implemented for every SESSION, CONVERSTAION and PAGE scoped seam component that is not a EJB. EJBs are serializable by defaults since they are proxied. But you'll get warnings from the seam core!


          Why I ask?

          Hard to answer. But I think that should be a problem between conversation handling and stateful bean session handling. The EJB seems to get removed earlier than the conversation. That causes that the conversation tries to work on a bean that doesn't exist anymore.

          Hope that helps!