
| Key: |
GERONIMO-3452
|
| Type: |
Bug
|
| Status: |
Closed
|
| Resolution: |
Fixed
|
| Priority: |
Major
|
| Assignee: |
Unassigned
|
| Reporter: |
Aman Nanner
|
| Votes: |
0
|
| Watchers: |
0
|
|
If you were logged in you would be able to see more operations.
|
|
|
|
Environment:
|
Windows XP SP2
|
|
| Resolution Date: |
11/Oct/07 03:44 AM
|
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:
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
....
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.
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;
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.
|
|
Description
|
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:
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
....
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.
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;
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. |
Show » |
| No work has yet been logged on this issue.
|
|