This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 195113 - Annotation processor throwing up, eclipselink/javaeeapi conflict
Summary: Annotation processor throwing up, eclipselink/javaeeapi conflict
Status: RESOLVED WORKSFORME
Alias: None
Product: javaee
Classification: Unclassified
Component: Code (show other bugs)
Version: 7.0
Hardware: PC Windows 7
: P3 normal (vote)
Assignee: Sergey Petrov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-07 00:54 UTC by Chiana
Modified: 2012-04-13 12:03 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
messages.log (50.13 KB, text/plain)
2011-02-07 00:56 UTC, Chiana
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chiana 2011-02-07 00:54:26 UTC
[ BUILD # : 201102060000 ]
[ JDK VERSION : 1.6.23 ]

This compiled properly when the project was temporarly closed about a week ago,
I've been working on a solution for bug #188514 for a while. When I reopened
the project(s) and tried to compile the following was displayed in the output
window;

Created dir: P:\reciete4\RecieteServer\RecieteServer-ejb\build\classes
Copying 2 files to
P:\reciete4\RecieteServer\RecieteServer-ejb\build\classes\META-INF
Created dir: P:\reciete4\RecieteServer\RecieteServer-ejb\build\empty
Created dir:
P:\reciete4\RecieteServer\RecieteServer-ejb\build\generated-sources\ap-source-ou
tput
Compiling 25 source files to
P:\reciete4\RecieteServer\RecieteServer-ejb\build\classes
Note: Creating static metadata factory ...
Note: Building metadata class for round element: remote.GlobdataBean
Note: Building metadata class for round element: ent.SystemBeans.ErrorHandler
Note: Building type parameter element: T
Note: Building metadata class for round element: ent.SystemBeans.FilterList
Note: Building metadata class for round element: ent.EntityClasses.Storage
Note: Building metadata class for round element:
ent.SystemBeans.ServiceradBean
Note: Building metadata class for round element: ent.EntityClasses.Servicerad
Note: Building metadata class for round element: ent.EntityClasses.Service
Note: Building metadata class for round element: ent.EntityClasses.Artreg
Note: Building metadata class for round element: ent.structs.recieteLine
Note: Building metadata class for round element: reciete.recieteLine
Note: Building metadata class for round element: init.programInit
Note: Building metadata class for round element: misc.TimedStorage
Note: Building metadata class for round element: init.Ready
Note: Building metadata class for round element: ent.SystemBeans.SingleFilter
Note: Building metadata class for round element: ent.EntityClasses.Kvitton
Note: Building metadata class for round element: remote.ArtBean
Note: Building metadata class for round element: ent.EntityClasses.Kund
Note: Building metadata class for round element: ent.EntityClasses.Users
Note: Building metadata class for round element: remote.ServiceBean
Note: Building metadata class for round element: ent.SystemBeans.UserBean
Note: Building metadata class for round element: remote.KvittoBean
Note: Building metadata class for round element: remote.KundBean


An annotation processor threw an uncaught exception.
Consult the following stack trace for details.
java.lang.ClassFormatError: Absent Code attribute in method that is not native
or abstract in class file javax/persistence/PersistenceException
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
	at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
	at java.lang.Class.getDeclaredFields0(Native Method)
	at java.lang.Class.privateGetDeclaredFields(Class.java:2291)
	at java.lang.Class.getDeclaredField(Class.java:1880)
	at
org.eclipse.persistence.internal.security.PrivilegedAccessHelper.findDeclaredFie
ld(PrivilegedAccessHelper.java:46)
	at
org.eclipse.persistence.internal.security.PrivilegedAccessHelper.getField(Privil
egedAccessHelper.java:190)
	at org.eclipse.persistence.internal.helper.Helper.getField(Helper.java:928)
	at
org.eclipse.persistence.internal.descriptors.InstanceVariableAttributeAccessor.i
nitializeAttributes(InstanceVariableAttributeAccessor.java:100)
	at
org.eclipse.persistence.mappings.DatabaseMapping.preInitialize(DatabaseMapping.j
ava:1274)
	at
org.eclipse.persistence.mappings.foundation.AbstractDirectMapping.preInitialize(
AbstractDirectMapping.java:949)
	at
org.eclipse.persistence.oxm.mappings.XMLDirectMapping.preInitialize(XMLDirectMap
ping.java:413)
	at
org.eclipse.persistence.oxm.XMLDescriptor.preInitialize(XMLDescriptor.java:463)

	at
org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.initializeDescript
ors(DatabaseSessionImpl.java:434)
	at
org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.initializeDescript
ors(DatabaseSessionImpl.java:407)
	at
org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.postConnectDatasou
rce(DatabaseSessionImpl.java:672)
	at
org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.login(DatabaseSess
ionImpl.java:633)
	at org.eclipse.persistence.oxm.XMLContext.<init>(XMLContext.java:213)
	at org.eclipse.persistence.oxm.XMLContext.<init>(XMLContext.java:179)
	at org.eclipse.persistence.oxm.XMLContext.<init>(XMLContext.java:169)
	at
org.eclipse.persistence.internal.jpa.modelgen.objects.PersistenceXMLMappings.cre
ateXMLContext(PersistenceXMLMappings.java:123)
	at
org.eclipse.persistence.internal.jpa.modelgen.objects.PersistenceUnitReader.init
PersistenceUnits(PersistenceUnitReader.java:168)
	at
org.eclipse.persistence.internal.jpa.modelgen.objects.PersistenceUnitReader.<ini
t>(PersistenceUnitReader.java:71)
	at
org.eclipse.persistence.internal.jpa.modelgen.CanonicalModelProcessor.process(Ca
nonicalModelProcessor.java:376)
	at
com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacPro
cessingEnvironment.java:625)
	at
