Groovy
  1. Groovy
  2. GROOVY-4673

java.lang.ClassFormatError: Illegal class name "groovy/jmx/builder/package-info" in class file groovy/jmx/builder/package-info

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.7.7
    • Fix Version/s: 1.8.1, 1.7.11
    • Component/s: groovy-jdk
    • Labels:
      None
    • Environment:
      JBoss AS 6.0.0 / Tomcat 7.0.0
      Windows 7

      Description

      The groovy-all-1.7.7.jar file in the embeddable directory of the binary ZIP file contains an invalid package-info file groovy.jmx.builder.package-info.class. I believe this is due to the src/main/groovy/jmx/builder/package-info.groovy file being incorrectly compiled. In Tomcat 7.0.0 and JBoss AS 6.0.0, this results in an exception like the one below and a deployment failure for any applications that bundle this JAR file.

      Tomcat has since released a patch that issues this is a warning and allows the deployment to continue, but JBoss AS has not. Since the problem is ultimately that a legitimately invalid package-info class exists in the library, it seems most logical that the problem be resolved with Groovy and not JBoss.

      I was able to resolve my issue for now by manually editing the distributable JAR file and removing the package-info.class file from it, but this is not a good permanent solution.

      Here is the exception:

      Exception
      18:02:52,225 WARN  [org.jboss.detailed.classloader.ClassLoaderManager] Unexpected error during load of:groovy.jmx.builder.package-info: java.lang.ClassFormatError: Illegal class name "groovy/jmx/builder/package-info" in class file groovy/jmx/builder/package-info
      	at java.lang.ClassLoader.defineClass1(Native Method) [:1.6.0_23]
      	at java.lang.ClassLoader.defineClassCond(Unknown Source) [:1.6.0_23]
      	at java.lang.ClassLoader.defineClass(Unknown Source) [:1.6.0_23]
      	at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:52) [jboss-classloader.jar:2.2.0.GA]
      	at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:650) [jboss-classloader.jar:2.2.0.GA]
      	at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:609) [jboss-classloader.jar:2.2.0.GA]
      	at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_23]
      	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:608) [jboss-classloader.jar:2.2.0.GA]
      	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:585) [jboss-classloader.jar:2.2.0.GA]
      	at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:156) [jboss-classloader.jar:2.2.0.GA]
      	at org.jboss.classloader.spi.filter.FilteredDelegateLoader.doLoadClass(FilteredDelegateLoader.java:141) [jboss-classloader.jar:2.2.0.GA]
      	at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:132) [jboss-classloader.jar:2.2.0.GA]
      	at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:461) [jboss-classloader.jar:2.2.0.GA]
      	at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:262) [jboss-classloader.jar:2.2.0.GA]
      	at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:161) [jboss-classloader.jar:2.2.0.GA]
      	at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:260) [jboss-classloader.jar:2.2.0.GA]
      	at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1152) [jboss-classloader.jar:2.2.0.GA]
      	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:886) [jboss-classloader.jar:2.2.0.GA]
      	at org.jboss.classloader.spi.base.BaseClassLoader.doLoadClass(BaseClassLoader.java:505) [jboss-classloader.jar:2.2.0.GA]
      	at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:450) [jboss-classloader.jar:2.2.0.GA]
      	at java.lang.ClassLoader.loadClass(Unknown Source) [:1.6.0_23]
      	at java.lang.Class.forName0(Native Method) [:1.6.0_23]
      	at java.lang.Class.forName(Unknown Source) [:1.6.0_23]
      	at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.resolveComplexTypeInfo(IntrospectionTypeInfoFactoryImpl.java:458) [jboss-reflect.jar:2.2.0.GA]
      	at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.getTypeInfo(IntrospectionTypeInfoFactoryImpl.java:414) [jboss-reflect.jar:2.2.0.GA]
      	at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactory.getTypeInfo(IntrospectionTypeInfoFactory.java:54) [jboss-reflect.jar:2.2.0.GA]
      	at org.jboss.config.plugins.AbstractConfiguration.getTypeInfo(AbstractConfiguration.java:121) [jboss-reflect.jar:2.2.0.GA]
      	at org.jboss.kernel.plugins.config.AbstractKernelConfig.getTypeInfo(AbstractKernelConfig.java:95) [jboss-kernel.jar:2.2.0.GA]
      	at org.jboss.kernel.plugins.config.AbstractKernelConfigurator.getTypeInfo(AbstractKernelConfigurator.java:102) [jboss-kernel.jar:2.2.0.GA]
      	at org.jboss.scanning.plugins.visitor.ConfiguratorReflectProvider.getTypeInfo(ConfiguratorReflectProvider.java:47) [:1.0.0.GA]
      	at org.jboss.scanning.plugins.visitor.CachingReflectProvider.getTypeInfo(CachingReflectProvider.java:52) [:1.0.0.GA]
      	at org.jboss.scanning.plugins.visitor.ReflectResourceVisitor.getTypeInfo(ReflectResourceVisitor.java:60) [:1.0.0.GA]
      	at org.jboss.scanning.plugins.visitor.ReflectResourceVisitor.getClassInfo(ReflectResourceVisitor.java:72) [:1.0.0.GA]
      	at org.jboss.scanning.plugins.visitor.ReflectResourceVisitor.doVisit(ReflectResourceVisitor.java:107) [:1.0.0.GA]
      	at org.jboss.scanning.plugins.visitor.ReflectResourceVisitor.visit(ReflectResourceVisitor.java:86) [:1.0.0.GA]
      	at org.jboss.scanning.hierarchy.plugins.HierarchyIndexScanningPlugin.visit(HierarchyIndexScanningPlugin.java:91) [:1.0.0.GA]
      	at org.jboss.scanning.spi.helpers.ScanningPluginWrapper.visit(ScanningPluginWrapper.java:112) [:1.0.0.GA]
      	at org.jboss.classloading.plugins.visitor.FederatedResourceVisitor.visit(FederatedResourceVisitor.java:101) [jboss-classloading.jar:2.2.0.GA]
      	at org.jboss.classloading.plugins.vfs.VFSResourceVisitor.visit(VFSResourceVisitor.java:264) [jboss-classloading-vfs.jar:2.2.0.GA]
      	at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:408) [jboss-vfs.jar:3.0.0.GA]
      	at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:410) [jboss-vfs.jar:3.0.0.GA]
      	at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:410) [jboss-vfs.jar:3.0.0.GA]
      	at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:410) [jboss-vfs.jar:3.0.0.GA]
      	at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:396) [jboss-vfs.jar:3.0.0.GA]
      	at org.jboss.classloading.plugins.vfs.VFSResourceVisitor.visit(VFSResourceVisitor.java:102) [jboss-classloading-vfs.jar:2.2.0.GA]
      	at org.jboss.deployers.vfs.plugins.classloader.VFSDeploymentClassLoaderPolicyModule.visit(VFSDeploymentClassLoaderPolicyModule.java:181) [:2.2.0.GA]
      	at org.jboss.scanning.plugins.DeploymentUnitScanner.scan(DeploymentUnitScanner.java:111) [:1.0.0.GA]
      	at org.jboss.scanning.spi.helpers.UrlScanner.scan(UrlScanner.java:96) [:1.0.0.GA]
      	at org.jboss.scanning.deployers.ScanningDeployer.deploy(ScanningDeployer.java:95) [:1.0.0.GA]
      	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.GA]
      	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.0.GA]
      	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.0.GA]
      	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.0.GA]
      	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA]
      	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.GA]
      	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.GA]
      	at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
      	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA]
      	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA]
      	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.GA]
      	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.GA]
      	at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.0.GA]
      	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.0.GA]
      	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.0.GA]
      	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:380) [:6.0.0.Final]
      	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_23]
      	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) [:1.6.0_23]
      	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) [:1.6.0_23]
      	at java.lang.reflect.Method.invoke(Unknown Source) [:1.6.0_23]
      	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) [:6.0.0.GA]
      	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [:6.0.0.GA]
      	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [:6.0.0.GA]
      	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271) [:6.0.0.GA]
      	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670) [:6.0.0.GA]
      	at org.jboss.system.server.jmx.MBeanServerWrapper.invoke(MBeanServerWrapper.java:138) [:6.0.0.Final (Build SVNTag:JBoss_6.0.0.Final date: 20101228)]
      	at javax.management.remote.rmi.RMIConnectionImpl.doOperation(Unknown Source) [:1.6.0_23]
      	at javax.management.remote.rmi.RMIConnectionImpl.access$200(Unknown Source) [:1.6.0_23]
      	at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(Unknown Source) [:1.6.0_23]
      	at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(Unknown Source) [:1.6.0_23]
      	at javax.management.remote.rmi.RMIConnectionImpl.invoke(Unknown Source) [:1.6.0_23]
      	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_23]
      	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) [:1.6.0_23]
      	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) [:1.6.0_23]
      	at java.lang.reflect.Method.invoke(Unknown Source) [:1.6.0_23]
      	at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) [:1.6.0_23]
      	at sun.rmi.transport.Transport$1.run(Unknown Source) [:1.6.0_23]
      	at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_23]
      	at sun.rmi.transport.Transport.serviceCall(Unknown Source) [:1.6.0_23]
      	at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) [:1.6.0_23]
      	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source) [:1.6.0_23]
      	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source) [:1.6.0_23]
      	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) [:1.6.0_23]
      	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [:1.6.0_23]
      	at java.lang.Thread.run(Unknown Source) [:1.6.0_23]
      1. package-info.java
        0.1 kB
        Cédric Champeau
      2. package-info.class
        0.2 kB
        Cédric Champeau
      3. MyAnnotation.java
        0.4 kB
        Cédric Champeau

        Activity

        Hide
        Guillaume Delcroix added a comment -

        I've removed the offending package-info.groovy file.

        Show
        Guillaume Delcroix added a comment - I've removed the offending package-info.groovy file.
        Hide
        Nick Williams added a comment -

        I figured that would be the only needed change. Thanks!

        Show
        Nick Williams added a comment - I figured that would be the only needed change. Thanks!
        Hide
        Paul King added a comment -

        Deleting the file from source isn't the correct approach - as we lose doco and have reduced functionality in groovydoc compared with javadoc. We need to make other parts of the build ignore such files. I'll work on a better fix shortly.

        Show
        Paul King added a comment - Deleting the file from source isn't the correct approach - as we lose doco and have reduced functionality in groovydoc compared with javadoc. We need to make other parts of the build ignore such files. I'll work on a better fix shortly.
        Hide
        Paul King added a comment -

        Actually looking at the generated class file I don't see much different from what Java produces in its package-info.class files. Groovy is setting "major version: 49" (Java 5 had some package-info support anyway) versus Java which is setting "major version: 50" with my default setup but otherwise the files seem alike.

        Show
        Paul King added a comment - Actually looking at the generated class file I don't see much different from what Java produces in its package-info.class files. Groovy is setting "major version: 49" (Java 5 had some package-info support anyway) versus Java which is setting "major version: 50" with my default setup but otherwise the files seem alike.
        Hide
        Cédric Champeau added a comment -

        If I remember well, package-info.java files should only be processed by javadoc : if you compile this file with javac, no .class file should be produced. groovyc produces this file though with package-info.groovy.

        Show
        Cédric Champeau added a comment - If I remember well, package-info.java files should only be processed by javadoc : if you compile this file with javac, no .class file should be produced. groovyc produces this file though with package-info.groovy.
        Hide
        Nick Williams added a comment -

        Let my provide a few more details...

        As of and after Java 1.5, package-info.java classes ARE compiled and shipped. This is because packages can retain annotations at runtime, and you annotate a package by annotating the package statement in package-info.java.

        Comments, annotations and the package statement should be the only things present in a package-info.java file, and the compiler strips out comments as usual and leaves just the package statement and annotations marked as having a runtime retention policy.

        The package-info.groovy file just had the package statement and comments in it (so it was rather worthless for anything other than JavaDocs), but when compiled, the following appeared in it (when decompiled):

        package groovy.jmx.builder;
        
        interface package-info {
        
        }
        

        The Java ClassLoader, when it sees this (empty) interface defined in the class file, throws an error because you can't have hyphens in class/interface names. That is the error you get above.

        So the 100% correct solution is to fix the Groovy compiler to compile the package-info file correctly. The 90% correct solution is to have the Groovy compiler ignore the package-info.groovy file, but that may result in annotations being ignored (I don't know if Groovy even has annotations, I don't use Groovy, this is a dependency of Jasper Reports, which I use). Removing the package-info.groovy file doesn't necessarily work, because what's to stop someone (or someone's IDE) from recreating it?

        Let me know if you have questions.

        Thanks.

        Show
        Nick Williams added a comment - Let my provide a few more details... As of and after Java 1.5, package-info.java classes ARE compiled and shipped. This is because packages can retain annotations at runtime, and you annotate a package by annotating the package statement in package-info.java. Comments, annotations and the package statement should be the only things present in a package-info.java file, and the compiler strips out comments as usual and leaves just the package statement and annotations marked as having a runtime retention policy. The package-info.groovy file just had the package statement and comments in it (so it was rather worthless for anything other than JavaDocs), but when compiled, the following appeared in it (when decompiled): package groovy.jmx.builder; interface package -info { } The Java ClassLoader, when it sees this (empty) interface defined in the class file, throws an error because you can't have hyphens in class/interface names. That is the error you get above. So the 100% correct solution is to fix the Groovy compiler to compile the package-info file correctly. The 90% correct solution is to have the Groovy compiler ignore the package-info.groovy file, but that may result in annotations being ignored (I don't know if Groovy even has annotations, I don't use Groovy, this is a dependency of Jasper Reports, which I use). Removing the package-info.groovy file doesn't necessarily work, because what's to stop someone (or someone's IDE) from recreating it? Let me know if you have questions. Thanks.
        Hide
        Jochen Theodorou added a comment -

        with not correctly you mean only the name, right? How is the name supposed to be right looking?

        Show
        Jochen Theodorou added a comment - with not correctly you mean only the name, right? How is the name supposed to be right looking?
        Hide
        Nick Williams added a comment -

        Well, there isn't supposed to be anything other than the package statement and annotations in the package-info.class file. The fact that an interface is defined in it is incorrect to begin with. Apparently, however, the ClassLoader is trying to load it anyway, but choking on the hyphen.

        So, no, I mean that the Groovy compiler shouldn't be putting an interface in the file at all. That is the root of the problem.

        Show
        Nick Williams added a comment - Well, there isn't supposed to be anything other than the package statement and annotations in the package-info.class file. The fact that an interface is defined in it is incorrect to begin with. Apparently, however, the ClassLoader is trying to load it anyway, but choking on the hyphen. So, no, I mean that the Groovy compiler shouldn't be putting an interface in the file at all. That is the root of the problem.
        Hide
        Jochen Theodorou added a comment -

        but there is no package statement in class files. The package is part of the classname. That means I need a classname. Or it is no ordinary class, then it would be good if someone could tell me where to get such a class file, so I can check, or to attach one here (even better)

        Show
        Jochen Theodorou added a comment - but there is no package statement in class files. The package is part of the classname. That means I need a classname. Or it is no ordinary class, then it would be good if someone could tell me where to get such a class file, so I can check, or to attach one here (even better)
        Hide
        Cédric Champeau added a comment -

        Jochen, I've made this simple test : create an annotation like this :

        import java.lang.annotation.ElementType;
        import java.lang.annotation.Retention;
        import java.lang.annotation.RetentionPolicy;
        import java.lang.annotation.Target;
        
        @Retention(RetentionPolicy.CLASS)
        @Target(ElementType.PACKAGE)
        public @interface MyAnnotation {
        }
        

        Then use this annotation in a package-info.java file :

        @groovy.test.MyAnnotation
        package groovy.other;
        

        Then a .class file is generated (there's no .class generated if the package is not annotated). The result of javap is then :

        # javap -s -c -verbose groovy/other/package-info
        Compiled from "package-info.java"
        interface groovy.other.package-info
          SourceFile: "package-info.java"
          RuntimeInvisibleAnnotations: length = 0x6
           00 01 00 06 00 00 
          minor version: 0
          major version: 50
          Constant pool:
        const #1 = class	#7;	//  "groovy/other/package-info"
        const #2 = class	#8;	//  java/lang/Object
        const #3 = Asciz	SourceFile;
        const #4 = Asciz	package-info.java;
        const #5 = Asciz	RuntimeInvisibleAnnotations;
        const #6 = Asciz	Lgroovy/test/MyAnnotation;;
        const #7 = Asciz	groovy/other/package-info;
        const #8 = Asciz	java/lang/Object;
        
        {
        }
        
        
        Show
        Cédric Champeau added a comment - Jochen, I've made this simple test : create an annotation like this : import java.lang.annotation.ElementType; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; import java.lang.annotation.Target; @Retention(RetentionPolicy.CLASS) @Target(ElementType.PACKAGE) public @ interface MyAnnotation { } Then use this annotation in a package-info.java file : @groovy.test.MyAnnotation package groovy.other; Then a .class file is generated (there's no .class generated if the package is not annotated). The result of javap is then : # javap -s -c -verbose groovy/other/ package -info Compiled from " package -info.java" interface groovy.other. package -info SourceFile: " package -info.java" RuntimeInvisibleAnnotations: length = 0x6 00 01 00 06 00 00 minor version: 0 major version: 50 Constant pool: const #1 = class #7; // "groovy/other/ package -info" const #2 = class #8; // java/lang/ Object const #3 = Asciz SourceFile; const #4 = Asciz package -info.java; const #5 = Asciz RuntimeInvisibleAnnotations; const #6 = Asciz Lgroovy/test/MyAnnotation;; const #7 = Asciz groovy/other/ package -info; const #8 = Asciz java/lang/ Object ; { }
        Hide
        Cédric Champeau added a comment -

        Example of package-info.class

        Show
        Cédric Champeau added a comment - Example of package-info.class
        Hide
        Paul King added a comment -

        I have this same setup. The Java and Groovy class files look essentially the same to me. Can anyone confirm that a Java package-info file works with Tomcat or JBoss?

        Show
        Paul King added a comment - I have this same setup. The Java and Groovy class files look essentially the same to me. Can anyone confirm that a Java package-info file works with Tomcat or JBoss?
        Hide
        Cédric Champeau added a comment -

        I created a mini webapp with both a Java annotated package-info.java file and the groovy 1.7.7 library in the classpath. Under Tomcat 7.0.8, I can't see any error nor warning...

        Show
        Cédric Champeau added a comment - I created a mini webapp with both a Java annotated package-info.java file and the groovy 1.7.7 library in the classpath. Under Tomcat 7.0.8, I can't see any error nor warning...
        Hide
        Paul King added a comment -

        Cédric: And you can replicate the ClassFormatError by replacing the Java based package-info class file in your web app with a Groovyc'd class file?

        Show
        Paul King added a comment - Cédric: And you can replicate the ClassFormatError by replacing the Java based package-info class file in your web app with a Groovyc'd class file?
        Hide
        Cédric Champeau added a comment -

        No, I meant I tested both. I can't reproduce at all. I'm starting to think this is not directly related to Groovy, but rather to a "magic library" which performs classpath scanning. Nicolas, how do you deploy your application ? As a war file ? Do you include groovy libs in the application server lib directory ?

        Show
        Cédric Champeau added a comment - No, I meant I tested both. I can't reproduce at all. I'm starting to think this is not directly related to Groovy, but rather to a "magic library" which performs classpath scanning. Nicolas, how do you deploy your application ? As a war file ? Do you include groovy libs in the application server lib directory ?
        Hide
        Paul King added a comment -

        I have reverted the package-info file in 1.8 and trunk (but for now have left it out of the 1_7_X branch). I can find no difference in Java and Groovy generated files when runtime annotations are used. Leaving open for now as we should check further the case when no runtime annotations are supplied. In theory we can leave out the class file altogether in that case - have to double check what we actually do - certainly ant leaves around a stub in that case even though it is not required.

        Show
        Paul King added a comment - I have reverted the package-info file in 1.8 and trunk (but for now have left it out of the 1_7_X branch). I can find no difference in Java and Groovy generated files when runtime annotations are used. Leaving open for now as we should check further the case when no runtime annotations are supplied. In theory we can leave out the class file altogether in that case - have to double check what we actually do - certainly ant leaves around a stub in that case even though it is not required.
        Hide
        Graeme Rocher added a comment -

        Raising the priority of this because it breaks deployment of Grails applications on JBoss 6. See http://jira.grails.org/browse/GRAILS-7553

        Show
        Graeme Rocher added a comment - Raising the priority of this because it breaks deployment of Grails applications on JBoss 6. See http://jira.grails.org/browse/GRAILS-7553
        Hide
        Paul King added a comment - - edited

        Lowering priority for now. Groovy 1.7.9 and 1.7.10 (and future 1.7.* versions) don't have the files which cause the error.

        Groovy 1.8.0 does include the mentioned files as Tomcat and JBoss break on the Java equivalent of those files anyway - so on present information, those containers contain the bug not Groovy. Our thinking was that those app servers would fix the problem before Groovy 1.8 was widely used in a bundled Grails. Please re-raise the priority if you do not believe that to be the case and we can look at workarounds for 1.8 too (we basically throw away doco and potentially annotations - so not the long term approach we would like to take). Besides, I would suspect any users using standard Java javadoc conventions will be caught out by the same issue - though I haven't tried it.

        Show
        Paul King added a comment - - edited Lowering priority for now. Groovy 1.7.9 and 1.7.10 (and future 1.7.* versions) don't have the files which cause the error. Groovy 1.8.0 does include the mentioned files as Tomcat and JBoss break on the Java equivalent of those files anyway - so on present information, those containers contain the bug not Groovy. Our thinking was that those app servers would fix the problem before Groovy 1.8 was widely used in a bundled Grails. Please re-raise the priority if you do not believe that to be the case and we can look at workarounds for 1.8 too (we basically throw away doco and potentially annotations - so not the long term approach we would like to take). Besides, I would suspect any users using standard Java javadoc conventions will be caught out by the same issue - though I haven't tried it.
        Hide
        Graeme Rocher added a comment -

        I don't think its acceptable for us to expect containers to fix this problem. Also since Tomcat is still issuing a warning that makes for an unpleasant experience for users. My recommendation is that a workaround be found for the problem in 1.8.1

        It is not acceptable situation that people cannot deploy Groovy applications to JBoss or Tomcat cleanly. If it is a choice between worse documentation and deploying to containers then the latter wins by a mile.

        Show
        Graeme Rocher added a comment - I don't think its acceptable for us to expect containers to fix this problem. Also since Tomcat is still issuing a warning that makes for an unpleasant experience for users. My recommendation is that a workaround be found for the problem in 1.8.1 It is not acceptable situation that people cannot deploy Groovy applications to JBoss or Tomcat cleanly. If it is a choice between worse documentation and deploying to containers then the latter wins by a mile.
        Hide
        Paul King added a comment -

        Well we should expect them to fix this since Java 1.5 has been out since 2004 and indeed is already EOL - they have certainly had plenty of time to become 1.5 compliant. But agree that we shouldn't rely on it. Rather than delete our doco, we hopefully can tweak our build to remove the troublesome classes after the doco is generated. Of course, users won't be able to use runtime package-level annotations nor bundle their doco if using the recommended 1.5 style in their grails war until the containers are fixed.

        Show
        Paul King added a comment - Well we should expect them to fix this since Java 1.5 has been out since 2004 and indeed is already EOL - they have certainly had plenty of time to become 1.5 compliant. But agree that we shouldn't rely on it. Rather than delete our doco, we hopefully can tweak our build to remove the troublesome classes after the doco is generated. Of course, users won't be able to use runtime package-level annotations nor bundle their doco if using the recommended 1.5 style in their grails war until the containers are fixed.
        Hide
        Graeme Rocher added a comment -

        Is this going to be resolved for 1.8.1? It is causing http://jira.grails.org/browse/GRAILS-7756 and should really be a blocker IMO. Has the tweak to the build been done?

        Show
        Graeme Rocher added a comment - Is this going to be resolved for 1.8.1? It is causing http://jira.grails.org/browse/GRAILS-7756 and should really be a blocker IMO. Has the tweak to the build been done?
        Hide
        Paul King added a comment -

        I have a tweak to the build files which I will commit tonight once I have better connectivity, so it should be in 1.8.1.

        Show
        Paul King added a comment - I have a tweak to the build files which I will commit tonight once I have better connectivity, so it should be in 1.8.1.
        Hide
        Paul King added a comment -

        Build has been modified to remove the package-info.class files from the binary jars for now. They can still be found in the source jars at the moment. Let me know if there are any further problems.

        Show
        Paul King added a comment - Build has been modified to remove the package-info.class files from the binary jars for now. They can still be found in the source jars at the moment. Let me know if there are any further problems.

          People

          • Assignee:
            Paul King
            Reporter:
            Nick Williams
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 24h
              24h
              Remaining:
              Remaining Estimate - 24h
              24h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development