I have defined a session bean base class. This class is abstract and contains protected final methods. A session implementation class extends the abstract class and defines additional methods. During deployment, Glassfish 3.1.2 server generates an exception stating that method is overridden.
abstract class AbstractSessionBean {
@PersistenceContext(unitName="primary")
private EntityManager em;
protected final EntityManager getEntityManager() {
return em;
}
}
@Startup
@Stateless
class RegistrationSessionBean extends AbstractSessionBean {
public void loadRegistration() {
...
}
}
During deployment, the glassfish server throws an exception. If I make methods of AbstractSessionBean non-final, deployment is successful.
Does this mean that session bean cannot have final methods? or is this behavior specific to Glassfish 3.1.2 only.
Exception message is:
[#|2013-08-26T17:45:48.542+0530|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=47;_ThreadName=Thread-2;|Exception while loading the app : EJB Container initialization error
java.lang.RuntimeException: Could not invoke defineClass!
at com.sun.ejb.containers.EjbOptionalIntfGenerator.makeClass(EjbOptionalIntfGenerator.java:448)
at com.sun.ejb.containers.EjbOptionalIntfGenerator.access$200(EjbOptionalIntfGenerator.java:64)
at com.sun.ejb.containers.EjbOptionalIntfGenerator$1.run(EjbOptionalIntfGenerator.java:99)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.ejb.containers.EjbOptionalIntfGenerator.loadClass(EjbOptionalIntfGenerator.java:96)
at com.sun.ejb.containers.BaseContainer.instantiateOptionalEJBLocalBusinessObjectImpl(BaseContainer.java:3886)
at com.sun.ejb.containers.StatelessSessionContainer.initializeHome(StatelessSessionContainer.java:253)
at com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:167)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:230)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:305)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:108)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:264)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:460)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:389)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:461)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:724)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.sun.ejb.containers.EjbOptionalIntfGenerator.makeClass(EjbOptionalIntfGenerator.java:445)
... 41 more
Caused by: java.lang.VerifyError: class org.bean.test.persistence.util.__EJB31_Generated__RegistrationSessionBean__Intf____Bean__ overrides final method getContext.()Ljavax/ejb/SessionContext;
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:792)
... 45 more
|#]
The short answer is "yes", but the long answer is "yes in general, but no when using no-interface view". The restriction for no-interface view comes indirectly from section 3.4.4 of the EJB 3.2 specification:
Only public methods of the bean class and of any superclasses except java.lang.Object may be invoked through the no-interface view. Attempted invocations of methods with any other access modifiers via the no-interface view reference must result in the javax.ejb.EJBException.
When generating a no-interface view proxy, the EJB container must create a subclass of the EJB class and override all public methods to provide proxying behavior. However, the second sentence from the specification quote above implies that all remaining non-private methods must also be overridden in order to throw an unconditional EJBException. That said, the error message from the application server could be better.
来源：https://stackoverflow.com/questions/18437966/can-a-stateless-session-bean-have-protected-final-method