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.
Hello, When using the entity class wizard, the generated code places the table-fields/bean-properties annotation in the bean properties declarations. This makes the project fail deployment. I went to the glassfish project, and all their examples (https://glassfish.dev.java.net/javaee5/persistence/persistence-example.html) place the annotation just above the getter methods. I don't know if this is part of the specification, but I think the IDE should generate the code just as the examples in glassfish. the other problem that I found that makes the project fail deployment is in the persistence.xml file. The IDE places a "version" attribute in the root "persistence" element. Glassfish complains about the attribute and says it is not a valid attribute. When I take the attribute out, the deployment proceeds. If what I mean is not clear, just let me know and I can submit a little project as a sample.
It looks like you are using some very old build of GlassFish. Can you check it and post here?
Here is the glassfish build version: Sun Java System Application Server Platform Edition 9.0 Beta (build b32g) I'll download the latest build and try it again and post the results. Hopefully, that problem has been fixed.
Problem still happens with latest build.
I looked at the persistence specification final release. Section 9.1.5 addresses column annotations, and although it doesn't explicitly say where the annotations are to be placed, they put them just before the getter/setter methods and not before the bean property declaration. So, I guess, the wizard should follow that and place the annotations just above the getter/setter methods. Also, I noticed that in the generated code for the equal method won't wotk (as the comment says) if ids are not set. Maybe the generated code could be this: Assume a Person entity class where id is the primary key. public boolean equals(Object object) { if (object == null) return false; if (object instanceof Person) { Person other = (Person) object; if (id == null && other.id == null) return true; if (id == null || other.id == null) return false; return id.equals(other.id); } else return false; } I think that would cover all cases: 1. If there is no Person object, it cannot be equal. 2. If it is not of type Person, it cannot be equal. 3. If both are of type Person, then they are considered equal iff both theirs are equal.
The spec lets you choose field or property access. If field, the annotations go above the fields. If property, they go above the get/set methods. NB generates entities using field access. equals/hashCode suggestions should be discussed in issue 77355.
Ok. Now I see the distinction: whether it's field or property access. So to the relevant point: I still don't why the project is failing deployment. I'm running it with the lastest milestone (build 48).
Why is the project failing deployment? Do you have a stack trace or error log? Do you know if it's due to the annotation location or the version attribute? I suggest updating the issue summary with the remaining problem.
I'm attaching the glassfish logs, the netbeans log, and the project.
Created attachment 31164 [details] Netbeans log file
Created attachment 31165 [details] Glassfish log file
Created attachment 31166 [details] NetBeans Project Files
I've forwarded the log to 2 glassfish experts and they would like you to check if: 1) You have a path to a JRE installation specified instead of a path to full JDK installation (and as the result javac.exe was not found) OR, if not 2) classpath is too long
Here is the echo output for my path system variable: C:\WINDOWS;C:\WINDOWS\system32;C:\WINDOWS\system32\WBEM;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;C:\Program Files\QuickTime\QTSystem\;C:\Program Files\MySQL\MySQL Server 5.0\bin;C:\Program Files\Subversion\bin And the only system variable that contains a path to the java installation is java.home. Here is the echo output: C:\Program Files\Java\jdk1.5.0_06\jre If I try to execute javac.exe from a DOS prompt, this is what I get: C:\WINDOWS\SYSTEM32>javac 'javac' is not recognized as an internal or external command, operable program or batch file. I hope this helps. Let me know if there are any other things you need to know about the system configuration.
Okay, the latest hypothesis is that you have a Windows variable called java.home (not JAVA_HOME). Please try this: specify Windows environment variable called JAVA_HOME, point it to C:\Program Files\Java\jdk1.5.0_06 and then reinstall Glassfish. After that should start the default server and check the log file - javac related exceptions should be gone then and then can check if the deployment problem still occurs or not.
Ok... Indeed, the variable name was java.hom and not JAVA_HOME. I uninstalled glassfish, netbeans, and the jdk also to start fresh. Here are the builds for each that I installed: java: from command java -version java version "1.5.0_07" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03) Java HotSpot(TM) Client VM (build 1.5.0_07-b03, mixed mode, sharing) netbeans: from netbeans log file. Product Version = NetBeans 5.5 Beta (Build 200605090801) Operating System = Windows XP version 5.1 running on x86 glassfish: from administration console Sun Java System Application Server Platform Edition 9.0 (build b48) I also set the system variable JAVA_HOME to point to the jdk installation directory. Output of echo %JAVA_HOME% is "C:\jdk1.5.0_07\" The project still fails deployment. I attached the new log files and the project again since I start that fresh too. The log files are in the "logs" directory of the zipped project.
Created attachment 31341 [details] Project
It's sounding to me like your problem is not a netbeans one, but a glassfish one. Is this the same problem as you reported in <https://glassfish.dev.java.net/issues/show_bug.cgi?id=734>? One other recommendation I got from the glassfish team is to make sure your installation locations do not contain spaces in the path. My suggestion is to close this issue and followup on the glassfish issue or file a second glassfish issue if necessary.
I was able to reproduce it on my box with Glassfish b48. This seems another case where netbeans packaged an invalid ejb jar (with zero ejb) and the glassfish didn't handle the error case very well. I downloaded the project attached in the netbeans bug, and confirmed that the "ejb jar" in this case is really not an ejb jar. This jar contains an empty sun-ejb-jar.xml which makes the deployment code think it's an ejb jar. But it doesn't contain ejb-jar.xml or any valid valid ejb component level annotations (@Stateful, @Stateless, @MessageDriven) to define any ejb inside the jar. Note: @Entity is not a ejb component level annotation. EJB30 entity class is POJO class and not a ejb. So user will need to remove the sun-ejb-jar.xml from the jar, and use this jar as a library jar which contains persistence units (library jar cannot be deployed directly, but can be packaged inside the ear under lib directory and used by other jars in the same ear). We've seen quite a few cases for this, the following issue is a similar issue https://glassfish.dev.java.net/issues/show_bug.cgi?id=546 I've fixed in Glassfish v2 and the deployment will reject such invalid ejb jar before go any further. And I have backported the fix to Glassfish v1 ur1. There is also a bug filed for netbeans on this (since the invalidly packaged ejb jar is really the root cause here) http://www.netbeans.org/issues/show_bug.cgi?id=50323 *** This issue has been marked as a duplicate of 50323 ***
I see. I added a stateless bean along with its interface and proper annotations and it deploys just fine.