[jboss-jira] [JBoss JIRA] Updated: (JBAS-6609) JBAS 5 allows create methods for EJB2x home interface client view with the name 'create' only

JBAS 5 allows create methods for EJB2x home interface client view with the name 'create' only --------------------------------------------------------------------------------------------- Key: JBAS-6609 URL: https://jira.jboss.org/jira/browse/JBAS-6609 Project: JBoss Application Server Issue Type: Bug Security Level: Public(Everyone can see) Components: EJB3 Affects Versions: JBossAS-5.0.1.GA Environment: WindowsXP SP2 Reporter: Szymon Dembek Assignee: Carlo de Wolf Priority: Minor Fix For: JBossAS-5.1.0.CR1 According to EJB3 spec, home/local home interfaces for ejb3 stateful session bean (adopted to ejb2x client view) can have multiple create<METHOD> methods. The requirement is that their names begin with "create". Each of this methods must have corresponding @Init method or ejbCreate<METHOD> methods in the bean class. When I was trying to run a bean with many create methods in its local home interface under JBOSS 5.0.1, I got an exception: "IllegalArgumentException - illegal home method ..." (followed by the signature of the method) thrown from the org.jboss.ejb3.session.SessionSpecContainer class. The create method's signature in local home interface is: public TestSF2xLocal createA() throws CreateException; where TestSF2xLocal is the bean's local component interface for 2.x client view. The bean class has a @Init method defined in it: @Init("createA") public void doInitA() ... I looked into the source code for ejb3 module a bit and found out, that the invokeHomeMethod method of the SessionSpecContainer class compares the name of the method being called to "create": if (method.getName().equals(Ejb2xMethodNames.METHOD_NAME_HOME_CREATE)) { return this.invokeHomeCreate(method, args); } As this comparison fails in my case, an exception is thrown: else { throw new IllegalArgumentException("illegal home method " + method); } The very same bean works fine with Glassfish 2. I'd suggest that JBoss behaviour is against the spec in this case.