java.lang.ClassFormatError: Duplicate method name thrown in deployment

[glassfishrobot]

On deployment of a Javaee6 application using CDI and EJB 3.1 when using a no interface view ejb that extends an abstract class. I have two ejbs this way, both throw this exception when the same code works in prodution on glassfish 3.0.1

This looks to be a regression of a previously fixed issue and has been in the past few builds

class definition

@Stateless public class AggregatedResultsExporter extends ResultsExporter { ...

trace:

[#|2011-01-18T11:45:00.176+0000|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=80;_ThreadName=Thread-1;|Exception while loading the app : EJB Container initialization error java.lang.RuntimeException: Could not invoke defineClass! at com.sun.ejb.containers.EjbOptionalIntfGenerator.makeClass(EjbOptionalIntfGenerator.java:463) at com.sun.ejb.containers.EjbOptionalIntfGenerator.access$200(EjbOptionalIntfGenerator.java:70) at com.sun.ejb.containers.EjbOptionalIntfGenerator$1.run(EjbOptionalIntfGenerator.java:110) at java.security.AccessController.doPrivileged(Native Method) at com.sun.ejb.containers.EjbOptionalIntfGenerator.loadClass(EjbOptionalIntfGenerator.java:107) at com.sun.ejb.containers.BaseContainer.instantiateOptionalEJBLocalBusinessObjectImpl(BaseContainer.java:3861) at com.sun.ejb.containers.StatelessSessionContainer.initializeHome(StatelessSessionContainer.java:253) at com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:167) at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:234) at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:290) at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:101) at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186) at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:249) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:460) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240) at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370) at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:354) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:369) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1080) at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1260) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1248) at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:453) at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:220) at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168) at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:818) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1008) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:636) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at com.sun.ejb.containers.EjbOptionalIntfGenerator.makeClass(EjbOptionalIntfGenerator.java:460) ... 40 more Caused by: java.lang.ClassFormatError: Duplicate method name&signature in class file com/envisional/de2/__EJB31_GeneratedAggregatedResultsExporterIntf__Bean at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:634) ... 44 more

| #] |

Environment

Ubuntu 10.10 64bit, java version "1.6.0_20"

Affected Versions

[3.1_dev]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/glassfish/issues/15595
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @yaminikb
• Original Issue Closed By:@glassfishrobot

[glassfishrobot]

@glassfishrobot Commented mvatkina said: Do the subclasses override any methods in a base class? Is it possible to add a test case that reproduces the problem?

[glassfishrobot]

@glassfishrobot Commented adriaaaaan said: I've managed to narrow down the case that breaks it, AnEJB.java :

@Stateless public class AnEJB extends AbstractBaseEJB

[glassfishrobot]

@glassfishrobot Commented mvatkina said: Cheng, can your generics support break the described scenario?

[glassfishrobot]

@glassfishrobot Commented cf126330 said: Could be related to an earlier issue http://java.net/jira/browse/GLASSFISH-8319. The fix for that issue was checked in on 2010-06-22.

[glassfishrobot]

@glassfishrobot Commented cf126330 said: Need to fix TypeUtil class to be able to handle generics params that are ParameterizedType.

[glassfishrobot]

@glassfishrobot Commented cf126330 said: How bad is its impact? (Severity) regression of functionality from 3.0.1; Likely to generate a customer support call;

How often does it happen? (Frequency) sometimes. When apps use certain forms of generics params in ejb business methods.

How much effort is required to fix it? (Cost) low, about 1-2 person/days.

What is the risk of fixing it? (Risk) low

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user? The workaround is to avoid using certain forms of generics params in ejb business methods, which imposes undue restrictions on the use of ejb features.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes? Yes.

[glassfishrobot]

@glassfishrobot Commented kasso said: Approved for 3.1

[glassfishrobot]

@glassfishrobot Commented cf126330 said: fix checked in.

[glassfishrobot]

@glassfishrobot Commented adriaaaaan said: Just tried deploying our software on the latest promoted 3.1-b39, issue still not resolved. Is this fix in yet?

[glassfishrobot]

@glassfishrobot Commented cf126330 said: Can you attach a test app? The fix passed the tests including the simple test you included here.

[glassfishrobot]

@glassfishrobot Commented adriaaaaan said: Yes i can confirm the original example i gave now works, theres clearly more to it. I've attached a ghost implementation of the class we use, This fails to deploy in the way i described earlier so if this works, then so should our software.

[glassfishrobot]

@glassfishrobot Commented cf126330 said: From debugging this test app, this is what I gathered, without having the test source:

In superclass ResultsExporter:

protected abstract void getRows(Asynchronous at);

In subclass AggregateResultsExporter:

protected void getRows(Asynchronous a)

{...}

Can you confirm? I will investigate further. Can you also try using parameterized Asynchronous in AggregateResultsExporter?

[glassfishrobot]

@glassfishrobot Commented cf126330 said: The previous fix partially fixed the error. Need to refine it further.

[glassfishrobot]

@glassfishrobot Commented adriaaaaan said: Ah sorry I meant to send the source, yes it is though believe the subclass is also parameterised. There is at least one method where there is a nested parameterised type something like List<Asynchronous>

[glassfishrobot]

@glassfishrobot Commented cf126330 said: With a fix in my local workspace, I was able to deploy the EAR deployTest.ear successfully.

If you can add test source to the EAR, that will be very helpful.

[glassfishrobot]

@glassfishrobot Commented cf126330 said: Attached is the modified TypeUtil class in a jar file. Can you try it in your project? I believe this should fix the error.

Back up $GF/modules/dol.jar

update com/sun/enterprise/deployment/util/TypeUtil.class in $GF/modules/dol.jar with the class in the attached file

restart domain

check server.log for debug logs "In TypeUtil.sameParamTypes?"

[glassfishrobot]

@glassfishrobot Commented adriaaaaan said: Heres the project source

[glassfishrobot]

@glassfishrobot Commented adriaaaaan said: Success! Issue verified as working against the full application. Thanks for your hard work. If only all of the other blocking bugs for me would get resolved then I might be able to eventually use 3.1!

[glassfishrobot]

@glassfishrobot Commented cf126330 said: How bad is its impact? (Severity)

• is a regression of functionality from 3.0.1
• Likely to generate a customer support call

How often does it happen? (Frequency) sometimes.

How much effort is required to fix it? (Cost) low to moderate, about 1-2 person/day.

What is the risk of fixing it? (Risk) low.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user? Yes, avoid using certain forms of generics in EJB business methods. This is hard for users.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes? Yes.

How long has the bug existed in the product? Since July 2010.

Do regression tests exist for this issue? Yes, in ejb devtests.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish? regular tests including SQE tests and CTS tests.

When will a tested fix be ready for integration? In 1-2 days.

[glassfishrobot]

@glassfishrobot Commented kasso said: Approved for RC2.

[glassfishrobot]

@glassfishrobot Commented cf126330 said: Fix checked into trunk: revision 44825 and into 3.1 branch: revision 44826

[glassfishrobot]

@glassfishrobot Commented File: deployTest.ear Attached By: adriaaaaan

[glassfishrobot]

@glassfishrobot Commented File: deployTest.zip Attached By: adriaaaaan

[glassfishrobot]

@glassfishrobot Commented File: TypeUtil.jar Attached By: cf126330

[glassfishrobot]

@glassfishrobot Commented Was assigned to cf126330

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA GLASSFISH-15595

[glassfishrobot]

@glassfishrobot Commented Reported by adriaaaaan

[glassfishrobot]

@glassfishrobot Commented Marked as fixed on Wednesday, February 2nd 2011, 12:45:14 am