January 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JASSIST-241) VerifyError: Expecting a stackmap frame - Switch case statement Java 7

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-241?page=com.atlassian.jira.plugi... ] Shigeru Chiba closed JASSIST-241. --------------------------------- > VerifyError: Expecting a stackmap frame - Switch case statement Java 7 > ---------------------------------------------------------------------- > > Key: JASSIST-241 > URL: https://issues.jboss.org/browse/JASSIST-241 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.19.0-GA > Environment: jdk7 > Reporter: Patson Luk > Assignee: Shigeru Chiba > Fix For: 3.20.0-GA > > > This could be a duplicate of issue 215 and 205. > Tested it on the master (3.19.0-GA) with java 7. Running the below class > {code} > import java.util.Random; > import javassist.ClassPool; > import javassist.CtClass; > import javassist.CtMethod; > public class TestDriver { > public static void main(String[] args) throws Exception { > ClassPool pool = ClassPool.getDefault(); > CtClass cc = pool.get("TestClass"); > > CtMethod testMethod = cc.getMethod("test", "(Ljava/lang/Object;)V"); > testMethod.insertAfter("System.out.println(\"inserted!\");"); > cc.toClass(); > //invoke it > TestClass.test(new Object()); > } > } > class TestClass { > public static void test(Object o) { > //part 1 > if (o == null) { > return; > } > //part 2 > int oper = new Random().nextInt(); > switch (oper) { > case 1: > break; > } > } > } > {code} > > Triggers error message as below: > {quote} > Exception in thread "main" java.lang.VerifyError: Expecting a stackmap frame at branch target 9 in method TestClass.test(Ljava/lang/Object;)V at offset 1 > at TestDriver.main(TestDriver.java:19) > {quote} > *Please take note that:* > # This is observed on Java 7. When the same code is run on Java 6, it is fine > # Both the "part 1" - return statement (commented in the code above) and "part 2" - switch/case statement have to be there to trigger the error. If either of those are commented out, then the code runs fine -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-241) VerifyError: Expecting a stackmap frame - Switch case statement Java 7

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-241?page=com.atlassian.jira.plugi... ] Shigeru Chiba resolved JASSIST-241. ----------------------------------- Fix Version/s: 3.20.0-GA Resolution: Done > VerifyError: Expecting a stackmap frame - Switch case statement Java 7 > ---------------------------------------------------------------------- > > Key: JASSIST-241 > URL: https://issues.jboss.org/browse/JASSIST-241 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.19.0-GA > Environment: jdk7 > Reporter: Patson Luk > Assignee: Shigeru Chiba > Fix For: 3.20.0-GA > > > This could be a duplicate of issue 215 and 205. > Tested it on the master (3.19.0-GA) with java 7. Running the below class > {code} > import java.util.Random; > import javassist.ClassPool; > import javassist.CtClass; > import javassist.CtMethod; > public class TestDriver { > public static void main(String[] args) throws Exception { > ClassPool pool = ClassPool.getDefault(); > CtClass cc = pool.get("TestClass"); > > CtMethod testMethod = cc.getMethod("test", "(Ljava/lang/Object;)V"); > testMethod.insertAfter("System.out.println(\"inserted!\");"); > cc.toClass(); > //invoke it > TestClass.test(new Object()); > } > } > class TestClass { > public static void test(Object o) { > //part 1 > if (o == null) { > return; > } > //part 2 > int oper = new Random().nextInt(); > switch (oper) { > case 1: > break; > } > } > } > {code} > > Triggers error message as below: > {quote} > Exception in thread "main" java.lang.VerifyError: Expecting a stackmap frame at branch target 9 in method TestClass.test(Ljava/lang/Object;)V at offset 1 > at TestDriver.main(TestDriver.java:19) > {quote} > *Please take note that:* > # This is observed on Java 7. When the same code is run on Java 6, it is fine > # Both the "part 1" - return statement (commented in the code above) and "part 2" - switch/case statement have to be there to trigger the error. If either of those are commented out, then the code runs fine -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-697) Report an error when a declared type extends the wrong type

