4

I have already one session scoped CDI bean, which keeps currently logged in user data. Now, from another, request scoped I would like to access to this bean to get some data. I have some operation to do, which is dependent on user login. That's the only information I need.

How to access it?

AccountBean.java:

@Named("accountBean")
@SessionScoped
public class AccountBean implements Serializable {
    private static final long serialVersionUID = 16472027766900196L;

    @Inject
    AccountService accountService;

    private String login;
    private String password;
    // getters and setters ommited
}

Part of login.xhtml:

<h:form>
    <h:panelGrid columns="2">
        #{msgs.loginPrompt}
        <h:inputText id="login" value="#{accountBean.login}" />
        #{msgs.passwordPrompt}
        <h:inputSecret id="password" value="#{accountBean.password}" />
        <h:commandButton value="#{msgs.loginButtonText}"
            action="#{accountBean.login}" />
    </h:panelGrid>
</h:form>

SearchBean.java:

@Named("searchBean")
@RequestScoped
public class SearchBean {
        @Inject AccountBean accountBean;
            // some other stuff
}
rivasket
  • 377
  • 2
  • 6
  • 18
  • Hi @rivasket! Did you solve this case? I am having exact this trouble right now! Would be nice if you could tell me that. – Socrates Dec 13 '14 at 11:11

1 Answers1

6

Just @Inject it.

@Inject
private Bean bean;

Note that this isn't available in the constructor of the receiving bean (it's not possible to inject something in an unconstructed instance, you see). The earliest access point is a @PostConstruct method.

@PostConstruct
public void init() {
    bean.doSomething();
}
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • I have already tried this, but without success. When I looked into injected AccountBean I saw nulls on every its fields. I was checking it inside method, which is called by h:commandButton. Can it be the reason of this? Is it still not constructed yet? – rivasket Dec 14 '11 at 22:35
  • Apparently you've set login data on a different or an unmanaged instance. Hard to tell without seeing the code how you've set the login data. – BalusC Dec 14 '11 at 23:24
  • I updated my question. I would like to get logged user login inside SearchBean. – rivasket Dec 14 '11 at 23:47
  • 1
    The code given so far looks fine. Is the `#{accountBean.login}` method really ever invoked? From what package is the `@SessionScoped` annotation? This problem is explainable if it's incorrectly from the `javax.faces.bean` package instead of `javax.enterprise.context`. – BalusC Dec 14 '11 at 23:50
  • It is javax.enterprise.context.SessionScoped. Method login() is invoked. I can log in successfully. It gives access to further parts of the site. I have menu with some subpages and on one of them I need to provide some data based on login. That is my aim. – rivasket Dec 14 '11 at 23:55
  • So the `#{accountBean}` is available in all other pages in the same session? – BalusC Dec 15 '11 at 00:01
  • Should be. I don't know how to check it. – rivasket Dec 15 '11 at 00:10
  • For testing, just print `#{accountBean}` or `#{accountBean.login}`. How else are you checking the logged-in user in all your (restricted) pages by the way? – BalusC Dec 15 '11 at 00:14
  • I've just checked. When I print using `` values from `#{accountBean}` are ok. So the only thing I need now is just to have access to it from bean code. So far I am not checking, because it's first page needing such data which I write. – rivasket Dec 15 '11 at 00:22
  • Also if you refresh/revisit the page at later moment in the same session? Is it exactly the same instance with the right `login` property value? Well, sorry, I don't see why you wouldn't get the same instance in your `SearchBean`. – BalusC Dec 15 '11 at 00:31
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/5860/discussion-between-rivasket-and-balusc) – rivasket Dec 15 '11 at 00:36
  • If for someone the solution which was given by @BalusC doesn't work, [here](http://stackoverflow.com/questions/36115190/get-access-to-cdi-bean-from-another-cdi-bean) is the probable cause of the issue and the solution of the issue as well. – Robert Mar 26 '16 at 16:13