11 Replies Latest reply on Oct 12, 2006 7:42 PM by jazir1979

    Understanding... Bijection

    johnurban

      I have read the seam_reference.pdf (pg 51-52) regarding Bijection.

      Just wanted to run a concept by and see if I am implementing the Seam framework correctly.

      - user logs in and gets authenticated via the login stateful session bean
      - I have a user object that is an attribute of the login stateful session bean
      - I will @Out that user object to the context by simply using the @Out
      - now, because the user has access, I will redirect output to a new screen that needs some attributes from the user object (ie.. companyID) to lookup some company info
      - I can now @In a varible called user in my welcome stateless session bean and I now automatically have the user object that I just stored in the login stateful session bean.

      Is my understand correct?

        • 1. Re: Understanding... Bijection
          gavin.king

          Exactly.

          • 2. Re: Understanding... Bijection
            gus888

            Hi Gavin,

            I have a quesion about the @In in the issues example. I found there are two ways for @In injection. One way is @In a SFSB into another SFSB to pass values and invoke the second SFSB, the other way is @In a SFSB into a SLSB, then pass values into a second SFSB and invoke the second one, the SLSB works a bridge. The two @In ways works as same? Thank you in advance.

            • 3. Re: Understanding... Bijection
              gavin.king

              Yes, of course, there is no difference.

              • 4. Re: Understanding... Bijection
                gus888

                Hi Gavin,
                At the beginning, I thought @In a SFSB into another SFSB will use more memory than the second one (SFSB -> SLSB -> SFSB). If it works same, I prefer the first (SFSB -> SFSB), since I don't need to create the extra SLSB. Is it correct? Thank you very much.

                • 5. Re: Understanding... Bijection
                  jazir1979


                  Hi all,

                  My user login process works exactly how "johnurban" described. I have a "desktop" SFSB that gets the "user" injected into it and returns a list of "modules and transactions" that a user can access for building up their menu structure.

                  However, I have a problem understanding how a user login session can end. Specifically:
                  1) User from the same browser session hits the login page and logs in with a different username
                  2) User goes to the desktop but still has the same "desktop" SFSB in their session, causing them to view the wrong information.

                  I tried to solve this by destroying the session context upon login (before putting the "user" into the session context). However, this totally removes the "desktop" SFSB and causes errors.

                  Anybody know how I should be doing this?

                  cheers,
                  Daniel.

                  • 6. Re: Understanding... Bijection
                    mnrz

                    Hi

                    Do we think of @Out, somehow as setAttribute("variable_name",someValue) method of the session? and also, @In as a getAttribute("variable_name")

                    Am I right?

                    • 7. Re: Understanding... Bijection
                      gavin.king

                      yes

                      • 8. Re: Understanding... Bijection
                        jazir1979

                        Any suggestions on my problem above?

                        thanks!
                        Daniel.

                        • 9. Re: Understanding... Bijection

                          Regarding the commet about set/get analogy, how does this feel then?

                          Replace @In with @Get and @Out with @Set to get the analogy more correct..

                          @Get(scope=Session)
                          User user;
                          
                          @Set
                          List <Project> projects;
                          


                          etc...




                          • 10. Re: Understanding... Bijection
                            jazir1979

                            More info on MY problem:

                            I believe the booking example suffers from this same flaw, because a user can login again with a different username, without being forced to logout.

                            The session is only invalidated upon logout...

                            Steps:
                            Log in as user 1, make a booking
                            Go to home.seam and log in as user 2 from same browser session, you will see the booking.

                            • 11. Re: Understanding... Bijection
                              jazir1979

                              NOTE: I fixed this in my app by sending users that are already logged in to their desktop page if they directly request the login page. This will FORCE them to logout and invalidate the session before loggin in again.

                              Might be nice to add that to the booking example

                              It was easy for me because I already had a "verifyLoggedIn" action which applies to every request, and I was able to handle the logic there.

                              If there is a more logical way I should have done this, let me know :)

                              Dan.