Re: [XML Parsing]

[Dain Sundstrom]

We don't need this.  We have a plain old dynamic proxy on the front end 
 with interceptors so it can be configured at runtime.  At the end of 
the interceptor chain we do need a reflection call, but that may be in 
another vm or a different class loader.

-dain
On Friday, September 5, 2003, at 03:38 AM, Sagenschneider, Daniel A 
wrote:

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).