geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@coredevelopers.net>
Subject Re: [XML Parsing]
Date Fri, 05 Sep 2003 09:06:33 GMT
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).


Mime
View raw message