7

I'm working on a Java webapp trying to combine the following technologies:

  • Java EE 6
  • CDI
  • JSF 2
  • EJB 3.1
  • Spring Security

I provide CDI-based backing beans (@ViewScoped, @Named) for my JSF pages.

I use @Stateless EJB beans for the actual work to be done.

I only need few session information like jSessionCookie (managed by container), internal username and some other internal IDs. Now, I wonder where to put this session information so that I can access it in the backing beans for JSF, but also provide it to the stateless EJBs? Should I use a @Stateful EJB session bean or should I create CDI-based POJO with @SessionScoped and @Named?

Are there any best practices?

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
Sebi
  • 8,323
  • 6
  • 48
  • 76
  • 2
    Not an authoritative answer, but in my case I keep it mostly in a SessionScoped JSF backing bean. The EJBs hardly use that information, and when they use it it is more flexible (v.g., in one case one of the criteria of search is user; some users can only see its items -their id is passed as part of the filter- and others can see other users items -no id is passed as part of the filter-) – SJuan76 Aug 21 '12 at 19:13

2 Answers2

8

For your particular use case, a stateful session bean would not be a good choice.

Do note that contrary to what people may claim, stateful session beans are surely not something you should generally avoid. However, they are for advanced use cases, for instance when dealing with JPA's extended persistence context.

The reason why stateful session beans would not work here, is that they are not automatically associated with the HTTP session, which seems to be your prime concern. You could add the @SessionScoped annotation to them, but then you could just as well use a regular managed bean. You would not use any of the particular features of a SFSB.

See alo:

You can inject your stateless EJBs with a session scoped CDI bean, but you have to realize that within the same application your EJB bean would be dependent on the HTTP session then (something you sometimes want to avoid, e.g. if your bean has to be called from other contexts as well).

Community
  • 1
  • 1
Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
  • Ok, just to make sure I understood it correctly. You would also say that I should use a CDI SessionScoped bean to hold the user information, but not go for a Stateful EJB? – Sebi Aug 22 '12 at 18:43
  • Yes, for this particular use case and with the information you have provided us, I don't see a need for a Stateful EJB. The CDI SessionScoped bean can be injected into both other CDI beans as well as in (Stateless) EJB beans. – Arjan Tijms Aug 22 '12 at 20:57
  • Ok, thanks, just wanted to make sure I have not misread your answer! – Sebi Aug 22 '12 at 21:19
2

@Stateful EJB is something I'd try to stay away from. I believe behavior and state are things that should not be mixed.

I would also go for SJuan76's answer and use SessionScoped JSF backing bean.

Peter Butkovic
  • 11,143
  • 10
  • 57
  • 81
  • 2
    I would not agree that mixing state and behavior is always a bad thing. Consider what is the essence of OOP: holding state and behavior in one place (in object). – Raigedas Aug 05 '14 at 16:27