April 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JASSIST-173) No Exception is thrown by CtNewMethod.make() when return type is wrong

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-173?page=com.atlassian.jira.plugi... ] Shigeru Chiba commented on JASSIST-173: --------------------------------------- Well, to minimize runtime overhead due to bytecode generation, Javassist's compiler does not check type errors; it assumes that the given source code is always correct. So throwing no exception is part of the specifications. > No Exception is thrown by CtNewMethod.make() when return type is wrong > ---------------------------------------------------------------------- > > Key: JASSIST-173 > URL: https://issues.jboss.org/browse/JASSIST-173 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.16.1-GA > Environment: Windows Vista, JDK 1.6 > Reporter: Maxime Dubois > Assignee: Shigeru Chiba > > When using the CtNewMethod.make() method to create a method that returns data with a wrong type, no Exception is thrown. > Steps to reproduce: > ----------------- > - use the method "public static CtMethod make(java.lang.String src, CtClass declaring)" to create a method that looks like this: > public static boolean myMethod() { return ("toto"); } > - add it to a CtClass object using the addMethod() method > Result : > ----------------- > No CannotCompileException is thrown, the method is created and added to the class without any problem even though it is not correct. > When trying to use the resulting class, the following error is thrown: "java.lang.VerifyError: Wrong return type in function" > Expected result : > ------------------ > The CtNewMethod.make() method should throw a CannotCompileException indicating that the return type is wrong. -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-173) No Exception is thrown by CtNewMethod.make() when return type is wrong

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-173?page=com.atlassian.jira.plugi... ] Shigeru Chiba closed JASSIST-173. --------------------------------- Resolution: Rejected > No Exception is thrown by CtNewMethod.make() when return type is wrong > ---------------------------------------------------------------------- > > Key: JASSIST-173 > URL: https://issues.jboss.org/browse/JASSIST-173 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.16.1-GA > Environment: Windows Vista, JDK 1.6 > Reporter: Maxime Dubois > Assignee: Shigeru Chiba > > When using the CtNewMethod.make() method to create a method that returns data with a wrong type, no Exception is thrown. > Steps to reproduce: > ----------------- > - use the method "public static CtMethod make(java.lang.String src, CtClass declaring)" to create a method that looks like this: > public static boolean myMethod() { return ("toto"); } > - add it to a CtClass object using the addMethod() method > Result : > ----------------- > No CannotCompileException is thrown, the method is created and added to the class without any problem even though it is not correct. > When trying to use the resulting class, the following error is thrown: "java.lang.VerifyError: Wrong return type in function" > Expected result : > ------------------ > The CtNewMethod.make() method should throw a CannotCompileException indicating that the return type is wrong. -- 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

