You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Paul Hammant <Pa...@yahoo.com> on 2002/03/07 10:43:39 UTC
Re: [ARMI] ProxyGenrator
Juozas,
>Hi,
>1.We have the same code in ARMI and in Simplestore for proxy generation,
>("org.apache.commons.simplestore.tools.*")
>It depends only on BCEL. Is it possible to move this code from SimpleStore
>to more generic project ? I see BeanUtils is about reflection, May be BCEL
>itself is the best place for this kind of code.
>
Our proxys are different really. Decompile a generated proxy for ...
interface Fred {
int sayHelloFred(String s);
}
..from both Simplestore and AltRMI to understand.
>2. I don't understand ProxyGenerator interface in ARMI, It will be very good if
>somebody will write some coments, for this interface, Generator for ARMI Proxy
>is ready we need to add implementation for ProxyGenerator interface.
>I don't understand meaning of "additionalFacede" ,"classesOrInterfaces" and "DeferredClass".
>
I have just replied to this in the EOB list, I'll repeat in summary form
Ignore DeferredClasses for BCEL.
ClassesOrInterfaces and AdditionalFacades are to all intents and
purposes the same. They are pass-by-reference proxies.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [ARMI] ProxyGenrator
Posted by Juozas Baliuka <ba...@mwm.lt>.
I thin we must try "standard" Proxy first, BCEL must be the last possible
solution,
This code is very dangerous and error phone.
> Juozas,
>
> Thanks for your continued thinking on this dude.
>
> >Hi,
> >ProxyGeneratorImpl and ClientClassAltrmiFactory use diferent ClassLoaders
.
> >We need to call "generate" in ClientClassAltrmiFactory not in ants task.
> >I see BCEL is not very useful for ARMI if we are going to support only
> >interfaces.
> >
> <skip/>
>
> I don't think that java.lang.reflect.Proxy is good enough for us. Why?
> 1) A scripting env like the excellent BeanShell cannot query the exposed
> methods and invoke them.
It must work, because java.lang.reflect.Proxy generates byte code for
interface implementation,
and they are visible for reflection, Enhancer in simplestore implemented in
the same way, but has
more features. This problem is becouse diferent ClassLoades are used.
> 2) As we are not delegating immediately to a ral impl, we cannot have a
> single catch/throws block that suits all scenarios.
I am sure it is possible to implement.
If ARMI is not going to support Class types BCEL and java.lang.reflect.Proxy
will do the same.
Trust me I tested both.
>
> If it were not for that it would be a good solution.
>
> BCEL almost certainly is (one of) the right tools to dynamic make
> proxies, the problem is it is Brain-Surgery to use. Anyone that can
> actually use it to make a proxy of the type we find easy via our javac
> route would be a god.
>
> I dream of a bytecode generator that allows me some natural java-like
> construction :
Yes, I thinking about this. It is trivial to implement, but it eats a lot of
time for testing.
> JMethod ap = new JMethod("actionPerformed");
> ap.addArg("event", ActionEvent.class);
> ap.setVoidReturn(); // maybe this a default.
>
> InstructionList il = ap.getInstructionList();
> Var txtVar = new NewVar(String,"txt");
> ir.add(new JInstruction(txtVar, "event","toString"));
> ir.add(new JInstruction(System.out, "println", txtVar));
> ap.generate();
>
> Regards,
>
> - Paul
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [ARMI] ProxyGenrator
Posted by Paul Hammant <Pa...@yahoo.com>.
Juozas,
Thanks for your continued thinking on this dude.
>Hi,
>ProxyGeneratorImpl and ClientClassAltrmiFactory use diferent ClassLoaders .
>We need to call "generate" in ClientClassAltrmiFactory not in ants task.
>I see BCEL is not very useful for ARMI if we are going to support only
>interfaces.
>
<skip/>
I don't think that java.lang.reflect.Proxy is good enough for us. Why?
1) A scripting env like the excellent BeanShell cannot query the exposed
methods and invoke them.
2) As we are not delegating immediately to a ral impl, we cannot have a
single catch/throws block that suits all scenarios.
If it were not for that it would be a good solution.
BCEL almost certainly is (one of) the right tools to dynamic make
proxies, the problem is it is Brain-Surgery to use. Anyone that can
actually use it to make a proxy of the type we find easy via our javac
route would be a god.
I dream of a bytecode generator that allows me some natural java-like
construction :
JMethod ap = new JMethod("actionPerformed");
ap.addArg("event", ActionEvent.class);
ap.setVoidReturn(); // maybe this a default.
InstructionList il = ap.getInstructionList();
Var txtVar = new NewVar(String,"txt");
ir.add(new JInstruction(txtVar, "event","toString"));
ir.add(new JInstruction(System.out, "println", txtVar));
ap.generate();
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [ARMI] ProxyGenrator
Posted by Juozas Baliuka <ba...@centras.lt>.
Hi,
ProxyGeneratorImpl and ClientClassAltrmiFactory use diferent ClassLoaders .
We need to call "generate" in ClientClassAltrmiFactory not in ants task.
I see BCEL is not very useful for ARMI if we are going to support only
interfaces.
java.lang.reflect.Proxy does this :
Object invoke(Object obj,Method method, Object[] args){
try{
StringBuffer sb = new
StringBuffer(method.getName()).append('(');
return mBaseServedObject.processObjectRequest(
generateParameters(sb,method.getParameterTypes()).
append(')').toString(), args);
} catch (Throwable t) {
if (t instanceof RuntimeException) {
throw (RuntimeException) t;
} else if (t instanceof Error) {
throw (Error) t;
} else {
t.printStackTrace();
throw new
org.apache.commons.altrmi.common.AltrmiInvocationException("Should never get
here: " + t.getMessage());
}
private StringBuffer generateParameters(StringBuffer sb, Class[]
argTypes ) {
for( int i = 0; i < argTypes.length; i++){
sb.append( argTypes[i].getName() );
if (i + 1 < argTypes.length ) {
sb.append(", ");
}
}
return sb;
}
}
<scip>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [ARMI] ProxyGenrator
Posted by Juozas Baliuka <ba...@mwm.lt>.
<scip>
>
> >It single name for Class,
> >Is it means we need to generate Single proxy with this
> >ClassName,
> >Extend Single class form ClassesOrInterfaces if one of then is Class type
> >Implement all interfaces.
> >Or
> >Generated proxy count = ClassesOrInterfaces.length +
> >AdditionalFacades.length
> >And use name from "setClassName" as package name to define all proxies.
> >( "package" methods are not implemented at this time, only "protected"
and
> >"public" )
> >
> I am sorry Juozas, I do not understand what you are saying here (English
> usage).
>
> I do understand that you are saying that 'package', protected and public
> are worthy of thought. My feeling is that only public is needed, as
> that is the contract that java interfaces per se force on you.
Ok. It will be faster to understand this interface myself.
I seak JAVA better. :)
> Regards,
>
> - Paul H
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [ARMI] ProxyGenrator
Posted by Paul Hammant <Pa...@yahoo.com>.
Juozas,
><scip>
>Our proxys are different really. Decompile a generated proxy for ...
>
>> interface Fred {
>> int sayHelloFred(String s);
>> }
>>
>>..from both Simplestore and AltRMI to understand.
>>
>Yes, we dont use Enchancer for simplestore at this time, but we will rewrite
>PersistentProxy to support both Class an Interface type.
>
We are thinking from dropping the "class" types, and having just interfaces.
>I implemented
>MethodInterceptor and ConstructionHandler for ARMI, it calls
>
>generates signature ....
> return mBaseServedObject.processObjectRequest(signature,args);
> handles exeptions ....
>
You have coded it ... cool.
>>I have just replied to this in the EOB list, I'll repeat in summary form
>>
>>Ignore DeferredClasses for BCEL.
>>ClassesOrInterfaces and AdditionalFacades are to all intents and
>>purposes the same. They are pass-by-reference proxies.
>>
>
>It single name for Class,
>Is it means we need to generate Single proxy with this
>ClassName,
>Extend Single class form ClassesOrInterfaces if one of then is Class type
>Implement all interfaces.
>Or
>Generated proxy count = ClassesOrInterfaces.length +
>AdditionalFacades.length
>And use name from "setClassName" as package name to define all proxies.
>( "package" methods are not implemented at this time, only "protected" and
>"public" )
>
I am sorry Juozas, I do not understand what you are saying here (English
usage).
I do understand that you are saying that 'package', protected and public
are worthy of thought. My feeling is that only public is needed, as
that is the contract that java interfaces per se force on you.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [ARMI] ProxyGenrator
Posted by Juozas Baliuka <ba...@mwm.lt>.
<scip>
Our proxys are different really. Decompile a generated proxy for ...
>
> interface Fred {
> int sayHelloFred(String s);
> }
>
> ..from both Simplestore and AltRMI to understand.
Yes, we dont use Enchancer for simplestore at this time, but we will rewrite
PersistentProxy to support both Class an Interface type. I implemented
MethodInterceptor and ConstructionHandler for ARMI, it calls
generates signature ....
return mBaseServedObject.processObjectRequest(signature,args);
handles exeptions ....
It must work then we will have implementation for ProxyGenerator interface.
>
> >2. I don't understand ProxyGenerator interface in ARMI, It will be very
good if
> >somebody will write some coments, for this interface, Generator for ARMI
Proxy
> >is ready we need to add implementation for ProxyGenerator interface.
> >I don't understand meaning of "additionalFacede" ,"classesOrInterfaces"
and "DeferredClass".
> >
>
> I have just replied to this in the EOB list, I'll repeat in summary form
>
> Ignore DeferredClasses for BCEL.
> ClassesOrInterfaces and AdditionalFacades are to all intents and
> purposes the same. They are pass-by-reference proxies.
It single name for Class,
Is it means we need to generate Single proxy with this
ClassName,
Extend Single class form ClassesOrInterfaces if one of then is Class type
Implement all interfaces.
Or
Generated proxy count = ClassesOrInterfaces.length +
AdditionalFacades.length
And use name from "setClassName" as package name to define all proxies.
( "package" methods are not implemented at this time, only "protected" and
"public" )
>
> - Paul
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>