JBoss 5 - Deciphering Stack Trace

In my deployment on JBoss 5.1.0GA with JavaEE-5 I have beans of the general form

public interface Foo {
   void baz ();
}

@Stateless
public class FooBean implements Foo {
   void baz() { // ...
   }
}

I have assumed that this is the same as if I have explicitly annotated the Foo interface with @Local. From seeing a stack trace in the code I think that it is actually using a remote interface, whereas I want all of my beans to be local.

Do I need to explicitly annotate interfaces as Local or is there some default? Finding documentation on this is proving challenging so any links to relevant documentation would be greatly appreciated.

(edit added suspicious stack trace)

The stack trace I'm getting looks like this. The suspicious line is "$Proxy638". FooBean is annotated as descrbied as above, and Client and Manager are both POJO's (e.g. completely unannotated with any Java EE related items). This call is being processed by an Message-Driven bean if that is helpful. I can see that the exception is one of mine ("My error message goes here!" is the message I want to real stack trace of).开发者_运维技巧

2011-01-10 11:15:06,428 ERROR [org.jboss.resource.adapter.jms.inflow.JmsServerSession](WorkManager(2)-11) Unexpected error delivering message delegator->JBossMessage[21211678385963013]:PERSISTENT, deliveryId=5
javax.ejb.EJBTransactionRolledbackException: My error message goes here!
  at org.jboss.ejb3.tx.Ejb3TxPolicy.handleInCallerTx(Ejb3TxPolicy.java:115)
  at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:130)
  at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
  at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
  at org.jboss.ejb3.security.RunAsSecurityInterceptorv2.invoke(RunAsSecurityInterceptorv2.java:94)
  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
  at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:201)
  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
  at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
  at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
  at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
  at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
  at org.jboss.ejb3.session.SessionSpecContainer.invoke(SessionSpecContainer.java:182)
  at org.jboss.ejb3.session.SessionSpecContainer.invoke(SessionSpecContainer.java:240)
  at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:188)
  at $Proxy638.generateWidget(Unknown Source)
  at com.foobar.managers.Client.writeBananaToStream(Client.java:456)
  at com.foobar.managers.Client.write(Client.java:123)
  at com.foobar.managers.Manager.persist(Manager.java:275)
  at com.foobar.FooBean.doSomething(FooBean.java:1243)

Note that I've had to anonymize the code so any mismatching things to do with class names are almost certainly typos!

This is a local call.

With JBoss AS, if you omit the @Local annotation you get local interface semantics. I'm not 100% sure whether this is spec compliant, so better define it explicitly by putting that annotation there.

The $Proxy638 that you see is at the heart of how EJB and similar component models work. It's the reason why you can't use the new operator to create an EJB, but can only look one up via JNDI of have one injected via the @EJB or @Inject annotation.

You never get the object directly, but instead you get a proxy, also known as a stub. In EJB terms you are said to have a Client view on the actual bean. This proxy allows the EJB container to do its AOP magic, like starting a transaction transparently and committing or rollbacking it.