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

Details

Type: Bug
Status: Closed
Priority: 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

Number of attachments :
3

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]

Options
- Sort By Name
- Sort By Date
- Ascending
- Descending
- Download All

Attachments

MyAnnotation.java

13/Feb/11 1:58 PM

0.4 kB

Cedric Champeau
package-info.class

13/Feb/11 1:58 PM

0.2 kB

Cedric Champeau
package-info.java

13/Feb/11 1:58 PM

0.1 kB

Cedric Champeau

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Guillaume Laforge added a comment - 11/Feb/11 10:18 AM

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

Show

Guillaume Laforge added a comment - 11/Feb/11 10:18 AM I've removed the offending package-info.groovy file.

Hide

Permalink

Nicholas Williams added a comment - 11/Feb/11 10:28 AM

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

Show

Nicholas Williams added a comment - 11/Feb/11 10:28 AM I figured that would be the only needed change. Thanks!

Hide

Permalink

Paul King added a comment - 11/Feb/11 9:06 PM

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 - 11/Feb/11 9:06 PM 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

Permalink

Paul King added a comment - 13/Feb/11 2:57 AM

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 - 13/Feb/11 2:57 AM 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

Permalink

Cedric Champeau added a comment - 13/Feb/11 6:24 AM

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

Cedric Champeau added a comment - 13/Feb/11 6:24 AM 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

Permalink

Nicholas Williams added a comment - 13/Feb/11 10:12 AM

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

Nicholas Williams added a comment - 13/Feb/11 10:12 AM 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

Permalink

blackdrag blackdrag added a comment - 13/Feb/11 11:56 AM

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

Show

blackdrag blackdrag added a comment - 13/Feb/11 11:56 AM with not correctly you mean only the name, right? How is the name supposed to be right looking?

Hide

Permalink

Nicholas Williams added a comment - 13/Feb/11 12:01 PM

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

Nicholas Williams added a comment - 13/Feb/11 12:01 PM 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

Permalink

blackdrag blackdrag added a comment - 13/Feb/11 1:20 PM

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

blackdrag blackdrag added a comment - 13/Feb/11 1:20 PM 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

Permalink

Cedric Champeau added a comment - 13/Feb/11 1:56 PM

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

Cedric Champeau added a comment - 13/Feb/11 1:56 PM 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

Permalink

Cedric Champeau added a comment - 13/Feb/11 1:58 PM

Example of package-info.class

Show

Cedric Champeau added a comment - 13/Feb/11 1:58 PM Example of package-info.class

Hide

Permalink

Paul King added a comment - 13/Feb/11 4:10 PM

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 - 13/Feb/11 4:10 PM 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

Permalink

Cedric Champeau added a comment - 15/Feb/11 3:29 PM

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

Cedric Champeau added a comment - 15/Feb/11 3:29 PM 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

Permalink

Paul King added a comment - 16/Feb/11 3:49 PM

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 - 16/Feb/11 3:49 PM 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

Permalink

Cedric Champeau added a comment - 16/Feb/11 4:40 PM

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

Cedric Champeau added a comment - 16/Feb/11 4:40 PM 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

Permalink

Paul King added a comment - 25/Feb/11 3:37 PM

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 - 25/Feb/11 3:37 PM 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

Permalink

Graeme Rocher added a comment - 12/Jun/11 3:28 PM

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 - 12/Jun/11 3:28 PM Raising the priority of this because it breaks deployment of Grails applications on JBoss 6. See http://jira.grails.org/browse/GRAILS-7553

Hide

Permalink

Paul King added a comment - 12/Jun/11 3:44 PM - 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 - 12/Jun/11 3:44 PM - 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

Permalink

Graeme Rocher added a comment - 13/Jun/11 3:48 AM

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 - 13/Jun/11 3:48 AM 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

Permalink

Paul King added a comment - 13/Jun/11 7:48 AM

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 - 13/Jun/11 7:48 AM 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

Permalink

Graeme Rocher added a comment - 19/Jul/11 3:15 PM

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 - 19/Jul/11 3:15 PM 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

Permalink

Paul King added a comment - 19/Jul/11 4:49 PM

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 - 19/Jul/11 4:49 PM 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

Permalink

Paul King added a comment - 20/Jul/11 3:19 AM

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 - 20/Jul/11 3:19 AM 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:

Nicholas Williams

Vote (1)

Watch (1)

Dates

Created:

10/Feb/11 8:35 PM

Updated:

21/Jul/11 7:06 PM

Resolved:

20/Jul/11 3:19 AM

Time Tracking

Estimated:

Remaining:

Logged:

Not Specified