Then can we extend that through code generation (i.e. switch statements
automatically generated specific to the particular EJB) for the mapping of the
appropriate EJB implemented method on the server? The generated code could be
created at deployment and would be something as following:
class ParticularEnterpriseBeanMapper extends EnterpriseBeanMethodMapper {
void callImplementationMethod(ParticularEnterpriseBean ejbImplementationInstance
, int methodIndex
, Object[] arguments
, /* potential objects for callback as
statically required */) {
// generic potential hookin calls
...
switch(methodIndex) {
case 1:
// method specific potential hookin calls
ejbImplementationInstance.method((ArgumentTypeOne)agruments[0]
,
(ArgumentTypeTwo)arguments[1]); // hardcoded linkage - reducing memory
and computation
...
}
...
// generic potential hookin calls
}
}
This could be coded to be thread safe and thus have both a lower computation
and memory overhead. We could even identify appropriate number ranges or
better a separate namespace for the different EJB methods (ie create, remove
and so forth).
