6 Replies Latest reply on Jul 9, 2006 11:57 PM by Gavin King

    @Unwrap bug?

    Peter Brewer Novice

      I'm using the @Unwrap to return the logged in user entity (to avoid any lazy initialization issues). However, when a user is not logged in I want the @Unwrap method to return null, which I do, and seam ignores it.

      Looking at the SeamVariableResolver class (below) line 44 correctly unwraps the component to null. However, the variable resolver (line 46) interprets a null value as the component not existing and then loads the seam component as a managed bean (line 45).

      Am I doing something wrong or is this a bug?

      Thanks in advance, Peter.

      39 public Object resolveVariable(FacesContext facesContext, String name) throws EvaluationException
      40 {
      41 name = name.replace('$', '.');
      42
      43 log.debug("resolving name: " + name);
      44 Object component = Component.getInstance(name, true);
      45 Object managedBean = jsfVariableResolver.resolveVariable(facesContext, name);
      46 if (component==null)
      47 {
      48 if (managedBean==null)
      49 {
      50 log.debug("could not resolve name");
      51 return null;
      52 }
      53 else {
      54 log.debug("resolved name to managed bean");
      55 return managedBean;
      56 }
      57 }
      58 else
      59 {
      60 //TODO: fix and re-enable
      61 /*if ( managedBean!=null && managedBean!=component )
      62 {
      63 log.warn("Seam component hides managed bean with same name");
      64 }*/
      65 log.debug("resolved name to seam component");
      66 return component;
      67 }
      68 }
      
      


        • 1. Re: @Unwrap bug?
          Jim Hazen Expert

          This looks right to me. Seam delegates variable resolution to JSF if the component can't be found in your Seam context. By returning null from your @Unwrap method you're telling Seam that a component couldn't be created and that it should delegate to JSF. It does this and delegates to JSF, which will either find a registered managed bean or return null.

          What did you expect to happen? What do you want to happen?

          • 2. Re: @Unwrap bug?
            Peter Brewer Novice

            I would have thought returning null from the @Unwrap method would set the component to be null, with no further action. Instead it treats null as though the unwrap method was never called.

            I thought of using an token null value e.g. if @Unwrap returns something like Component.NULL_COMPONENT then return null otherwise if @Unwrap returns null then continue resolving the variable.

            However, it got me to thinking that I'm kind of defeating the point of contexts - I can set the value in the context and remove it if it shouldn't be there.

            Thanks for the prompt reply and for making me think twice about what I'm doing!

            • 4. Re: @Unwrap bug?
              Jim Hazen Expert

              Seam doesn't inject nulls. It either creates a new component or throws an exception. So even with JBSEAM-283, I don't think you'll get what you want.

              Most security frameworks that deal with anonymous users will create a valid user object with Anonymous role permissions. This makes your business logic easier as well. Anonymous is a first class role that you can manage along with your other roles. Once a user authenticates, replace the anon user with the authenticated user object.

              This way your @Unwrap will always return some object, Seam is much happier and you have fewer null checks. I think this is a better way all around, but again I'm not 100% sure what your objectives are.

              • 5. Re: @Unwrap bug?
                Jim Hazen Expert

                Looks like I was wrong, after looking at the code it looks like after JBSEAM-283 is fixed you may be able to inject your null value if @In(required=false). Still, look into the anonymous user concept, I think you'll get more mileage in the long run.

                • 6. Re: @Unwrap bug?
                  Gavin King Master

                  Yes, this is a fixed bug.