[JBoss JIRA] (JASSIST-183) API breakage: javassist.util.proxy.RuntimeSupport.findSuperMethod has changed signature
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-183?page=com.atlassian.jira.plugi... ]
Shigeru Chiba closed JASSIST-183.
---------------------------------
> API breakage: javassist.util.proxy.RuntimeSupport.findSuperMethod has changed signature
> ---------------------------------------------------------------------------------------
>
> Key: JASSIST-183
> URL: https://issues.jboss.org/browse/JASSIST-183
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.17.0-GA, 3.17.1-GA
> Environment: Seam 2.2.2 / 2.3.0, Java 7u9
> Reporter: Andrei Ivanov
> Assignee: Shigeru Chiba
> Priority: Blocker
> Labels: regression
> Fix For: 3.18.0-GA
>
>
> Checking how some applications run with Java 7, I've tried to upgrade to the newly released Javassist just to notice Seam is no longer working:
> {noformat}
> java.lang.NoSuchMethodError: javassist.util.proxy.RuntimeSupport.findSuperMethod(Ljava/lang/Object;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/reflect/Method;
> at OrderInitializer_$$_javassist_seam_0.writeReplace(OrderInitializer_$$_javassist_seam_0.java)
> at org.jboss.seam.Component.postConstructJavaBean(Component.java:1461)
> at org.jboss.seam.Component.postConstruct(Component.java:1379)
> at org.jboss.seam.Component.newInstance(Component.java:2155)
> at org.jboss.seam.contexts.Contexts.startup(Contexts.java:304)
> at org.jboss.seam.contexts.Contexts.startup(Contexts.java:278)
> at org.jboss.seam.contexts.ServletLifecycle.endInitialization(ServletLifecycle.java:143)
> at org.jboss.seam.init.Initialization.init(Initialization.java:744)
> at org.jboss.seam.mock.AbstractSeamTest.startSeam(AbstractSeamTest.java:929)
> at org.jboss.seam.mock.SeamTest.startSeam(SeamTest.java:69)
> {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
10 years, 11 months
[JBoss JIRA] (JASSIST-162) Correction introduced in JASSIST-127 raises AbstractMethodError on call site
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-162?page=com.atlassian.jira.plugi... ]
Shigeru Chiba closed JASSIST-162.
---------------------------------
> Correction introduced in JASSIST-127 raises AbstractMethodError on call site
> ----------------------------------------------------------------------------
>
> Key: JASSIST-162
> URL: https://issues.jboss.org/browse/JASSIST-162
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.16.1-GA
> Environment: OSX, JDK 1.6.0_29
> Reporter: Brice Dutheil
> Assignee: Shigeru Chiba
> Fix For: 3.18.0-GA
>
> Attachments: JASSIST-162___correct_patch_for_bridge_methods_and_covariant_return_types.patch
>
>
> The proposed solution in JASSIST-127 doesn't work, the JVM raises an {{AbstractMethodError}} on the call site.
> What happen is that in {{getMethods}} the code now discard method with same name / same arguments as the return type is not taken into account when generating the key.
> Reverting this patch will raises a {{DuplicateMemberException}}, the reason is that {{ClassFile.isDuplicated}} don't see either of the possible duplicate method as bridge.
> I've created a patch that detect methods with covariant type and mark forwarding methods as bridge if relevant.
> Note that the effect is only for method calls that have the very same arguments, as Javassist don't see duplicate methods if the arguments differ, e.g. proxying ({{StringList extends List<String>}}) will see {{add(Object)}} and {{add(String)}}, though the first one is not marked as bridge in the generated bytecode.
> Also, I'm not sure of that one, but the patch also adds a boolean to enable the {{MethodHandler}} to intercept bridge methods.
--
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
10 years, 11 months
[JBoss JIRA] (JASSIST-189) Bridge methods are proxied instead of desired methods
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-189?page=com.atlassian.jira.plugi... ]
Shigeru Chiba closed JASSIST-189.
---------------------------------
> Bridge methods are proxied instead of desired methods
> -----------------------------------------------------
>
> Key: JASSIST-189
> URL: https://issues.jboss.org/browse/JASSIST-189
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.17.1-GA
> Environment: OS X, Java 1.7.0_09
> Reporter: Donnchadh Ó Donnabháin
> Assignee: Shigeru Chiba
> Fix For: 3.18.0-GA
>
>
> The following test intermittently fails:
> {code}
> package org.javassist.test.covariantproxy;
> import java.lang.reflect.Method;
> import javassist.util.proxy.MethodHandler;
> import javassist.util.proxy.ProxyFactory;
> import javassist.util.proxy.ProxyObject;
> import junit.framework.TestCase;
> public class CovariantProxyTest extends TestCase {
>
> public interface TestProxy {
>
> }
>
> public static class TestMethodHandler implements MethodHandler {
>
> boolean invoked = false;
> public Object invoke(Object self, Method thisMethod, Method proceed, Object[] args) throws Throwable {
> invoked = true;
> return proceed.invoke(self, args);
> }
>
> public boolean wasInvoked() {
> return invoked;
> }
> public void reset() {
> invoked = false;
> }
> }
> public static class Issue {
>
> private Integer id;
>
> public Integer getId() {
> return id;
> }
>
> public void setId(Integer id) {
> this.id = id;
> }
> }
>
> public static class PublishedIssue extends Issue {
>
> }
> public static abstract class Article {
>
> private Integer id;
>
> public Integer getId() {
> return id;
> }
>
> public void setId(Integer id) {
> this.id = id;
> }
>
> public abstract Issue getIssue();
> }
> public static class PublishedArticle extends Article {
>
> private PublishedIssue issue;
>
> @Override
> public PublishedIssue getIssue() {
> return issue;
> }
>
> public void setIssue(PublishedIssue issue) {
> this.issue = issue;
> }
>
> }
>
> public void testThatCallingAMethodWithCovariantReturnTypeCallsProxy() throws Exception {
> Class persistentClass = PublishedArticle.class;
> ProxyFactory factory = new ProxyFactory();
> factory.setUseCache(false);
> factory.setSuperclass(persistentClass);
> factory.setInterfaces(new Class[] {TestProxy.class});
> Class cl = factory.createClass();
> TestProxy proxy = ( TestProxy ) cl.newInstance();
> TestMethodHandler methodHandler = new TestMethodHandler();
> ( ( ProxyObject ) proxy ).setHandler( methodHandler );
>
> ((Article)proxy).getIssue();
> assertTrue(methodHandler.wasInvoked());
>
> methodHandler.reset();
>
> PublishedArticle article = (PublishedArticle) proxy;
>
> article.getIssue();
>
> assertTrue(methodHandler.wasInvoked());
>
> }
>
> }
> {code}
> Were there tests added for JASSIST-24 ? I don't see any associated source.
> This bug causes a problem in hibernate, described in https://hibernate.onjira.com/browse/HHH-7884 .
> This may be related to JASSIST-162 but the circumstances are slightly different.
> The problem occurs intermittently so it appears to depend on the order in which the methods are processed.
--
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
10 years, 11 months
[JBoss JIRA] (JASSIST-180) Javassist fails to load class from jar (com.tivoli.pd.jutil.PDPermResource_cs )
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-180?page=com.atlassian.jira.plugi... ]
Shigeru Chiba closed JASSIST-180.
---------------------------------
> Javassist fails to load class from jar (com.tivoli.pd.jutil.PDPermResource_cs )
> -------------------------------------------------------------------------------
>
> Key: JASSIST-180
> URL: https://issues.jboss.org/browse/JASSIST-180
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.17.0-GA
> Reporter: ami tabak
> Assignee: Shigeru Chiba
> Priority: Critical
> Fix For: 3.17.0-GA
>
> Attachments: WebsphereBugSample.zip
>
>
> Trying to load class com.tivoli.mts.util.PDPermResource_cs which has only java dependencies. (based on JAD)
> Getting the following error at instantiation.
> 1. Not sure if its related to the 3.17.0 or just 3.17.1 code drops.
> 2. Not sure why its looking to the second class
> com.tivoli.pd.jutil.PDPermResource_cs
> rather than to what I'm trying to load.
> java.lang.InstantiationException: javassist.CtClassType
> at java.lang.Class.newInstance0(Class.java:357)
> at java.lang.Class.newInstance(Class.java:325)
> at com.optier.bug.report.WASTest.wasTestCase(WASTest.java:42)
> at com.optier.bug.report.WASTest.main(WASTest.java:18)
> Exception in thread "main" java.lang.RuntimeException: cannot find com.tivoli.mts.util.PDPermResource_cs: com.tivoli.pd.jutil.PDPermResource_cs found in com/tivoli/mts/util/PDPermResource_cs.class
> at javassist.CtClassType.getClassFile2(CtClassType.java:194)
> at javassist.CtClassType.makeFieldCache(CtClassType.java:848)
> at javassist.CtClassType.getMembers(CtClassType.java:839)
> at javassist.CtClassType.getDeclaredBehaviors(CtClassType.java:987)
> at com.optier.bug.report.WASTest.wasTestCase(WASTest.java:50)
> at com.optier.bug.report.WASTest.main(WASTest.java:18)
--
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
10 years, 11 months
[JBoss JIRA] (JASSIST-163) RuntimeSupport.find2Methods a perf hotspot when proxy's methods are called at higher concurrency
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-163?page=com.atlassian.jira.plugi... ]
Shigeru Chiba closed JASSIST-163.
---------------------------------
> RuntimeSupport.find2Methods a perf hotspot when proxy's methods are called at higher concurrency
> ------------------------------------------------------------------------------------------------
>
> Key: JASSIST-163
> URL: https://issues.jboss.org/browse/JASSIST-163
> Project: Javassist
> Issue Type: Enhancement
> Affects Versions: 3.15.0-GA, 3.16.1-GA
> Environment: hibernate-core 3.6.10.Final
> Reporter: Nikita Tovstoles
> Assignee: Shigeru Chiba
> Fix For: 3.17.0-GA
>
> Attachments: Bean_$$_bulkaccess_0.txt, Bean_$$_bulkaccess_0_Two.txt, blocked-threads.png, BulkAccessorFactory.java.diff, BulkAccessorFactory.java.diff2, BulkAccessorFactory.patch, find2methods-hotspot.png, jassist-163-fix.patch, monitor-backtraces.png, monitor-backtraces.png, Product.java, Product_$$_javassist_0-post-patch.java, Product_$$_javassist_0.java, Tomcat-2012-03-28(2).zip
>
>
> We've been profiling our Hibernate 3.6.10-based app and noticed a perf bottleneck in javassist.util.proxy.RuntimeSupport.find2methods. Unfortunately, this method, which has a synch. block, is being called on
> every invocation of every proxied entity method (see javassist.util.proxy.ProxyFactory.makeForwarder(), called indirectly by
> ProxyFactory.createClass()).
> In our testing, the result is that our service call's latency increases from 33 to 55, 260, 400ms as concurrency increases
> 1-10-20-30 users on a 4-core CPU. At 20 and 30 users 51% of CPU time is spent contending for a monitor in RuntimeSupport.find2methods:
> {code}
> synchronized (methods) {
> if (methods[index] == null) {
> methods[index + 1] = thisMethod == null ? null
> : findMethod(self, thisMethod, desc);
> methods[index] = findSuperMethod(self, superMethod, desc);
> }
> }
> {code}
> Since find2methods merely interrogates class metadata, seems like its return values should be cached (in a ConcurrentMap?) instead of repeatedly executing the above synchronized statement. Instead, currently, it's being called every time (?) a proxied method is executed - see *Invocation Count* in this screen shot:
> https://issues.jboss.org/secure/attachment/12353025/monitor-backtraces.png
> Full [YourKit profile|http://yourkit.com] is [attached as a ZIP archive|^Tomcat-2012-03-28(2).zip]; key screen shots from the snapshot also attached separately
--
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
10 years, 11 months
[JBoss JIRA] (JASSIST-177) javassist.bytecode.BadBytecode on weblogic.jdbc.jts.Driver:
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-177?page=com.atlassian.jira.plugi... ]
Shigeru Chiba closed JASSIST-177.
---------------------------------
> javassist.bytecode.BadBytecode on weblogic.jdbc.jts.Driver:
> -----------------------------------------------------------
>
> Key: JASSIST-177
> URL: https://issues.jboss.org/browse/JASSIST-177
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.17.0-GA
> Reporter: ami tabak
> Assignee: Shigeru Chiba
> Priority: Critical
> Fix For: 3.17.1-GA
>
> Attachments: javassist-3-17-GA-weblogicBugSample.zip, weblogicBugSampleWithOracleDriver.zip
>
>
> Once upgraded from 3.13 to 3.17 GA started receiving the following error:
> Might be reappearance of JASSIST-125.
> I tried to run the test with JDK 1.5 / 6/ 7 Same result.
> java version:1.6.0_16
> test: loading class data from pool:weblogic.jdbc.jts.Driver
> (2)javassist.CtMethod@3b9ab065[public connect (Ljava/lang/String;Ljava/util/Properties;)Ljava/sql/Connection;]
> Found method:(Ljava/lang/String;Ljava/util/Properties;)Ljava/sql/Connection;
> Fetching method attribute:
> Exception in thread "main" javassist.CannotCompileException: by javassist.bytecode.BadBytecode: connect (Ljava/lang/String;Ljava/util/Properties;)Ljava/sql/Connection; in weblogic.jdbc.jts.Driver: dead code detected at 664. No stackmap table generated.
> at javassist.CtBehavior.insertBefore(CtBehavior.java:773)
> at javassist.CtBehavior.insertBefore(CtBehavior.java:730)
> at com.optier.bug.report.Test.main(Test.java:76)
> Caused by: javassist.bytecode.BadBytecode: connect (Ljava/lang/String;Ljava/util/Properties;)Ljava/sql/Connection; in weblogic.jdbc.jts.Driver: dead code detected at 664. No stackmap table generated.
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:103)
> at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:423)
> at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:405)
> at javassist.CtBehavior.insertBefore(CtBehavior.java:764)
> ... 2 more
> Caused by: javassist.bytecode.BadBytecode: dead code detected at 664. No stackmap table generated.
> at javassist.bytecode.stackmap.MapMaker.fixDeadcode(MapMaker.java:314)
> at javassist.bytecode.stackmap.MapMaker.fixTypes(MapMaker.java:297)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:151)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:100)
> ... 5 more
--
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
10 years, 11 months
[JBoss JIRA] (JASSIST-176) I get a NPE in TypeData
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-176?page=com.atlassian.jira.plugi... ]
Shigeru Chiba closed JASSIST-176.
---------------------------------
> I get a NPE in TypeData
> -----------------------
>
> Key: JASSIST-176
> URL: https://issues.jboss.org/browse/JASSIST-176
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.17.0-GA
> Environment: Java 7
> Reporter: John Bainbridge
> Assignee: Shigeru Chiba
> Fix For: 3.17.0-GA
>
> Attachments: javassist.jar, javassist.nov7.jar
>
>
> This kills my JVM. I'm looking at trying to make simple test case. It appears to be releated to JASSIST-175
> caused by: java.lang.NullPointerException
> at javassist.bytecode.stackmap.TypeData.commonSuperClassEx(TypeData.java:400)
> at javassist.bytecode.stackmap.TypeData$TypeVar.fixTypes2(TypeData.java:342)
> at javassist.bytecode.stackmap.TypeData$TypeVar.fixTypes(TypeData.java:325)
> at javassist.bytecode.stackmap.TypeData$TypeVar.dfs(TypeData.java:270)
> at javassist.bytecode.stackmap.MapMaker.fixTypes(MapMaker.java:301)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:151)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:100)
> at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:423)
> at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:405)
> at javassist.expr.ExprEditor.doit(ExprEditor.java:113)
> at javassist.CtClassType.instrument(CtClassType.java:1398)
> at org.powermock.core.transformers.impl.MainMockTransformer.transform(MainMockTransformer.java:75)
> at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:203)
> ... 27 more
--
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
10 years, 11 months
