June 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1436) Incorrect vresion number reported by JBoss fork of Mojarra for 2.2.0.Final

by Stan Silvert (JIRA)

[ https://issues.jboss.org/browse/WFLY-1436?page=com.atlassian.jira.plugin.... ] Stan Silvert updated WFLY-1436: ------------------------------- Fix Version/s: 8.0.0.Alpha2 Git Pull Request: https://github.com/wildfly/wildfly/pull/4578 Affects Version/s: 8.0.0.Alpha2 > Incorrect vresion number reported by JBoss fork of Mojarra for 2.2.0.Final > -------------------------------------------------------------------------- > > Key: WFLY-1436 > URL: https://issues.jboss.org/browse/WFLY-1436 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 8.0.0.Alpha2 > Environment: WildFly upstream (June 1 2013) > Reporter: jaikiran pai > Assignee: Stan Silvert > Fix For: 8.0.0.Alpha2 > > > Recently JSF mojarra was updated to 2.2.0.Final https://github.com/wildfly/wildfly/pull/4568. A user has reported that the version is being incorrectly reported https://github.com/wildfly/wildfly/commit/a0a6adc2aa7e87975991300488b6a69.... > It indeed looks like a bug in the forked version, in the commit here https://github.com/jboss/mojarra/commit/e83154185eea8e94533718dba7086f181... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-201) VerifyError: Inconsistent args_size for opc_invokeinterface occured for nested statement

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-201?page=com.atlassian.jira.plugi... ] Shigeru Chiba closed JASSIST-201. --------------------------------- > VerifyError: Inconsistent args_size for opc_invokeinterface occured for nested statement > ---------------------------------------------------------------------------------------- > > Key: JASSIST-201 > URL: https://issues.jboss.org/browse/JASSIST-201 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.17.1-GA > Environment: Sun JRE6 1.6.0_25 64bits > Reporter: Hua Zhang > Assignee: Shigeru Chiba > Priority: Critical > Labels: VerifyError, nested, opc_invokeinterface > Fix For: 3.18.0-GA > > > Please see source in "steps to reproduce". > Running the code will throw error: > Exception in thread "main" java.lang.VerifyError: (class: Clazz, method: method signature: ()V) Inconsistent args_size for opc_invokeinterface > at java.lang.Class.getDeclaredConstructors0(Native Method) > at java.lang.Class.privateGetDeclaredConstructors(Unknown Source) > at java.lang.Class.getConstructors(Unknown Source) > at test.<init>(test.java:27) > at test.main(test.java:31) > The key is on "new HashMap().toString()" in the statement: > theMethod.setBody("{map.put(\"name\", new HashMap().toString());System.out.println(\"OK\");}"); > The behaviour is really strange. Try to modify it, sometimes it can be run successfully, sometimes failed. But they all can be compiled successfully. > FAILED: > theMethod.setBody("{StringBuffer buffer = new StringBuffer();map.put(\"name\", buffer.toString());System.out.println(\"OK\");}"); > SUCCESS: > theMethod.setBody("{map.put(\"name\", map.toString());System.out.println(\"OK\");}"); > SUCCESS: (workaround) > theMethod.setBody("{String V = new HashMap().toString();map.put(\"name\", V);System.out.println(\"OK\");}"); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-188) CtClass detach does not completely clean class from pool.

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-188?page=com.atlassian.jira.plugi... ] Shigeru Chiba closed JASSIST-188. --------------------------------- > CtClass detach does not completely clean class from pool. > --------------------------------------------------------- > > Key: JASSIST-188 > URL: https://issues.jboss.org/browse/JASSIST-188 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.17.0-GA > Environment: Ubuntu, Windows, JDK 1.6/1.7 > Reporter: J D > Assignee: Shigeru Chiba > Priority: Critical > Fix For: 3.18.0-GA > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > Description: > Class with same qualified name cannot be recreated even if previous class was detached successfully from pool. > Creation#1: Consider class eg.foo.MyClass is created using default pool and private int myArg1 private member along with some getter/setter methods. After its creation, the CtClass.detach is invoked successfully. > Creation#2: Subsequently, create eg.foo.MyClass using same default pool succeeds but any attempt to add members e.g. private int myArg1 fails with error: > Field myArg1 in eg.foo.MyClass is private. > Bug Analysis: > MemberCodeGen.isAccessibleField has f.getDeclaringClass from Creation#1 but thisClass is from Creation#2. This was traced to MemberResolver.invalidNamesMap. When Creation#1 detached the CtClass, it got removed from pool but not from the invalidNamesMap for default pool. Subsequently when MemberResolver.lookupClass looks for "eg.foo.MyClass", the Creation#1's CtClass gets returned. This is a bug because that class was detached earlier and must not be reused for any processing - we are creating another instance because a new definition is needed for that class. > The bug is critical as erroneous unintended cached class definitions could be used even when not intended leading to potentially very severe runtime problems. Remember that cache is a good only if it accurately provided cached results. In this case, stale/incorrect results will be returned. > Proposed Fix: > Add a static method detachInvalidNames in MemberResolver that removes a qualified class-name from invalidNamesMap for that class's pool. CtClass.detach must invoke this detachInvalidNames. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-196) Dont use ==, instead use .equals() for strings

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-196?page=com.atlassian.jira.plugi... ] Shigeru Chiba closed JASSIST-196. --------------------------------- > Dont use ==, instead use .equals() for strings > ---------------------------------------------- > > Key: JASSIST-196 > URL: https://issues.jboss.org/browse/JASSIST-196 > Project: Javassist > Issue Type: Quality Risk > Affects Versions: 3.17.1-GA > Reporter: oliver z > Assignee: Shigeru Chiba > Fix For: 3.17.1-GA > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > I just used a code quality tool to scan my application which uses javassist. > It is complaining about a few "==" instead of .equals(). > Occurance at least in: AccessorMaker.java:127 > Would be nice if this could be fixed because as its a very little change. > Thanks! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-199) LinkageError while accessing classes using ProxyFactory

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-199?page=com.atlassian.jira.plugi... ] Shigeru Chiba closed JASSIST-199. --------------------------------- > LinkageError while accessing classes using ProxyFactory > ------------------------------------------------------- > > Key: JASSIST-199 > URL: https://issues.jboss.org/browse/JASSIST-199 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.17.1-GA > Reporter: Shigeru Chiba > Assignee: Shigeru Chiba > Fix For: 3.18.0-GA > > > ProxyFactory does not guarantee the uniqueness of the names > of the generated proxy classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-178) Binary on Maven Central requires Java 7

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-178?page=com.atlassian.jira.plugi... ] Shigeru Chiba closed JASSIST-178. --------------------------------- > Binary on Maven Central requires Java 7 > --------------------------------------- > > Key: JASSIST-178 > URL: https://issues.jboss.org/browse/JASSIST-178 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.17.0-GA > Reporter: Dan Fabulich > Assignee: Shigeru Chiba > Fix For: 3.17.1-GA > > > As discussed in https://issues.jboss.org/browse/JASSIST-163?focusedCommentId=12734189&pag... > The binary uploaded to Maven central http://repo2.maven.org/maven2/org/javassist/javassist/3.17.0-GA/ requires Java 7, breaking backward compatibility with Java 6 and lower. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-195) Verifier error with try-finally clause in Java 1.7

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-195?page=com.atlassian.jira.plugi... ] Shigeru Chiba closed JASSIST-195. --------------------------------- > Verifier error with try-finally clause in Java 1.7 > --------------------------------------------------- > > Key: JASSIST-195 > URL: https://issues.jboss.org/browse/JASSIST-195 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.17.1-GA > Environment: Oracle Java 1.7 on Mac OS X > Reporter: John Brush > Assignee: Shigeru Chiba > Fix For: 3.18.0-GA > > > After upgrading from Java 1.6 to Java 1.7 our unit tests failed due to the new verifier in 1.7 which requires a stack map. I fixed this issue by adding a call to the rebuildStackMap() method after instrumentation, but this caused a new problem to pop up in one particular instance: > {code} > public int testInstrumentedCallInFinallyBlock( int i ) > { > try > {} > catch ( Throwable t ) > {} > finally > { > i = incByOne( i ); > } > return i; > } > {code} > This unit test results in the following exception: > java.lang.VerifyError: Stack map does not match the one at exception handler 9 in method xxx.StatementsTestComponent.testInstrumentedCallInFinallyBlock(I)I at offset 9 > After some investigation, I noticed that the problem occurred independent of my instrumentation, simply as a result of loading the byte code with Javassist, invoking rebuildStackMap() and then trying to load it. The byte code for the above snippet looks as follows before invoking rebuildStackMap(): > {code} > Code: > stack=2, locals=3, args_size=2 > 0: aload_0 > 1: iload_1 > 2: invokespecial #3 // Method incByOne:(I)I > 5: istore_1 > 6: goto 18 > 9: astore_2 > 10: aload_0 > 11: iload_1 > 12: invokespecial #3 // Method incByOne:(I)I > 15: istore_1 > 16: aload_2 > 17: athrow > 18: iload_1 > 19: ireturn > Exception table: > from to target type > 9 10 9 any > StackMapTable: number_of_entries = 2 > frame_type = 73 /* same_locals_1_stack_item */ > stack = [ class java/lang/Throwable ] > frame_type = 8 /* same */ > {code} > Afterwards, it looks like this: > {code} > Code: > stack=2, locals=3, args_size=2 > 0: aload_0 > 1: iload_1 > 2: invokespecial #23 // Method incByOne:(I)I > 5: istore_1 > 6: goto 18 > 9: nop > 10: nop > 11: nop > 12: nop > 13: nop > 14: nop > 15: goto 9 > 18: iload_1 > 19: ireturn > Exception table: > from to target type > 9 10 9 any > StackMapTable: number_of_entries = 2 > frame_type = 249 /* chop */ > offset_delta = 9 > frame_type = 253 /* append */ > offset_delta = 8 > locals = [ class ch/shaktipat/saraswati/instrument/busicomp/StatementsTestComponent, int ] > {code} > Notice the modifications from lines 9-15: this is a result of Javassist's MapMaker.fixDeadcode() method. I assume that the verify error is a result of the exception table entry that refers to code which is no longer there. A possible fix would be to make sure that any exception handlers referring to dead code are removed in such cases. Personally, I would prefer that Javassist simply not modify the code if at all possible, or at least for such modifications to be optional (configurable). > BTW: my only workaround for the time being is to force the 1.7 JVM to use the old verifier with -XX:-UseSplitVerifier. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-186) java.lang.VerifyError: Inconsistent args count operand in invokeinterface in method

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-186?page=com.atlassian.jira.plugi... ] Shigeru Chiba closed JASSIST-186. --------------------------------- > java.lang.VerifyError: Inconsistent args count operand in invokeinterface in method > ----------------------------------------------------------------------------------- > > Key: JASSIST-186 > URL: https://issues.jboss.org/browse/JASSIST-186 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.17.0-GA, 3.17.1-GA > Reporter: Lauri Tulmin > Assignee: Shigeru Chiba > Fix For: 3.18.0-GA > > Attachments: JASSIST-186.patch, javassist-bug2.zip > > > Happens when the argument of interface method call comes from anoter method call, like > {code} > m.insertBefore( > "{" + > " java.util.List l = new java.util.ArrayList();" + > " l.add(this.toString());" + > "}" > ); > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-184) Javassist ProxyFactory does not handle interfaces with generics correctly.

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-184?page=com.atlassian.jira.plugi... ] Shigeru Chiba closed JASSIST-184. --------------------------------- > Javassist ProxyFactory does not handle interfaces with generics correctly. > -------------------------------------------------------------------------- > > Key: JASSIST-184 > URL: https://issues.jboss.org/browse/JASSIST-184 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.17.0-GA > Reporter: Eduardo Macarron > Assignee: Shigeru Chiba > Fix For: 3.18.0-GA > > Attachments: testinterfaces.tar.gz > > > We included Javassist support for MyBatis 3.2.0. > We had an issue regarding generics. > http://code.google.com/p/mybatis/issues/detail?id=664 > We have isolated it and looks like this is a problem in Javassist. > CGlib works fine in the same scenario. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-181) java.lang.RuntimeException: multiple descriptors? with javac 1.7

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-181?page=com.atlassian.jira.plugi... ] Shigeru Chiba closed JASSIST-181. --------------------------------- > java.lang.RuntimeException: multiple descriptors? with javac 1.7 > ---------------------------------------------------------------- > > Key: JASSIST-181 > URL: https://issues.jboss.org/browse/JASSIST-181 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.17.0-GA > Environment: Windows 7 x64, > java version "1.7.0_05" > Java(TM) SE Runtime Environment (build 1.7.0_05-b06) > Java HotSpot(TM) Client VM (build 23.1-b03, mixed mode, sharing) > Eclipse Juno Service Release 1 > Reporter: Oleh Faizulin > Assignee: Shigeru Chiba > Fix For: 3.18.0-GA > > Attachments: javassist_test.zip > > > Hi, > When I try to run attached code compiled with javac I recive the following error: > {noformat} > Exception in thread "main" java.lang.RuntimeException: multiple descriptors?: Ljavassist_test/A<TT;>.B; > at javassist.bytecode.Descriptor.toClassName(Descriptor.java:108) > at javassist.bytecode.annotation.ClassMemberValue.getValue(ClassMemberValue.java:100) > at javassist.bytecode.annotation.ClassMemberValue.toString(ClassMemberValue.java:117) > at java.lang.String.valueOf(String.java:2902) > at java.lang.StringBuffer.append(StringBuffer.java:232) > at javassist.bytecode.annotation.Annotation.toString(Annotation.java:223) > at javassist.bytecode.annotation.AnnotationImpl.invoke(AnnotationImpl.java:137) > at $Proxy0.toString(Unknown Source) > at java.lang.String.valueOf(String.java:2902) > at java.io.PrintStream.println(PrintStream.java:821) > at javassist_test.Test.main(Test.java:21) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) > {noformat} > However if I run the same code from eclipse (ejc) i get expected result: > {noformat} > @javassist_test.Condition(condition=<javassist_test.A$B class>) > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2013