com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(Ja
vacProcessingEnvironment.java:554)
	at
com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProc
essingEnvironment.java:699)
	at
com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:981)

	at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:727)
	at com.sun.tools.javac.main.Main.compile(Main.java:353)
	at com.sun.tools.javac.main.Main.compile(Main.java:279)
	at com.sun.tools.javac.main.Main.compile(Main.java:270)
	at com.sun.tools.javac.Main.compile(Main.java:69)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
a:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.apache.tools.ant.taskdefs.compilers.Javac13.execute(Javac13.java:56)
	at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:1134)
	at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:912)
	at org.netbeans.modules.java.source.ant.JavacTask.execute(JavacTask.java:136)
	at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
	at sun.reflect.GeneratedMethodAccessor61.invoke(Unknown Source)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
a:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
	at org.apache.tools.ant.Task.perform(Task.java:348)
	at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:68)
	at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
	at sun.reflect.GeneratedMethodAccessor61.invoke(Unknown Source)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
a:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
	at org.apache.tools.ant.Task.perform(Task.java:348)
	at
org.apache.tools.ant.taskdefs.MacroInstance.execute(MacroInstance.java:398)
	at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
	at sun.reflect.GeneratedMethodAccessor61.invoke(Unknown Source)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
a:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
	at org.apache.tools.ant.Task.perform(Task.java:348)
	at org.apache.tools.ant.Target.execute(Target.java:390)
	at org.apache.tools.ant.Target.performTasks(Target.java:411)
	at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
	at
org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecut
or.java:38)
	at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
	at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442)
	at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
	at sun.reflect.GeneratedMethodAccessor61.invoke(Unknown Source)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
a:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
	at org.apache.tools.ant.Task.perform(Task.java:348)
	at org.apache.tools.ant.Target.execute(Target.java:390)
	at org.apache.tools.ant.Target.performTasks(Target.java:411)
	at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
	at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
	at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:
41)
	at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
	at
org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:284)
	at
org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:539)
	at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:154)
P:\reciete4\RecieteServer\nbproject\build-impl.xml:211: The following error
occurred while executing this line:
P:\reciete4\RecieteServer\RecieteServer-ejb\nbproject\build-impl.xml:521: The
following error occurred while executing this line:
P:\reciete4\RecieteServer\RecieteServer-ejb\nbproject\build-impl.xml:222:
Compile failed; see the compiler error output for details.
BUILD FAILED (total time: 9 seconds)

This has compiled and worked just fine earlier, so this must definatly be a
showstopper.
Comment 1 Chiana 2011-02-07 00:56:45 UTC
Created attachment 105693 [details]
messages.log