by Davide Sottara (JIRA)

Davide Sottara created DROOLS-697: ------------------------------------- Summary: Report an error when a declared type extends the wrong type Key: DROOLS-697 URL: https://issues.jboss.org/browse/DROOLS-697 Project: Drools Issue Type: Enhancement Affects Versions: 6.2.0.CR4, 6.1.0.Final, 6.0.1.Final, 5.6.0.Final, 5.5.0.Final Reporter: Davide Sottara Assignee: Davide Sottara Priority: Minor Fix For: 6.2.0.Final Declared pojos should extend regular classes, while declared traits should extend interfaces. The bean creation process does not enforce such a type check, possibly resulting in serious exceptions -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-241) VerifyError: Expecting a stackmap frame - Switch case statement Java 7

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-241?page=com.atlassian.jira.plugi... ] Shigeru Chiba commented on JASSIST-241: --------------------------------------- I think your problem analysis is right. Thanks, it helps bug fixing lots! > VerifyError: Expecting a stackmap frame - Switch case statement Java 7 > ---------------------------------------------------------------------- > > Key: JASSIST-241 > URL: https://issues.jboss.org/browse/JASSIST-241 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.19.0-GA > Environment: jdk7 > Reporter: Patson Luk > Assignee: Shigeru Chiba > > This could be a duplicate of issue 215 and 205. > Tested it on the master (3.19.0-GA) with java 7. Running the below class > {code} > import java.util.Random; > import javassist.ClassPool; > import javassist.CtClass; > import javassist.CtMethod; > public class TestDriver { > public static void main(String[] args) throws Exception { > ClassPool pool = ClassPool.getDefault(); > CtClass cc = pool.get("TestClass"); > > CtMethod testMethod = cc.getMethod("test", "(Ljava/lang/Object;)V"); > testMethod.insertAfter("System.out.println(\"inserted!\");"); > cc.toClass(); > //invoke it > TestClass.test(new Object()); > } > } > class TestClass { > public static void test(Object o) { > //part 1 > if (o == null) { > return; > } > //part 2 > int oper = new Random().nextInt(); > switch (oper) { > case 1: > break; > } > } > } > {code} > > Triggers error message as below: > {quote} > Exception in thread "main" java.lang.VerifyError: Expecting a stackmap frame at branch target 9 in method TestClass.test(Ljava/lang/Object;)V at offset 1 > at TestDriver.main(TestDriver.java:19) > {quote} > *Please take note that:* > # This is observed on Java 7. When the same code is run on Java 6, it is fine > # Both the "part 1" - return statement (commented in the code above) and "part 2" - switch/case statement have to be there to trigger the error. If either of those are commented out, then the code runs fine -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-505) Fix double redeployment due to .failed file and a artifact with newer timestamp.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-505?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-505: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1169239 > Fix double redeployment due to .failed file and a artifact with newer timestamp. > -------------------------------------------------------------------------------- > > Key: WFCORE-505 > URL: https://issues.jboss.org/browse/WFCORE-505 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 1.0.0.Alpha15 > Reporter: Chao Wang > Assignee: Chao Wang > Fix For: 1.0.0.Alpha16 > > > Issue found and described in https://bugzilla.redhat.com/show_bug.cgi?id=1169239 > steps to reproduce: > 1. deploy a "Test.war" > 2. Change something in "Test.war" to fail it. > 3. "Test.war.failed" file will be created. > 4. stop JBoss EAP. > 5. Revert the changes done in "Test.war" so that it will deploy successfully. > 6. Now there are two files ("Test.war.failed" and "Test.war", due to correction, Test.war must have a newer timestamp than Test.war.failed)in deployment directory. > 7. Restart JBoss EAP, it will fail with below Error : > The problem happens as a result of redundant redeployment in next reboot. During servert reboot, it will try to redeploy the application due to found .failed file, it also will try to redeploy same application because Test.war has a newer timestamp to see the problem. This will cause server startup failure as: > {noformat} > ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 18) JBAS014613: Operation ("add") failed - address: ([("deployment" => "Test.war")]) - failure description: "JBAS014803: Duplicate resource [(\"deployment\" => \"Test.war\")] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-522) BlockingNotificationMBeanServer will NPE if resolvedDomain or expressionsDomain are not configured

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-522?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-522: ------------------------------------------------ Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1185496|https://bugzilla.redhat.com/show_bug.cgi?id=1185496] from NEW to POST > BlockingNotificationMBeanServer will NPE if resolvedDomain or expressionsDomain are not configured > -------------------------------------------------------------------------------------------------- > > Key: WFCORE-522 > URL: https://issues.jboss.org/browse/WFCORE-522 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha16 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > If the jmx subsystem <expose-resolved-model/> and/or <expose-expression-model/> settings are not configured, but <remoting-connector/> is BlockingNotificationMBeanServer will throw NPEs in isInExposedModelControllerDomains due to passing null into java.util.regex.Pattern.matcher(...). > Simply null checks will fix the problem. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-54) Add Keycloak authentication/authorization to http management endpoint

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-54?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFCORE-54: ----------------------------------- Fix Version/s: 1.0.0.Alpha17 (was: 1.0.0.Alpha16) > Add Keycloak authentication/authorization to http management endpoint > --------------------------------------------------------------------- > > Key: WFCORE-54 > URL: https://issues.jboss.org/browse/WFCORE-54 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: 1.0.0.Alpha4 > Reporter: Stan Silvert > Assignee: Stan Silvert > Fix For: 1.0.0.Alpha17 > > > This is here to track the core changes needed for WFLY-3591. See that jira for details. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-25) Windows PowerShell scripts in bin

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-25?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFCORE-25: ----------------------------------- Fix Version/s: 1.0.0.Alpha17 (was: 1.0.0.Alpha16) > Windows PowerShell scripts in bin > --------------------------------- > > Key: WFCORE-25 > URL: https://issues.jboss.org/browse/WFCORE-25 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: Brian Stansberry > Assignee: Tomaz Cerar > Fix For: 1.0.0.Alpha17 > > > Add .psh scripts that match the functionality of our .sh scripts. Leave the .bat scripts in their current limited-functionality form for people still on XP, but use PowerShell as the recommended Windows scripting language. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-129) Overlay does not work for subunits in exploded deployments.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-129?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-129: ------------------------------------ Fix Version/s: 1.0.0.Alpha17 (was: 1.0.0.Alpha16) > Overlay does not work for subunits in exploded deployments. > ----------------------------------------------------------- > > Key: WFCORE-129 > URL: https://issues.jboss.org/browse/WFCORE-129 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 1.0.0.Alpha8 > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: 1.0.0.Alpha17 > > > If deployment is exploded and has subdeployments overlay wont work on files contained in said subdeployments. > Reproducers: https://github.com/baranowb/wildfly/tree/WFCORE-83-TESTS -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-107) Update whoami operation to return authentication mechanism where verbose=true

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-107?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-107: ------------------------------------ Fix Version/s: 1.0.0.Alpha17 (was: 1.0.0.Alpha16) > Update whoami operation to return authentication mechanism where verbose=true > ----------------------------------------------------------------------------- > > Key: WFCORE-107 > URL: https://issues.jboss.org/browse/WFCORE-107 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha17 > > > The admin console currently contains a "logout" handler that follows a round of HTTP message exchanges to trick the web browser into forgetting the credentials it has cached. > This only makes sense where the browser has cached a credential - if we return the authentication mechanism then the console can make a better decision regarding displaying the logout link or could change the implementation so display a message to the user explaining why logout does not make sense. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2015