[JBoss JIRA] (WFLY-1777) Upgrade Wildfly to Infinispan 6
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-1777?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-1777:
------------------------------------
I'm going to start a branch for Infinispan 6.0. Given that Wildfly 8's CR is scheduled for Oct 10, and that Infinispan 6.0 is scheduled to go final just 2 days before, this doesn't seem very likely (Infinispan release dates usually slip quite a bit). I'll start a branch for this upgrade, so we'll see what happens in the coming months. I'm going to schedule this for WF9 for now.
> Upgrade Wildfly to Infinispan 6
> -------------------------------
>
> Key: WFLY-1777
> URL: https://issues.jboss.org/browse/WFLY-1777
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 8.0.0.Alpha3
> Reporter: Chris Ritter
> Assignee: Paul Ferraro
>
> Infinispan 6 is going to final in Sept. -- what's the timeline on integrating the latest version of Infinispan.
> There are major improvements, especially to the file store in 6.
--
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
12 years, 11 months
[JBoss JIRA] (WFLY-1777) Upgrade Wildfly to Infinispan 6
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-1777?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on WFLY-1777 at 7/30/13 1:47 PM:
-------------------------------------------------------------
Given that Wildfly 8's CR is scheduled for Oct 10, and that Infinispan 6.0 is scheduled to go final just 2 days before, this doesn't seem very likely (Infinispan release dates usually slip quite a bit). I'll start a branch for this upgrade, and we'll see what happens in the coming months. I'm going to schedule this for WF9 for now.
was (Author: pferraro):
I'm going to start a branch for Infinispan 6.0. Given that Wildfly 8's CR is scheduled for Oct 10, and that Infinispan 6.0 is scheduled to go final just 2 days before, this doesn't seem very likely (Infinispan release dates usually slip quite a bit). I'll start a branch for this upgrade, so we'll see what happens in the coming months. I'm going to schedule this for WF9 for now.
> Upgrade Wildfly to Infinispan 6
> -------------------------------
>
> Key: WFLY-1777
> URL: https://issues.jboss.org/browse/WFLY-1777
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 8.0.0.Alpha3
> Reporter: Chris Ritter
> Assignee: Paul Ferraro
> Fix For: 9.0.0.CR1
>
>
> Infinispan 6 is going to final in Sept. -- what's the timeline on integrating the latest version of Infinispan.
> There are major improvements, especially to the file store in 6.
--
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
12 years, 11 months
[JBoss JIRA] (WFLY-1406) Hibernate cannot process package-info.java any more
by Steve Ebersole (JIRA)
[ https://issues.jboss.org/browse/WFLY-1406?page=com.atlassian.jira.plugin.... ]
Steve Ebersole commented on WFLY-1406:
--------------------------------------
Here is what the javadoc for that method ({{org.hibernate.jpa.boot.archive.spi.ArchiveEntry#getNameWithinArchive}}) says:
{code}
/**
* Get the relative name of the entry within the archive. Typically what we are looking for here is
* the ClassLoader resource lookup name.
*
* @return The name relative to the archive root
*/
public String getNameWithinArchive();
{code}
Notice the specific reference to "ClassLoader resource lookup name"...
> Hibernate cannot process package-info.java any more
> ---------------------------------------------------
>
> Key: WFLY-1406
> URL: https://issues.jboss.org/browse/WFLY-1406
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 8.0.0.Alpha2
> Reporter: Juergen Zimmermann
> Attachments: javap.log, server.log, server.log.zip, shop2.war, tar.log
>
>
> I tried the snapshot which contains Hibernate 4.3.0.Beta2. However, package-info.java files are causing problems. For instance, the package de.shop.artikelverwaltung.domain has a package-info.java which causes a NoClassDefFoundError:
> "IllegalName: de/shop/artikelverwaltung/domain.package-info". Please see the stacktrace below.
> Here is an example for package-info.java which was working with WildFly 8.0.0.Alpha1:
> @XmlAccessorType(FIELD)
> @Vetoed
> package de.shop.artikelverwaltung.domain;
> import static javax.xml.bind.annotation.XmlAccessType.FIELD;
> import javax.enterprise.inject.Vetoed;
> import javax.xml.bind.annotation.XmlAccessorType;
> The stacktrace:
> ...
> 09:29:53,880 WARN [org.jboss.modules] Failed to define class de/shop/artikelverwaltung/domain.package-info in Module "deployment.shop2.war:main" from Service Module Loader: java.lang.LinkageError: Failed to link de/shop/artikelverwaltung/domain/package-info (Module "deployment.shop2.war:main" from Service Module Loader)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:427) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:260) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:75) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.Module.loadModuleClass(Module.java:526) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:188) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.0.Final]
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader.findClass(ClassLoaderServiceImpl.java:218) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:423) [rt.jar:1.7.0_21]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356) [rt.jar:1.7.0_21]
> at org.hibernate.annotations.common.util.ReflectHelper.classForName(ReflectHelper.java:160) [hibernate-commons-annotations-4.0.2.Final.jar:4.0.2.Final]
> at org.hibernate.annotations.common.reflection.java.JavaReflectionManager.packageForName(JavaReflectionManager.java:121) [hibernate-commons-annotations-4.0.2.Final.jar:4.0.2.Final]
> at org.hibernate.cfg.AnnotationBinder.bindPackage(AnnotationBinder.java:262) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.cfg.Configuration.addPackage(Configuration.java:792) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildHibernateConfiguration(EntityManagerFactoryBuilderImpl.java:1174) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:839) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.HibernatePersistenceProvider.createContainerEntityManagerFactory(HibernatePersistenceProvider.java:142) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.createContainerEntityManagerFactory(PersistenceUnitServiceImpl.java:213) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.access$800(PersistenceUnitServiceImpl.java:58) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:107) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: java.lang.NoClassDefFoundError: IllegalName: de/shop/artikelverwaltung/domain.package-info
> at java.lang.ClassLoader.preDefineClass(ClassLoader.java:646) [rt.jar:1.7.0_21]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:785) [rt.jar:1.7.0_21]
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:344) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:422) [jboss-modules.jar:1.2.0.Final]
> ... 28 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
12 years, 11 months
[JBoss JIRA] (WFLY-1406) Hibernate cannot process package-info.java any more
by Steve Ebersole (JIRA)
[ https://issues.jboss.org/browse/WFLY-1406?page=com.atlassian.jira.plugin.... ]
Steve Ebersole commented on WFLY-1406:
--------------------------------------
Thanks for investigating Juergen.
I almost think the problem is with {{entry.getNameWithinArchive()}}. To me it seems like these paths should get normalized.
> Hibernate cannot process package-info.java any more
> ---------------------------------------------------
>
> Key: WFLY-1406
> URL: https://issues.jboss.org/browse/WFLY-1406
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 8.0.0.Alpha2
> Reporter: Juergen Zimmermann
> Attachments: javap.log, server.log, server.log.zip, shop2.war, tar.log
>
>
> I tried the snapshot which contains Hibernate 4.3.0.Beta2. However, package-info.java files are causing problems. For instance, the package de.shop.artikelverwaltung.domain has a package-info.java which causes a NoClassDefFoundError:
> "IllegalName: de/shop/artikelverwaltung/domain.package-info". Please see the stacktrace below.
> Here is an example for package-info.java which was working with WildFly 8.0.0.Alpha1:
> @XmlAccessorType(FIELD)
> @Vetoed
> package de.shop.artikelverwaltung.domain;
> import static javax.xml.bind.annotation.XmlAccessType.FIELD;
> import javax.enterprise.inject.Vetoed;
> import javax.xml.bind.annotation.XmlAccessorType;
> The stacktrace:
> ...
> 09:29:53,880 WARN [org.jboss.modules] Failed to define class de/shop/artikelverwaltung/domain.package-info in Module "deployment.shop2.war:main" from Service Module Loader: java.lang.LinkageError: Failed to link de/shop/artikelverwaltung/domain/package-info (Module "deployment.shop2.war:main" from Service Module Loader)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:427) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:260) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:75) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.Module.loadModuleClass(Module.java:526) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:188) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.0.Final]
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader.findClass(ClassLoaderServiceImpl.java:218) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:423) [rt.jar:1.7.0_21]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356) [rt.jar:1.7.0_21]
> at org.hibernate.annotations.common.util.ReflectHelper.classForName(ReflectHelper.java:160) [hibernate-commons-annotations-4.0.2.Final.jar:4.0.2.Final]
> at org.hibernate.annotations.common.reflection.java.JavaReflectionManager.packageForName(JavaReflectionManager.java:121) [hibernate-commons-annotations-4.0.2.Final.jar:4.0.2.Final]
> at org.hibernate.cfg.AnnotationBinder.bindPackage(AnnotationBinder.java:262) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.cfg.Configuration.addPackage(Configuration.java:792) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildHibernateConfiguration(EntityManagerFactoryBuilderImpl.java:1174) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:839) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.HibernatePersistenceProvider.createContainerEntityManagerFactory(HibernatePersistenceProvider.java:142) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.createContainerEntityManagerFactory(PersistenceUnitServiceImpl.java:213) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.access$800(PersistenceUnitServiceImpl.java:58) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:107) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: java.lang.NoClassDefFoundError: IllegalName: de/shop/artikelverwaltung/domain.package-info
> at java.lang.ClassLoader.preDefineClass(ClassLoader.java:646) [rt.jar:1.7.0_21]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:785) [rt.jar:1.7.0_21]
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:344) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:422) [jboss-modules.jar:1.2.0.Final]
> ... 28 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
12 years, 11 months
[JBoss JIRA] (WFLY-530) Integrate RESTEasy and Hibernate Validator for resource validation
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-530?page=com.atlassian.jira.plugin.s... ]
Jason Greene resolved WFLY-530.
-------------------------------
Fix Version/s: 8.0.0.Alpha3
(was: 8.0.0.Alpha4)
Resolution: Done
> Integrate RESTEasy and Hibernate Validator for resource validation
> ------------------------------------------------------------------
>
> Key: WFLY-530
> URL: https://issues.jboss.org/browse/WFLY-530
> Project: WildFly
> Issue Type: Sub-task
> Reporter: Emmanuel Bernard
> Fix For: 8.0.0.Alpha3
>
>
> JAX-RS describes how resources can be validated via the use of Bean Validation.
> While some are method calls on CDI beans and thus can be handled by the CDI interceptor, fields and getter resources cannot be handled that way. Likewise @GET, @PUT etc methods are considered constrained methods even if they are getters and without user use of @ValidateExecutable.
> We need to figure out something.
> Adding [~bill.burke] to the loop
--
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
12 years, 11 months
[JBoss JIRA] (WFLY-1769) 2 config updates for OpenJDK 8
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-1769?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann commented on WFLY-1769:
------------------------------------------
OK, using https the command sequence worked. I hope that I successfully sent the PR.
> 2 config updates for OpenJDK 8
> ------------------------------
>
> Key: WFLY-1769
> URL: https://issues.jboss.org/browse/WFLY-1769
> Project: WildFly
> Issue Type: Feature Request
> Components: EE
> Reporter: Juergen Zimmermann
> Assignee: David Lloyd
>
> JDK 8 uses the Javascript Engine Nashorn instead of Rhino in JDK 7 (and 6).
> Therefore, 2 additional config lines are required to support JDK 8 in addition to JDK 7:
> After making the following 2 config updates for bean validation my web app is running with WildFly and OpenJDK 8:
> 1) In modules/system/layers/base/sun/jdk/main/module.xml: add the following <path> declaration as the 2nd subtag inside <paths>, i.e. after the "com/sun/script/javascript" for JDK 7:
> {code}
> <path name="jdk/nashorn/api/scripting"/>
> {code}
> 2) In modules/system/layers/base/sun/jdk/main/service-loader-resources/META-INF/services/javax.script.ScriptEngineFactory add the following line as the 2nd service, i.e. as a alternative service for JDK 7:
> {code}
> jdk.nashorn.api.scripting.NashornScriptEngineFactory
> {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
12 years, 11 months
[JBoss JIRA] (JASSIST-204) Getting java.lang.VerifyError when adding try/catch to a method using CtMethod.insertAfter, if the method returns when the JVM stack is not empty - Inconsistent stack height 0 != 1, or Inconsistent stackmap frames at branch target
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-204?page=com.atlassian.jira.plugi... ]
Shigeru Chiba commented on JASSIST-204:
---------------------------------------
Yes, you're right. That bytecode is not broken. It's fine according to the specifications.
But, fixing it is not straightforward. One solution is to check all return instructions and insert pop instructions if necessary. A drawback of this solution is an extra overhead is added to insertAfter() even if pops are not needed. Another solution is to insert a distinct copy of the statement to every return statement. The memory overhead is a drawback of this solution. Are there other approaches?
> Getting java.lang.VerifyError when adding try/catch to a method using CtMethod.insertAfter, if the method returns when the JVM stack is not empty - Inconsistent stack height 0 != 1, or Inconsistent stackmap frames at branch target
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JASSIST-204
> URL: https://issues.jboss.org/browse/JASSIST-204
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.17.0-GA, 3.18.0-GA
> Environment: Occurred on Windows with standard HotSpot JVM (1.6.0_24, 1.7.0_21, ..), also with IBM J9 JVM on AIX etc.
> Reporter: Dordoriko Beanie
> Assignee: Shigeru Chiba
> Labels: VerifyError, height, insertBefore, stack
> Attachments: popnopbug.zip
>
>
> After instrumenting certain classes with insertAfter(), I am consistently getting java.lang.VerifyError when trying to load the instrumented class(either "Inconsistent stack height 0 != 1" or "Inconsistent stackmap frames at branch target", depending on whether I'm on a newer 1.7 environment or an older one). The class was perfectly loadable prior to instrumentation, even though it exhibits a slightly unusual property that its return-type instructions are not necessarily executed when the stack is empty (not counting the return parameter, if applicable).
> The problem originally occurred with some class file that was apparently weaved by AspectJ 1.5.2a, but it was then reproduced by combining the following circumstances:
> 1) That the instrumented method has the "odd" property that it has an areturn/ireturn/return instruction which is invoked when the stack is not empty (when there are one or more values that were pushed onto the current frame and weren't popped). Note that I was unable to produce this with a freshly compiled .java source, so instead I took a simple .class file and changed one of the popping instructions to a nop instruction using a hex editor.
> 2) That the code added by insertAfter() contains a try/catch structure or something similar (which forces the stack height to be reset in case of catch). It is possible that this wasn't really necessary and that similar symptoms could occur by just having multiple return statements with different stack heights.
> When this happens, javassist replaces the original return-type instruction with a goto (when the stack height is N), but also adds a goto to the same label from the end of the catch clause (when the stack height is 0).
> runtest_modified_nop_java17.bat
> Exception in thread "main" java.lang.VerifyError: Inconsistent stackmap frames at branch target 35 in method com.test.HelloWorld.g()Ljava/lang/String; at offset 20
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
> at java.lang.Class.getMethod0(Unknown Source)
> at java.lang.Class.getMethod(Unknown Source)
> at sun.launcher.LauncherHelper.getMainMethod(Unknown Source)
> at sun.launcher.LauncherHelper.checkAndLoadMain(Unknown Source)
> runtest_modified_nop_java12.bat
> Exception in thread "main" java.lang.VerifyError: (class: com/test/HelloWorld, method: g signature: ()Ljava/lang/String;) Inconsistent stack height 0 != 1
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
> at java.lang.Class.getMethod0(Unknown Source)
> at java.lang.Class.getMethod(Unknown Source)
> at sun.launcher.LauncherHelper.getMainMethod(Unknown Source)
> at sun.launcher.LauncherHelper.checkAndLoadMain(Unknown Source)
--
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
12 years, 11 months