geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevan Miller (JIRA)" <j...@apache.org>
Subject [jira] Closed: (GERONIMO-3452) Stateless Session EJBs cannot contain a remove() method
Date Thu, 11 Oct 2007 03:45:51 GMT

     [ https://issues.apache.org/jira/browse/GERONIMO-3452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Kevan Miller closed GERONIMO-3452.
----------------------------------

    Resolution: Fixed

I'm closing this as it appears to have been fixed in OpenEJB.

> Stateless Session EJBs cannot contain a remove() method
> -------------------------------------------------------
>
>                 Key: GERONIMO-3452
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-3452
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: OpenEJB
>    Affects Versions: 2.0.x, 2.1
>         Environment: Windows XP SP2
>            Reporter: Aman Nanner
>             Fix For: 2.0.2, 2.1
>
>
> We have a stateless session bean that contains a "remove(...)" method that takes in a
specific type of array as a parameter.  It seems that the EJBObjectProxyHandler confuses this
custom business method with the Entity Bean "remove(...)" method.  Once the logic sees that
a method called "remove" is being called, it assumes that it is a "special" method instead
of a business method.  Here is a stack trace up to the point where this piece of logic occurs:
> {panel}
> Thread [http-80-3] (Suspended)	
> 	StatelessEjbObjectHandler(EjbObjectProxyHandler)._invoke(Object, Class, Method, Object[])
line: 62	
> 	StatelessEjbObjectHandler(BaseEjbProxyHandler).invoke(Object, Method, Object[]) line:
320	
> 	Jdk13InvocationHandler.invoke(Object, Method, Object[]) line: 49	
> 	$Proxy173.remove(FcModelKey[]) line: not available	
> 	FCRemoveTest.test() line: 75	
> 	....
> {panel}
> The following code in the EjbObjectProxyHandler looks up the name of the method from
the dispatch table and sees that it is a "special" method name.  However, this really only
applies to Entity beans and not Session Beans.  Therefore, case 4 is executed, and the StatelessEjbObjectHandler.remove(...)
method is called, which is empty and only returns null.
> {code}
>             Integer operation = (Integer) dispatchTable.get(m.getName());
>             if (operation == null) {
>                 retValue = businessMethod(interfce, m, a, p);
>             } else {
>                 switch (operation.intValue()) {
>                     case 1:
>                         retValue = getHandle(m, a, p);
>                         break;
>                     case 2:
>                         retValue = getPrimaryKey(m, a, p);
>                         break;
>                     case 3:
>                         retValue = isIdentical(m, a, p);
>                         break;
>                     case 4:
>                         retValue = remove(interfce, m, a, p);
>                         break;
>                     case 5:
>                         retValue = getEJBHome(m, a, p);
>                         break;
>                     case 6:
>                         retValue = getEJBLocalHome(m, a, p);
>                         break;
>                     default:
>                         throw new RuntimeException("Inconsistent internal state");
>                 }
>             }
>             return retValue;
> {code}
> We have not run into this problem with JBoss and Weblogic.  I do not believe having a
method called "remove" on a Stateless Session bean is in violation of any spec, so this should
work.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message