6 Replies Latest reply on Jul 9, 2006 11:57 PM by gavin.king

    @Unwrap bug?

    pbrewer_uk

      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?

          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?
            pbrewer_uk

            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!

            • 3. Re: @Unwrap bug?
              pmuir
              • 4. Re: @Unwrap bug?

                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?

                  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

                    Yes, this is a fixed bug.