Avoid Excessive Bijection – How can a Stateless session bean have state information

[johnnyren]

In Michael Yuan's book "JBoss Seam" section 2.4.5 he recommends that you avoid using Excessive Bijection Bijection.   However, “ManagerAction” is a stateless session bean. How can Seam guarantee the same instance of bean is used for displaying the “fans”?  Are session beans managed by Seam or by EJB container?

@Stateless
@Name("manager")
public class ManagerAction implements Manager {

  private Person person;
  public Person getPerson () {return person;}
  public void setPerson (Person person) {
    this.person = person;
  }

  private List <Person> fans;
  public List<Person> getFans () {return fans;}

...  ...
}

Then, on the web page, we reference the properties as follows.
<h:form>

Please enter your name:<br/>

<h:inputText value="#{manager.person.name}"/>
<br/>
<h:commandButton type="submit" value="Say Hello"
                 action="#{manager.sayHello}"/>
</h:form>
... ...
<h:dataTable value="#{manager.fans}" var="fan">
  <h:column>
    <h:outputText value="#{fan.name}"/>
  </h:column>
</h:dataTable>

[admin.admin.email.tld]

The following is from the upcoming Seam in Action book:

Seam can derive a component from an EJB 3 session bean—herein referred to as a Seam session bean component. There is nothing proprietary about these components. The EJB3 container does most of the work of managing them. Seam only steps in to bind the component to a context variable and apply its own set of interceptors around method invocations.

[dan.j.allen]

Couldn't have said it better myself. ;)

As for the example, I think that is an error. A stateless session bean is not stored in a Seam context variable because it is, well, stateless. It is refetched from the EJB container on each method call. Stateless session beans aren't really that useful in Seam, other than doing what I call one shot processing. This should really be a stateful session bean, which would be stored in the conversation scope (the conversation lasts for a single request unless the conversation is made long-running).

[admin.admin.email.tld]

well according to section 20.2.1 of Seam 2.0.1.GA ref pdf, when you develop a web service in a Seam app, you should use a SLSB or POJO as a facade to the conversation-scoped component which is a POJO (can it be a SFSB??)

but most of the action beans (backing beans for the JSF EL method calls) are SFSB's...

In that regard, Seam is very different from traditional J2EE technologies like Struts/JSP/Servlet/EJB2.x b/c SFSB's were frowned upon back then.  Apparently, for HA prod envmts, JBoss' clustering technologies (JCache and JGroups) have improved the performance of apps making heavy use of SFSB's.

I wonder how the latest versions of Spring/Hibernate apps manage conversation context in their use cases?  old skool HTTP Session mgmt?

or have they begun to integrate Seam conversation components into their projects now???

[dan.j.allen]

Yeah, I'm not saying never use SLSB, just that when you use it in the web and expect it to store state, then you really need to be using a SFSB (or JavaBean). A web-service passthrough would qualify as one-shot processing.

I know that Spring is trying to move its users over the Spring Web Flow, which is a similar concept to Seam's conversations except that it is a state machine, whereas Seam conversations are ad-hoc (Seam of course supports pageflows as well). The industry is definitely moving away from using the HTTP Session directly (except for obvious uses) and choosing an abstraction layer instead that does more fine-grained state management.

Any Spring/Hibernate user's out there that want to share stories?

[johnnyren]

Dan,

Thanks a lot for your help. That makes sense.

[jacob.orshalick]

I've actually been meaning to put together a blog posting on a comparison between the two as I am putting the final touches on an SWF project, but my time has been very thin lately.  I'm sure you can understand Dan knowing first-hand ;)

Essentially the biggest problem I have with Spring Web Flow is XML configuration.  I am not a fan of extensive XML configuration. In fact, this was one of the major issues I always had with Spring. I have been very pleased with the improvements Spring has made in this department with their annotational support. The built-in stereotypes (i.e. @Component, @Repository, and @Service) along with the @Autowired support greatly simplify configuration of Spring beans. Yet, it seems that SWF really hasn't jumped on the annotation bandwagon. So much of the configuration and implementation is done through the flow definition that I often feel like I'm coding in XML.

The missing piece is the use of contextual components that Seam provides, essentially the concept of bijection. Spring beans are stateless (and singleton) in nature requiring a reminder of state on each invocation to avoid scope impedence.  This may not seem overwhelming initially, but as the number of invocations grows in your flow configuration this constant reminding of state can lead to difficulties in refactoring, tight coupling, and the feeling of coding in XML.

Another issue is the limitations at the moment with PersistenceContext scoping.  I believe the intent of SWF is to eventually provide the same scoping abilities as Seam (see 2.1 support for ViewState PersistenceContext and Conversation-scoped PersistenceContext) avoiding LIEs altogether, but there are some limitations at the moment.  Flow scoping of the PersistenceContext is the only available scope and sub-flows share the same PC.  Since everything is a flow in SWF, this can lead to some hairy situations (although there are ways to work around the issue).

Anyways, thought others might find the experiences interesting.  I would be happy to discuss further if anyone has any additional insight.

[dan.j.allen]

Great feedback Jacob. And trust me, I completely understand the no time thing. As the old saying goes, my friends went to the beach and all I got was this loosy t-shirt.

I definitely want to talk to you more about SWF. There seems to be a lot of static between Seam and SWF and we need to get down to the facts. I completely agree with your three main statements, which were

• Spring is still knee deep in XML, even with annotation support (actually, now it just looks confused)


• Spring is still fundamentally stateless, even with autoproxy hacks


• SWF still doesn't quite get the extended PC right

I like Spring, I do. Otherwise, I wouldn't have done a chapter on it and a talk on mixing Spring and Seam. But Spring has some issues, and as sad as it is to say, we are using Spring for its labor, not for its preachings.

[jacob.orshalick]

I like Spring, I do. Otherwise, I wouldn't have done a chapter on it and a talk on mixing Spring and Seam.

Don't get me wrong, I'm a fan of Spring and everything Rod Johnson has done for simplifying Java EE development.  I wouldn't sign on for projects using Spring otherwise.   Then again, I didn't decide to write a full chapter on it as you did, I chose Groovy instead as I like to stay bleeding edge ;)

Spring has played a huge part in the evolution of Java EE (and keeping Java mainstream for that matter), but in order to remain cutting edge there are certainly areas where it now needs to improve.  Other frameworks (Seam and Guice especially) have now evolved Java EE further and Spring will have to play catch up.

I definitely want to talk to you more about SWF. There seems to be a lot of static between Seam and SWF and we need to get down to the facts.

Perhaps we could collaborate on something.  Ping me at my email and we can discuss further:  jacob (AT) solutionsfit.com