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?
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!
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.
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.
Yes, this is a fixed bug.