7
votes

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?

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

2 Answers

8
votes

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).

2
votes

@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.