13 years, 3 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 resolved JASSIST-181. ----------------------------------- Fix Version/s: 3.18.0-GA Resolution: Done > 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-5432) TransactionRolledbackLocalException doesn't reference the originating runtime-exception

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-5432?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-5432: ---------------------------------------------- wfink(a)redhat.com made a comment on [bug 952629|https://bugzilla.redhat.com/show_bug.cgi?id=952629] Change is merged to https://github.com/jbossas/jboss-eap.git (EAP6.1) > TransactionRolledbackLocalException doesn't reference the originating runtime-exception > --------------------------------------------------------------------------------------- > > Key: AS7-5432 > URL: https://issues.jboss.org/browse/AS7-5432 > Project: Application Server 7 > Issue Type: Bug > Components: EJB > Affects Versions: 7.1.1.Final, 7.1.2.Final (EAP) > Reporter: Barnabas Bodnar > Assignee: jaikiran pai > Fix For: EAP 6.1.0.Alpha (7.2.0.Final) > > > If a runtime-exception thrown by an EJB v2.x application leads to javax.ejb.TransactionRolledbackLocalException (s. org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(...)), the TransactionRolledbackLocalException doesn't reference the originating exception (either as getCause() or as getCausedByException()). > The originating exception gets in org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories.LOCAL_INSTANCE lost: the javax.ejb.EJBTransactionRolledbackException catched here does still contain it, it will, however, not be propagated to the javax.ejb.TransactionRolledbackLocalException created here. > This behavior also deviates from that in the case of a locally started transaction: the wrapping javax.ejb.EJBException (s. org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(...)) is thrown unchanged to the caller (s. org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories.LOCAL_INSTANCE) and it references the originating exception both as getCause() and as getCausedByException(). -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBBUILD-725) Upgrade compiler plugin to >3.1 (once released)

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/JBBUILD-725?page=com.atlassian.jira.plugi... ] Lukáš Fryč updated JBBUILD-725: ------------------------------- Summary: Upgrade compiler plugin to >3.1 (once released) (was: Upgrade compiler plugin to 3.1) > Upgrade compiler plugin to >3.1 (once released) > ----------------------------------------------- > > Key: JBBUILD-725 > URL: https://issues.jboss.org/browse/JBBUILD-725 > Project: JBoss Build System > Issue Type: Bug > Components: JBoss Parent POM > Affects Versions: JBoss Parent POM - 10 > Reporter: Lukáš Fryč > Assignee: Paul Gier > > The compiler plugin in version {{3.0}} detects changes and thus recompile whole module even if there are no changes (e.g. {{mvn clean compile; mvn compile}}. > {code} > Changes detected - recompiling the module! > {code} > Upstream issue: http://jira.codehaus.org/browse/MCOMPILER-187 > https://github.com/jboss/jboss-parent-pom/blob/fb95df4dff8163a451286453f7... -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBBUILD-725) Upgrade compiler plugin to >3.1 (once released)

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/JBBUILD-725?page=com.atlassian.jira.plugi... ] Lukáš Fryč edited comment on JBBUILD-725 at 4/17/13 9:15 AM: ------------------------------------------------------------- Note that the upstream issue [wasn't solved correctly|http://jira.codehaus.org/browse/MCOMPILER-187?focusedCommentId=...]. I have opened new upstream issue to address it: https://jira.codehaus.org/browse/MCOMPILER-205 was (Author: lfryc): Note that the upstream issue [wasn't solved correctly|http://jira.codehaus.org/browse/MCOMPILER-187?focusedCommentId=...]. > Upgrade compiler plugin to >3.1 (once released) > ----------------------------------------------- > > Key: JBBUILD-725 > URL: https://issues.jboss.org/browse/JBBUILD-725 > Project: JBoss Build System > Issue Type: Bug > Components: JBoss Parent POM > Affects Versions: JBoss Parent POM - 10 > Reporter: Lukáš Fryč > Assignee: Paul Gier > > The compiler plugin in version {{3.0}} detects changes and thus recompile whole module even if there are no changes (e.g. {{mvn clean compile; mvn compile}}. > {code} > Changes detected - recompiling the module! > {code} > Upstream issue: http://jira.codehaus.org/browse/MCOMPILER-187 > https://github.com/jboss/jboss-parent-pom/blob/fb95df4dff8163a451286453f7... -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6933) Task for tracking all workarounds / hacks needed to have undertow & jbossweb living together

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/AS7-6933?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar updated AS7-6933: ----------------------------- Description: There are many workarounds in undertow subsystem code just to make it behave exactly as jbossweb did but that is wrong in many cases. This issue is here just to track such occurrences and resolutions for this issue should eventual removal of this hacks when web subsystem is removed from AS8 was: There are many workarounds in undertow subsystem code just to make it behave exactly as jbossweb did but that is wrong in may cases. This issue is here just to track such occurrences and resolutions for this issue should eventual removal of this hacks when web subsystem is removed from AS8 > Task for tracking all workarounds / hacks needed to have undertow & jbossweb living together > -------------------------------------------------------------------------------------------- > > Key: AS7-6933 > URL: https://issues.jboss.org/browse/AS7-6933 > Project: Application Server 7 > Issue Type: Task > Components: Web > Affects Versions: 8.0.0.Alpha1 > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 8.0.0.CR1 > > > There are many workarounds in undertow subsystem code just to make it behave exactly as jbossweb did but that is wrong in many cases. > This issue is here just to track such occurrences and resolutions for this issue should eventual removal of this hacks when web subsystem is removed from AS8 -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6933) Task for tracking all workarounds / hacks needed to have undertow & jbossweb living together

by Tomaz Cerar (JIRA)

Tomaz Cerar created AS7-6933: -------------------------------- Summary: Task for tracking all workarounds / hacks needed to have undertow & jbossweb living together Key: AS7-6933 URL: https://issues.jboss.org/browse/AS7-6933 Project: Application Server 7 Issue Type: Task Components: Web Affects Versions: 8.0.0.Alpha1 Reporter: Tomaz Cerar Assignee: Tomaz Cerar Fix For: 8.0.0.CR1 There are many workarounds in undertow subsystem code just to make it behave exactly as jbossweb did but that is wrong in may cases. This issue is here just to track such occurrences and resolutions for this issue should eventual removal of this hacks when web subsystem is removed from AS8 -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6929) Provide way to display deployed application metadata

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/AS7-6929?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar updated AS7-6929: ----------------------------- Summary: Provide way to display deployed application metadata (was: Output final DeploymentInfo for an application) > Provide way to display deployed application metadata > ---------------------------------------------------- > > Key: AS7-6929 > URL: https://issues.jboss.org/browse/AS7-6929 > Project: Application Server 7 > Issue Type: Feature Request > Components: Domain Management, Web > Affects Versions: 8.0.0.Alpha1 > Reporter: Nicklas Karlsson > Assignee: Tomaz Cerar > > It would be handy to have the deployment process print out the complete DeploymentInfo for an application so one could view the final order of filters and request listeners etc. -- 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBBUILD-725) Upgrade compiler plugin to 3.1

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/JBBUILD-725?page=com.atlassian.jira.plugi... ] Lukáš Fryč commented on JBBUILD-725: ------------------------------------ Note that the upstream issue [wasn't solved correctly|http://jira.codehaus.org/browse/MCOMPILER-187?focusedCommentId=...]. > Upgrade compiler plugin to 3.1 > ------------------------------ > > Key: JBBUILD-725 > URL: https://issues.jboss.org/browse/JBBUILD-725 > Project: JBoss Build System > Issue Type: Bug > Components: JBoss Parent POM > Affects Versions: JBoss Parent POM - 10 > Reporter: Lukáš Fryč > Assignee: Paul Gier > > The compiler plugin in version {{3.0}} detects changes and thus recompile whole module even if there are no changes (e.g. {{mvn clean compile; mvn compile}}. > {code} > Changes detected - recompiling the module! > {code} > Upstream issue: http://jira.codehaus.org/browse/MCOMPILER-187 > https://github.com/jboss/jboss-parent-pom/blob/fb95df4dff8163a451286453f7... -- 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

13 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 April 2013