This is the messages.log where the error occured.
Comment 2 Sergey Petrov 2011-02-07 01:06:56 UTC
It there a way to provide sample project?
Comment 3 Chiana 2011-02-07 01:19:23 UTC
Yes, if you can guarantee total security I can let you have a copy of the entire project.
Comment 4 Sergey Petrov 2011-02-07 01:30:07 UTC
just tried (but with 110204 but it should contain all related changes I know) alll entities from jdbc/sample and build works, it may be something specific to specific entities/config.

It's good it you can try to remove all content you don't want to share and keep only 1-2 entities and if it' will be reproducible it best way. But if no way you can send you project by email, but it may need to  be shared with 1-2 more developers on nb side and possible 1-2 more developers on eclipselink side.

Do you use your own eclipselink library anywhere or just bundled with nb?
Comment 5 Sergey Petrov 2011-02-07 01:31:18 UTC
Anyway I'll try with more fresh sources tomorrow.
Comment 6 Sergey Petrov 2011-02-07 11:30:21 UTC
I can reproduce with provided project with 110204, also if I remove modelgen jar from ejb module libraries project is compilable as well if switch off "enable ap" in ejb module project properties.
Comment 7 Sergey Petrov 2011-02-07 11:49:32 UTC
even if i remove all classes from ejb module and generate only one sample entity in ejb module, I'll get this exception.

