Am I missing something obvious with the JSF example in docs?

[hirowla.ian.rowlands.three.com.au]

I'm talking about the User/Credentials JSf example in Chapter 3.

When I try to do something like that, I get a Credentials object injected but the username and password are both null. I have debugged and seen the setUsername and setPassword methods called with the correct values.

But wouldn't the injected Credentials object simply be blank, or disappear out of scope as it is a RequestScoped object? The Login object would then keep it, as it is a SessionScoped object and it is already been injected in.

Am I missing something obvious here?

Thanks,

Ian

[nickarls]

You @Inject the request scoped Credentials bean into your session scoped Login bean through a proxy. A proxy is a placeholder, a window into that data how it looks at the time of the invocation of a method in login.

You only the need the data in Credentials when you attempt a login (and have filled in the un/pw). If you would look at the credentials at another point (another view where the un/pw wouldn't have been filled in), you would have an emptyish Credentials instance

[hirowla.ian.rowlands.three.com.au]

But doesn't the example extract (or hint at) the username and password from the credentials object as the button has been pressed (which calls the login bean)? At that point, the credentials members should be populated and hence accessible.

Or am I misunderstanding the example and what it is trying to illustrate? If you can't get the values from Credentials in the login method at that point at which it is called (which is when the button is pressed), then the example has no practical use apart from showing something can be injected - which can be seen with a blank object.

Unless I'm missing something with your proxy, and my misunderstanding of the example. What else would be needed in that example to get the username and password from Credentials?

[nickarls]

Yes, when the submit button is pressed the fields should be populated if they are bound correctly. Tried doing a System.out.println on the getUsername() etc since looking in the face of a proxy with a debugger might lead to different results(?) If it still is null, you have to start looking at config errors (presence of faces-config.xml etc)

[hirowla.ian.rowlands.three.com.au]

I did a System.out.println and it is null.

I put a breakpoint on the setter in Credentials, and it is being called (assuming it is valid of course) with the value I entered. Yet it is set to null when referenced through the injected variable. Any ideas?

Just to confirm my understanding, only proxys are injected that look like the object. When you access them, it refers the request to the real object?

[nickarls]

Proxies are used for normal scoped beans, yes.

Are you running the login example from Weld or are you building your own?

[hirowla.ian.rowlands.three.com.au]

I was building my own.

I've actually just solved it with some of your hints. I was using the javax.faces.bean.RequestScoped object, and not the javax.enterprise.context.RequestScoped object. Combining that with expecting a proxy rather than a real object means I am now getting the values transmitted across. Very subtle, but it is working. What are the odds that others will fall over that in time!!!

Thanks for your help,

Ian

[nickarls]

Yup, the whole JSF bean/scope model is a bit redundant when running CDI...

[hirowla.ian.rowlands.three.com.au]

It's more that it was not intended - probably related to my earlier problem with JBoss 6, and I got the wrong import.

I bet lots of people using Eclipse will choose the wrong import by accident and wonder why it isn't working. Well, it will make me feel better if they do!

[dan.j.allen]

My advice is to go into Eclipse and ban the javax.faces.bean from being used. That will solve your problem permanently. I know it is not ideal, but it's just some dust left behind than hopefully we can get cleaned up in the next release of Java EE.

[asookazian]

If 299 had used javax.enterprise.context.RequestScope rather than javax.enterprise.context.RequestScoped that would have solved the problem, no?

Current Seam equivalent: @Scope(ScopeType.REQUEST)

not: @Scoped(ScopeType.REQUEST)

minor problem I know but a lot of folks will hit this...