Ok... =) Looks like this is a problem with the generated method byte
code. I still have not tracked down exactly how to fix it... but I am
closer now. Thanks for your insight... and the dump or your method...
that is what helped me find the problem.
--jason
Juozas Baliuka wrote:
>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]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