I'm not sure why it was working before but in real it's  classpath conflict between javaee6 api jar and eclipselink jars.
Comment 8 Sergey Petrov 2011-02-07 12:03:51 UTC
Can be easily reproduced by:
create ejb module on gf3, generate entities from sample db, add javaee-6.0-api library. clean&build  - > exception.
Comment 9 Sergey Petrov 2011-02-07 12:10:59 UTC
I have exactly the same exception in 6.9.1
Comment 10 Sergey Petrov 2011-02-07 12:12:04 UTC
The only question if it's valid use-case to use both libraries or not.
David, do you have any ideas? May it be some issue with javaee-6.0-api.jar?
Comment 11 Chiana 2011-02-07 12:44:28 UTC
(In reply to comment #9)
> I have exactly the same exception in 6.9.1

Strange, then the $50000 question is, why did this work before? And, why does it become a showstopper now?
Comment 12 Sergey Petrov 2011-02-07 12:55:31 UTC
I have it(exactly the same exception) with my steps in 6.9.1, in your case it's likely classpath order was changed so it was working occationally. But it's not 100%, I can try with some older 7.0 build also.
Comment 13 Chiana 2011-02-07 12:57:50 UTC
(In reply to comment #11)
> (In reply to comment #9)
> > I have exactly the same exception in 6.9.1
> Strange, then the $50000 question is, why did this work before? And, why does
> it become a showstopper now?

One question that come to my mind is; what are those libraries doing there in
the first place? They should not be there as the entitymanager in the GF server
do not use eclipselink, in fact, the entire project(s) do not use eclipselink
at all, infact it works as it should with those libraries removed, atleast what
I can see with a simple testrun. A previous version of this program used
eclipselink as it did all it's database access by itself but in this version
all database access is done by the entitymanager in glassfish, what that uses
to actually access the database should not affect the recieteserver project.
Comment 14 Sergey Petrov 2011-02-07 13:01:23 UTC
Eclipselink is used to generate metamodel for entities and it's default behavior in 7.0. Hope it works in most cases, and in some "corner" cases it's always possible to disable generation. But we have no much feedback yet.
Comment 15 Chiana 2011-02-07 13:30:36 UTC
(In reply to comment #14)
> Eclipselink is used to generate metamodel for entities and it's default
> behavior in 7.0. Hope it works in most cases, and in some "corner" cases it's
> always possible to disable generation. But we have no much feedback yet.

Hmm. but if they were used a clean&build action would make the project to not run at all, as I removed them from properties->libraries->processor, but it does, thou I get an NPE in the client, I have to make furter check in ServiceBean, that one is the most likley to use MetaModel's.
Comment 16 Sergey Petrov 2011-02-07 13:38:58 UTC
In general is you have no usage of {entity.name}_ classes it should work the same with and without static metamodel generation. internally dynamic metamodel generation may present but it's internal eclipselink level.
Comment 17 Chiana 2011-02-07 13:57:01 UTC
Apparently msSql driver does not work without the meta's, that's why I got the NPE's. This means either putting those libraries back or device some other method to generate the meta's before loading the entitymanager.

Any suggestions/pointers?
Comment 18 Sergey Petrov 2011-02-07 14:03:45 UTC
quite strange, jpa2.0 do not require metamodel generation, it's always optional, it's also strange if some driver require static metamodel to be generated.
I would like to wait if David know is there is any issue with ee6-api jar also as it seems strange to have conflict here.
Comment 19 Sergey Petrov 2011-02-07 14:58:50 UTC
Playing around:
If i move javax.persistence classes from eclipsleink-javax.persistence jar to javaee-api-6.0.jar jar as is, I'm able to compile the project.
Comment 20 Chiana 2011-02-07 16:18:44 UTC
(In reply to comment #19)
> Playing around:
> If i move javax.persistence classes from eclipsleink-javax.persistence jar to
> javaee-api-6.0.jar jar as is, I'm able to compile the project.

Tried adding the libraries to the "normal" library collection and moved them to the top, it also compiles.
Comment 21 Sergey Petrov 2011-02-08 13:51:29 UTC
as there are number of workarounds it's good and at least not showstopper.

but looks like all api jars need to be updated to contain proper jpa2.0 api.
Comment 22 David Konecny 2011-02-08 20:12:58 UTC
"ClassFormatError: Absent Code attribute in method..." is always indication that javaee-api-6.0.jar is used for runtime execution. The jar contains only method signatures (method bodies are stripped) and is suitable only for compilation. In future versions of javac there might be better error message.

The problem here is that javaee-api-6.0.jar is on classpath before EclipseLink jars and when EclipseLink annotation processor is started classes from javaee-api-6.0.jar are used instead of classes from EclipseLink. First thing is that javaee-api-6.0.jar should be removed from classpath of EJB project - it should not be needed as EJB project has an Application server selected and the project takes EE 6 APIs from that server.

Chiana, what was your reason to add that library to your project?

Overall this is user error, but I wonder whether we should/could include some check somewhere which would at least warn user that it is not what they want. What do you think guys?
Comment 23 Chiana 2011-02-08 20:28:54 UTC
I suspect they actually are leftover from an earlier stage in the project where the client and the server part were integrated, I at one point reallized that when we take this into service we need a client/server relation as it must be accessed from different places simultanesly. In the earlier version I used first Eclipselink and later switched to Hibernate, I guess those libraries have been there all the time... I just wonder why it elects to kick-back now...

As for giving a warning I think that would be an apropriate fix...

And, don't forget to give Dusan Balek a copy of the code so he can look into the warnings in GlobdataBean concerning bug #194791.
Comment 24 Sergey Petrov 2011-02-09 12:41:00 UTC
>Tried adding the libraries to the "normal" library collection

the same works for processors libraries, i.e. after move of "compile classpath" down, I'm able to compile the project.
Will look to fix it on persistence side by initial addition of provider libraries on top. If will be possible  It will not fix conflict in general but nb will not create it in this place.
Comment 25 Sergey Petrov 2011-02-09 17:38:21 UTC
Unfortunately it's quite different approach in project properties and usual libraries addition to classpath.
Comment 26 Petr Jiricka 2011-10-05 13:27:39 UTC
Is this still a problem, and can we somehow fix it? If not, then we may need to close as WONTFIX.
Comment 27 Sergey Petrov 2011-10-05 13:46:21 UTC
As I remember I wasn't able to find any api to select added library position in classpath and postpone general solution as there should be easy workaround and also it may  be user error to use javaee-api-6.0.jar at runtime. I haven't try to look from "warn user" approach. As there was no changes I know about it should be an issue in 7.1 also.
Comment 28 Petr Jiricka 2012-04-13 12:03:04 UTC
I am not aware of any situation when the IDE adds javaee-api-6.0.jar on classpath in Ant-based projects, so I assume this was added by the user and this is a user error. I am closing as WORKSFORME, let's reopen if we find any situation when the IDE guides the user the wrong way.