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.
Created attachment 110612 [details] Testcase When running JPA JUnit testcases, VM Run options must be added as follows: -javaagent:"C:\Program Files\NetBeans 7.0.1\java\modules\ext\eclipselink\eclipselink-2.2.0.jar" Otherwise the ORM behaviour does not match its behaviour when deployed on GlassFish, and JUnit tests become meaningless. If everything is developed with IDE support, out of the box, standard build script, then this does not work. Painstaking experimentation has revealed that the project option "Compile on Save" breaks the normal functionality. While one could argue that there is now a workaround for this problem, this is hardly acceptable for the following reasons: - Normally, this defect is not evident because it des not advertise itself - Behaviour of test classes is only different in very subtle ways, but critical and possibly disastrous This testcase shows failure on failure, but it is also possible to show success on failure. To verify that the testcase functions: - Open the project "Web". - Verify that "Compile on Save" is off - Replace the VM run option "javaagent" with your version - Clean and build the project - Compile the test class MyServiceTest - Run the test class MyServiceTest At this stage, the test should succeed To reproduce the error: - Turn "Compile on Save" on - Clean and build the project - Compile the test class MyServiceTest - Run the test class MyServiceTest The test fails with the following error: Testcase: testGetMyEntities(ejb.service.MyServiceTest): Caused an ERROR Exception [EclipseLink-7197] (Eclipse Persistence Services - 2.3.0.v20110604-r9504): org.eclipse.persistence.exceptions.ValidationException Exception Description: Null or zero primary key encountered in unit of work clone [MyEntity[id=TYPE_0, ordinal:0, version:1]], primary key [0]. Set descriptors IdValidation or the "eclipselink.id-validation" property. javax.persistence.PersistenceException: Exception [EclipseLink-7197] (Eclipse Persistence Services - 2.3.0.v20110604-r9504): org.eclipse.persistence.exceptions.ValidationException Exception Description: Null or zero primary key encountered in unit of work clone [MyEntity[id=TYPE_0, ordinal:0, version:1]], primary key [0]. Set descriptors IdValidation or the "eclipselink.id-validation" property. at org.eclipse.persistence.internal.jpa.EntityManagerImpl.flush(EntityManagerImpl.java:786) at ejb.service.MyServiceTest.tearDown(MyServiceTest.java:102) This is also related to issue 193828 and issue 194605. The combination of these issues which affect this scenario makes this more severe than what is immediately apparent from the testcase.
Created attachment 110613 [details] Testcase The new testcase contains a project "Init" that can be used to create the test data.
First impression, why it's P1, what is broken? just if some specific tests for example for framework or library XYZ need some option to works properly and this options isn't added by ide automatically it's more like enhancement request rather then a defect. Even if test with XYZ usage is developed within IDE ide may not know much about special options even critical for proper XYZ work and can't wright everything out of the box.
There appears to be a misunderstanding: This issue is not about a missing option that lets JPA run properly, and option that the IDE shoud add, as apparently understood, as suggested in the previous comment. The testcase assumes that the user adds this option manually, and this is ok. I am not asking for this, which would certainly be an enhancement - I would agree with that. My comment is insofar misleading as it starts with this option - my apologies. The defect becomes evident when weaving is in fact configured manually. The test procedure shows this. My real concerns are: - Basic Java EE setup: Web, JPA, JUnit - All technologies out of the NetBeans "Box" except perhaps JUnit - Subject matter is Oracle core technology (JPA and perhaps GlassGish) - All default options, no fancy selections - Root cause extremly hard to discover (needs FINEST log level) and diff analysis - Nobody (absolutely nobody) would turn off "Compile on Save" as a workaround because it is needed to work around other bugs such as 201117 I am hoping that after some experimentation with this, it becomes obvious that this issue, seen in context, is really toxic!
Again, weaving is configured manually, no apparent configuration error - but it does not work as configured.
ok, if it';s about some option required for application to work properly and this option isn't transferred to compile&save feature and isn't used here, and compile&save is usually used in deplot&save also and it cause problems with an application, it looks like valid issue.
have no ideas yet if it's on persistence side or need base ide adjustment but as behavior is compile&save dependent, cc Tomas also.
it may have sense to wait if fix #201117 affect this issue also.
The web project (probably j2ee as well) has different CoS execution. So it already copied the resources to build/classes. But the fix of issue #201117 may help (the source root is not on CP.R).
unfortunately no luck and test still fail with c&s on.
will try to look in this release.
MyEntity.class file size is deferent dependent on c&s option, so it's really compiled with different option but it's bigger with c&s on, not sure yet what it may mean.
test pass if run with 'Test' project action instead of direct execution. it's second one easy "workaround" here. may b the issue with run action itself in web project.
David is there any difefermce in tests execution on web project with 'Test' and with 'run file'?
(In reply to comment #13) > David is there any difefermce in tests execution on web project with 'Test' and > with 'run file'? I would think there is not. Or there should not be. But test project is failing and so best way to evaluate this is to enable verbose logging on Ant and then run "Test" on project and "Test" on single unit test. Comparing the results I can see that "Test" on single unit test (which fails) is missing few attributes when executing JUnitTestRunner: * '-Xbootclasspath/p:/home/dev/main/nbbuild/netbeans/enterprise/modules/ext/javaee6-endorsed/javax.annotation.jar:/home/dev/main/nbbuild/netbeans/enterprise/modules/ext/javaee6-endorsed/jaxb-api-osgi.jar:/home/dev/main/nbbuild/netbeans/enterprise/modules/ext/javaee6-endorsed/webservices-api-osgi.jar' * '-javaagent:/home/software/netbeans-7.0/java/modules/ext/eclipselink/eclipselink-2.2.0.jar' It is the second difference which is causing this issue. Fixing it should be easy.
The problem is that when CoS is enabled then build-impl.xml is not used and unit test is started alternative way and it is here where bootstrap classpath and JVM arguments were forgotten to be included. I have a fix for WebProject and need to add fix also for other EE project types.
web-main #503c87a296ef
David, Thank you for this. I haven't tested this yet, bt I would like to take this opportunity to say that from my perspective, NetBeans Java EE and GlassFish support has recently reached a new level of quality. Previously, I could never trust deployment. I was never sure whether breakpoints would be broken, or whether I needed to re-start the server for other reasons and so on. But know it appears that mosst of my concerns have been addressed.
Great to hear! I hope it stays that way for a while. :-)
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/503c87a296ef User: David Konecny <dkonecny@netbeans.org> Log: #201937 - Weaving not enabled when running JPA JUnit test in Web Project
I re-tested with Product Version: NetBeans IDE Dev (Build 201111040600) Java: 1.6.0_25; Java HotSpot(TM) Client VM 20.0-b11 I get a different error using the same testcase: java.lang.NoClassDefFoundError: javax/persistence/spi/PersistenceUnitInfo I executed it it with an empty userdir without importing settings. I also re-tested with the same method with NetBeans beta to verify that the scenario is stable.
it's 99% another issue and is likely caused by another fix and unchanged module version in dependencies. it should be filed as new one.
I agree with Sergey, could you file a new issue please? Does the NoClassDefFoundError happens only when CoS is enabled and disabling CoS makes the exception go away?
I potentially agree with the assertion that this issue is fixed. However I find it difficult to accept that it is closed without being successfully re-tested. There is otherwise nothing in the system that would ensure quality wrt to this issue if this issue remains closed before it can be tested. The point I am making is confirmed by the fact that the failure was not even discovered when first closing it, meaning that no attempt was made to test using the supplied testcase. Even more I am asked to create a new issue for what was not really my original concern.
(In reply to comment #23) > However I find > it difficult to accept that it is closed without being successfully re-tested. I did test it and it worked fine - the problem was that bootstrap classpath and JVM arguments were forgotten to be included and that got fixed and tested. Thanks for filing issue 204729.