Hi,
We use BCEL for Proxy generation and it is no problems if MethodGen is
constructed this way :
private static MethodGen toMethodGen(
java.lang.reflect.Method mtd,
String className,
InstructionList il,
ConstantPoolGen cp) {
return new MethodGen(
ACC_PUBLIC,
toType(mtd.getReturnType()),
toType(mtd.getParameterTypes()),
null,
mtd.getName(),
className,
il,
cp);
}
May this problem exists in some version ?
I tried to build it from CVS a few weeks ago and from binary distribution,
but I don't see any problem.
Can you tell us version of BCEL distribution you use ?
It is output from DEBUG :
public void testLong(long arg1, long arg2)
Code(max_stack = 8, max_locals = 10, code_length = 112)
0: iconst_2
1: anewarray <java.lang.Object> (16)
4: dup
5: iconst_0
6: new <java.lang.Long> (45)
9: dup
10: lload_1
11: invokespecial java.lang.Long.<init> (J)V (48)
14: aastore
15: dup
16: iconst_1
17: new <java.lang.Long> (45)
20: dup
21: lload_3
22: invokespecial java.lang.Long.<init> (J)V (48)
25: aastore
26: astore %5
28: aload_0
29: getfield
org.apache.commons.simplestore.TestPersistentClassType$$EnhancedBySimplestor
e$$.h Lorg/apache/commons/simplestore/tools/MethodInterceptor; (14)
32: aload_0
33: getstatic
org.apache.commons.simplestore.TestPersistentClassType$$EnhancedBySimplestor
e$$.METHOD_0 Ljava/lang/reflect/Method; (50)
36: aload %5
38: invokeinterface
org.apache.commons.simplestore.tools.MethodInterceptor.beforeInvoke
(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;)Ljava/lang/
Object; (33) 4 0
43: astore %6
45: aconst_null
46: astore %7
48: iconst_0
49: istore %8
51: aconst_null
52: astore %9
54: aload_0
55: getfield
org.apache.commons.simplestore.TestPersistentClassType$$EnhancedBySimplestor
e$$.h Lorg/apache/commons/simplestore/tools/MethodInterceptor; (14)
58: aload_0
59: getstatic
org.apache.commons.simplestore.TestPersistentClassType$$EnhancedBySimplestor
e$$.METHOD_0 Ljava/lang/reflect/Method; (50)
62: aload %5
64: aload %6
66: invokeinterface
org.apache.commons.simplestore.tools.MethodInterceptor.invokeSuper
(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;Ljava/lang/O
bject;)Z (41) 5 0
71: ifeq #88
74: iconst_1
75: istore %8
77: aload_0
78: lload_1
79: lload_3
80: invokespecial
org.apache.commons.simplestore.TestPersistentClassType.testLong (JJ)V (54)
83: goto #88
86: astore %9
88: aload_0
89: getfield
org.apache.commons.simplestore.TestPersistentClassType$$EnhancedBySimplestor
e$$.h Lorg/apache/commons/simplestore/tools/MethodInterceptor; (14)
92: aload_0
93: getstatic
org.apache.commons.simplestore.TestPersistentClassType$$EnhancedBySimplestor
e$$.METHOD_0 Ljava/lang/reflect/Method; (50)
96: aload %5
98: aload %6
100: iload %8
102: aload %7
104: aload %9
106: invokeinterface
org.apache.commons.simplestore.tools.MethodInterceptor.afterReturn
(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;Ljava/lang/O
bject;ZLjava/lang/Object;Ljava/lang/Throwable;)Ljava/lang/Object; (37) 8
0
111: return
Exception handler(s) =
>From To Handler Type
75 86 86 java.lang.Throwable(56)
Class used for test looks like this :
public abstract class TestPersistentClassType implements TestPersistent,
org.apache.commons.simplestore.tools.Constants{
/** Creates a new instance of TestPersistentClassType */
public TestPersistentClassType() {
}
/***********************************/
public void testLong(long p1,long p2){
System.out.println("" + p1 + " " + p2);
}
/***********************************/
public void doSomething(String arg){
if( DEBUG ){
this.setStrVal("done Something " + arg);
System.out.println(getStrVal());
}
}
public void setNuls(){
setDateVal( null ) ;
setStrVal1( null );
setStrVal ( null );
setParent ( null );
}
public abstract TestPersistentClassType getParent();
public abstract void setDateVal(java.util.Date val) ;
public abstract void setBoolVal(boolean val) ;
public abstract java.util.Date getDateVal() ;
public abstract void setIntVal(int val);
public abstract void setFloatVal(float val) ;
public abstract float getFloatVal() ;
public abstract void setStrVal1(String strVal1);
public abstract void setStrVal(String strVal1);
public abstract String getStrVal();
public abstract java.util.Collection getChildren();
public abstract String getStrVal1();
public abstract void setParent(TestPersistentClassType tp);
public abstract int getIntVal();
public abstract boolean getBoolVal();
}
----- Original Message -----
From: "Jason Dillon" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, April 05, 2002 10:04 AM
Subject: Possible problem with MethodGen & long/double param types...
> Hey, I am working to fix a bug in side of JBoss, which relates to our
> dymanic proxy generation. This was recently switched over to using
> BCEL, but it seems like there is a problem.
>
> Before I get into the details, let me say that I am not a VM expert or a
> byte code whiz... I generally like to deal with higher level
> abstractions, but this bug looked important and well all this BCEL stuff
> looks really interesting. That said, this could simply be a problem
> with our usage, but based on my investigation today I don't think so...
> but who knows.
>
> I did try to look for some bug reports on this already, but either it is
> getting too late and I need to go home, or I simply will never
> understand how to use Bugzilla...
>
> * * *
>
> We use BCEL to generate proxies to interfaces and abstract classes. But
> for simplicily I will keep things to interfaces, as this shows the
problem.
>
> Take the given interface:
>
> public interface MyInterface
> {
> void test(long a, long b);
> }
>
> The MethodGen.toString() ends up with:
>
> public void test(long arg0, long)
>
> Where it should be:
>
> public void test(long arg0, long arg1)
>
> It turns out (only did some brief testing) that when using all long or
> double types that every other parameter will get corrupted like this.
> If you use any other type there are no problems.
>
> * * *
>
> We have a class (called ProxyImplementationFactory... for whatever
> reason) which contains helper methods to generate Method objects for
> parts of the target proxy. To make sure that none of the BCEL code
> inside was messing with this (as I don't really know that much about it
> ... yet), I took the contents of a method which generates a String
> toString() method and used it inside of the method which exhibits this
> problem... which it still does/did with this change.
>
> Based on this I am thinking that the problem is with the byte code
> generation done under the covers inside of MethodGen and friends. I
> spent very little time looking through this code to see if I could find
> anything obvious... but no.
>
> I am thinking that the code which deals with generation of the byte code
> for the method might not be giving enough space for the long/double...
> but that is just a guess, I don't really know how method defs work.
>
> Can someone give me a hand to get this fixed... either help me to get my
> code proper or track down a bug in BCEL... or evern better informing me
> that this is already fixed.
>
> Many thanks,
>
> --jason
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
