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.
[ 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.
Created attachment 105693 [details] messages.log This is the messages.log where the error occured.
It there a way to provide sample project?
Yes, if you can guarantee total security I can let you have a copy of the entire project.
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?
Anyway I'll try with more fresh sources tomorrow.
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.
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.
Can be easily reproduced by: create ejb module on gf3, generate entities from sample db, add javaee-6.0-api library. clean&build - > exception.
I have exactly the same exception in 6.9.1
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?
(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?
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.
(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.
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.
(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.
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.
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?
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.
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.
(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.
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.
"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?
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.
>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.
Unfortunately it's quite different approach in project properties and usual libraries addition to classpath.
Is this still a problem, and can we somehow fix it? If not, then we may need to close as WONTFIX.
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.
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.