Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 365385

Summary:	Weaver throws ClassNotFoundException even though it previously found the class
Product:	z_Archived	Reporter:	David Bernstein <dbb.posting>
Component:	Eclipselink	Assignee:	Tom Ware <tom.ware>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	major
Priority:	P2	CC:	abassouk, dbb.posting, eclipselink.orm-inbox, erangaj, tom.ware
Version:	unspecified	Flags:	erangaj: pmc_approved+
Target Milestone:	---
Hardware:	All
OS:	All
See Also:	https://bugs.eclipse.org/bugs/show_bug.cgi?id=355016 https://bugs.eclipse.org/bugs/show_bug.cgi?id=363238
Whiteboard:

Description David Bernstein

2011-12-01 21:21:33 EST

Build Identifier: 2.3.0.v20110604-r9504

I was trying to migrate my application from Glassfish 3.0.1 (EclipseLink 2.0.1.v20100213-r6600) to Glassfish 3.1.1 (EclipseLink 2.3.0.v20110604-r9504).  When I deployed my previous EAR to the new version, I started getting errors about weaving not being able to find some classes. (At first I missed this error because the ClassNotFoundException was just a warning and the EAR was reported as successfully deployed by Glassfish; it wasn't until I looked at the log closely that I noticed the error!) I investigated and the messages seemed perhaps reasonable because the EJB entities referred to some classes that were in a JAR in the EAR's lib directory rather than in the EJB module. (However, this had worked in GF 3.0.1 EL 2.0.1 .) I changed the packaging to put all referred-to classes in the EJB module but I still got ClassNotFoundException errors.  I tried different ways to compile and package the classes but none got rid of the problem.

Here is a snippet of relevant error messages from the log:

<<<<
[#|2011-12-01T16:22:06.600-0800|INFO|glassfish3.1.1|javax.enterprise.system.core.classloading.com.sun.enterprise.loader|_ThreadID=17;_ThreadName=Thread-2;|com.orgmob.orgmobilist.server.ejb.ent.User actually got transformed|#]

[#|2011-12-01T16:22:06.622-0800|WARNING|glassfish3.1.1|org.eclipse.persistence.session.file:/C:/java/glassfish/v3.1.1/glassfish/domains/domain1/applications/orgmob/orgmobejb_jar/_orgmob.weaver|_ThreadID=17;_ThreadName=Thread-2;|Weaver encountered an exception while trying to weave class com/orgmob/orgmobilist/server/ejb/ent/Email.  The exception was: java.lang.RuntimeException: java.lang.ClassNotFoundException: cd.j.store.Fld not found by org.eclipse.persistence.asm [194]|#]

[#|2011-12-01T16:22:06.634-0800|WARNING|glassfish3.1.1|org.eclipse.persistence.session.file:/C:/java/glassfish/v3.1.1/glassfish/domains/domain1/applications/orgmob/orgmobejb_jar/_orgmob.weaver|_ThreadID=17;_ThreadName=Thread-2;|Weaver encountered an exception while trying to weave class com/orgmob/orgmobilist/server/ejb/ent/Device.  The exception was: java.lang.RuntimeException: java.lang.ClassNotFoundException: cd.j.store.FldInt not found by org.eclipse.persistence.asm [194]|#]
>>>>

The strange thing is that the User class appears to be successfully woven, even though it refers to the Fld and FldInt classes that can't be found for the Email and Device classes.  The classes that can't be found are *not* EJB themselves and are all from one package.  It appears that classes from other packages that are similarly used are properly found. The classes that can't be found are stable from one deployment of the EAR to the next. Here is one of the classes that intermittently (i.e. only by some referring classes) can't be found in its entirety:

<<<<
    package cd.j.store;
    public interface Fld {
        public byte getType();
    }
>>>>

I have this problem both on Linux and Windows 7.

I couldn't find a log setting that would cause the weaver to display a stack trace or any more useful information.

I can't just post the app to bugzilla, but would be happy to work with somebody to get more log information and perhaps to create a test case that duplicates the problem.

On its face, this problem appears similar to bug 355016, which was closed as invalid in September 2011 due to lack of re-creation instructions.

The impact for me is that I'm unable to migrate to the current version of Glassfish and EclipseLink and am stuck on GF 3.0.1 and EL 2.0.1.


Reproducible: Always

Steps to Reproduce:
I can't just submit my entire application to bugzilla.  I would be happy to work with somebody to get extra debugging information and possibly to create a smaller test case.

Comment 1 David Bernstein

2011-12-02 18:24:12 EST

I spent some time trying to transform my application into a test case. I was successful in creating a much smaller and lobotomized application ("eltcWeaverFailsEmail.ear") which exhibits the same behavior. Interestingly, as I was trying to shrink the test case, when I removed a portion of the body of a method (in the class "Email" where the weaving problem occurs) with no apparent relevant references in the deleted code, EclipseLink stopped complaining ("eltcEmailTransformed.ear").  I can send both of these EAR files directly to somebody investigating the bug. This behavior was consistent through multiple runs. (There are other missing classes referenced in the code that do not affect whether weaving fails.)

RUN COMMAND:

c:\eclipse\workspace\eltc>asadmin deploy eltcWeaverFailsEmail.ear 
asadmin deploy eltcWeaverFailsEmail.ear 
Application deployed with name eltcWeaverFailsEmail.
Command deploy executed successfully.

c:\eclipse\workspace\eltc>

SERVER.LOG:

***here's the ClassNotFoundException that occured trying to weave the Email class ==>
[#|2011-12-02T15:03:44.481-0800|WARNING|glassfish3.1.1|org.eclipse.persistence.session.file:/C:/java/glassfish/v3.1.1/glassfish/domains/domain1/applications/eltcWeaverFailsEmail/orgmobejb_jar/_orgmob.weaver|_ThreadID=23;_ThreadName=Thread-2;|Weaver encountered an exception while trying to weave class com/orgmob/orgmobilist/server/ejb/ent/Email.  The exception was: java.lang.RuntimeException: java.lang.ClassNotFoundException: cd.j.store.Fld not found by org.eclipse.persistence.asm [194]|#]

[#|2011-12-02T15:03:44.495-0800|INFO|glassfish3.1.1|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=23;_ThreadName=Thread-2;|Portable JNDI names for EJB EmailDAOBean : [java:global/eltcWeaverFailsEmail/orgmobejb/EmailDAOBean, java:global/eltcWeaverFailsEmail/orgmobejb/EmailDAOBean!com.orgmob.orgmobilist.server.ejb.sif.EmailDAO]|#]

[#|2011-12-02T15:03:44.598-0800|INFO|glassfish3.1.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=23;_ThreadName=Thread-2;|WEB0671: Loading application [eltcWeaverFailsEmail#om.war] at [om]|#]

[#|2011-12-02T15:03:44.617-0800|INFO|glassfish3.1.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=23;_ThreadName=Thread-2;|eltcWeaverFailsEmail was successfully deployed in 610 milliseconds.|#]

*BUT* RUN COMMAND:

c:\eclipse\workspace\eltc>asadmin undeploy eltcWeaverFailsEmail
asadmin undeploy eltcWeaverFailsEmail
Command undeploy executed successfully.

c:\eclipse\workspace\eltc>asadmin deploy eltcEmailTransformed.ear 
asadmin deploy eltcEmailTransformed.ear 
Application deployed with name eltcEmailTransformed.
Command deploy executed successfully.

c:\eclipse\workspace\eltc>

AND GET SERVER.LOG:

****** tiny bit of code deleted from Email class and it's processed without apparent problem ==>
[#|2011-12-02T15:06:14.815-0800|INFO|glassfish3.1.1|javax.enterprise.system.core.classloading.com.sun.enterprise.loader|_ThreadID=18;_ThreadName=Thread-2;|com.orgmob.orgmobilist.server.ejb.ent.Email actually got transformed|#]

[#|2011-12-02T15:06:14.832-0800|INFO|glassfish3.1.1|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=18;_ThreadName=Thread-2;|Portable JNDI names for EJB EmailDAOBean : [java:global/eltcEmailTransformed/orgmobejb/EmailDAOBean!com.orgmob.orgmobilist.server.ejb.sif.EmailDAO, java:global/eltcEmailTransformed/orgmobejb/EmailDAOBean]|#]

[#|2011-12-02T15:06:14.927-0800|INFO|glassfish3.1.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=18;_ThreadName=Thread-2;|WEB0671: Loading application [eltcEmailTransformed#om.war] at [om]|#]

[#|2011-12-02T15:06:14.944-0800|INFO|glassfish3.1.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=18;_ThreadName=Thread-2;|eltcEmailTransformed was successfully deployed in 640 milliseconds.|#]

Comment 2 Tom Ware

2011-12-05 09:07:08 EST

If you cannot post your classes that recreate this problem here, I'd be keep them until someone looks at this issue.  At the moment, I am leaning towards targetting this bug for our next patch (2.3.3) and we would do some more investigation as we started to work on that release.  If you want to send the recreation, you can use the email address associated with this posting. Else, someone will post a request for more information to this bug when we start looking at it.

Comment 3 David Bernstein

2011-12-06 15:02:36 EST

I've sent the EAR files referenced in comment 1 to Tom Ware.

Comment 4 Tom Ware

2011-12-06 15:06:49 EST

To the person who ultimately looks into addressing this bug:  Please contact me for the recreation at the email address I posted this comment with.

Comment 5 Tom Ware

2011-12-14 15:36:57 EST

Setting target and priority.  See the following page for the meanings of these fields:

http://wiki.eclipse.org/EclipseLink/Development/Bugs/Guidelines

Community: Please vote for this bug if it is important to you.  Votes are one of the main criteria we use to determine which bugs to fix next.

Comment 6 Tom Ware

2012-02-22 09:22:40 EST

See also: https://bugs.eclipse.org/bugs/show_bug.cgi?id=363238

Comment 7 Tom Ware

2012-02-24 14:20:44 EST

*** Bug 363238 has been marked as a duplicate of this bug. ***

Comment 8 Tom Ware

2012-03-12 09:03:59 EDT

I believe this is fixed by the fix for 370975.

*** This bug has been marked as a duplicate of bug 370975 ***

Comment 9 Eclipse Webmaster

2022-06-09 10:09:46 EDT

The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink