JBossDeveloper

Hey Artem!

I'm glad we are making progress on this! We actually don't use EJB beans on my project (all our Seam beans are straight POJOs) so, this would explain why I have not experienced this issue.

Now the problem is I really don't have much experience (basically none) with how Seam works with EJB beans. So, I'm not really sure how to fix this issue.

So, when you normally instantiate a EJB bean what is the process? Maybe I just need to check for the @Stateful(less) annotation and instantiate the bean a different way?

I'm quite sure we can get it working I just need to understand how Seam and EJB beans fit together so that the code will work with them. :)

I'll try do some reading today and see if I can work out the problem. However, if you could post an example of how you would normally get a new EJB bean that would help as well. :)

Ok, just did a really quick google search and maybe the solution is simple. (Well, it's worth a try) :D

When you setup the SimpleForwardBackNavigation don't use the concreet class as the forward controller. User the Interface. It seems that EJB beans should be injected via their Local or Remote interface so... maybe this will work.

NOTE: The change in the generic type. It is the interface not the bean SFSB.

public void redirectToMiddleman() {

        NavigationUtils.setupNavigationAndForward(new AbstractSimpleForwardBackNavigation<MiddlemenGrid>(this
                .getConversationId())
                {

            @Override
            public void navigateForward(MiddlemenGrid controller) {
                controller.gotoMiddlemenGrid();
            }
        });
}

Of course doing this is going to run you into a whole new world of hurt right. Because, NavUtils expects the type to be an instance of AbstractSeamComponent. So...I'm guessing the right way to do this would be to make an SeamComponent interface and change NavUtils to rely on the type token being of that type. Then your interfaces could extend the SeamComponent interface and the AbstractSeamComponent superclass can be a default implementation of it.

In hindsight making NavigationManager dependent the abstract class was probably not my smartest move.

Hope this makes sense.

Artem have you had a chance to follow this up yet?