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.
Use "Session Beans from JPA entities" wizard and tick that you want Local or Remote interface and you will find that generated EJB interfaces have only getEntityManager method (which is abstract in AbstractFacade). Second problem which happened to me is that generating Sessions EJBs for all JPA entities from Sample DB generates all class correct apart from AddressFacade which has following error: public class AddressFacade extends <any> { instead of public class AddressFacade extends AbstractFacade<Address> { Please fix for 69M1. Is this your Sergey?
AbstractFacade seems to be also using createQuery instead of Criteria API. No big deal but what was reason for this?
abstract facade was implemented by Andrey, I can try to look too.
Fixed in the web-main. Now local/remote interfaces have all the abstract facade methods declared. As for 2nd problem with AddressFacade I am not found the Address table in the Sample database so where you get this Address entity you are generating session for? What specifically this entity different from others?
3rd problem fixed as well. The problem was the code always generated for JPA version 1.0.
When you say 3rd I assume you mean 2nd problem. :-) Thanks for quick fix. First problem is resolved but second is still there. I tested your changes and 80% of generates facades had that problem. It always happens only on fresh new project after I generated JPAs for all tables - generating EJBs for these JPAs results in some being incorrectly generated. Repeating generation always produces correct files. My guess is that it is related to Java parsing not being finished and instead of getting "AbstractFacade<Address>" you and up with "<any>". Or chase where that <any> is coming from.
Integrated into 'main-golden', will be available in build *201002120200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/4e33627b7c9d User: Andrey Yamkovoy <kaktus@netbeans.org> Log: #180583 - AbstractFacade introduction breaks EJBs generation
I am also seeing the second problem. Andrey, any progress on this? Thanks.
As for the 2nd problem I can't reproduce it. From the synopsis it can be reproduced in case the entity class for which we generating the facade was not parsed yet. So in this case AFAIK the only way to resolve this problem is wait while the scan finished and then start the generation ... Maybe it's better to move the 2nd problem to another issue and close this one because the rest of the problems are fixed?
Don't worry about creating separate issue. re. "So in this case AFAIK the only way to resolve this problem is wait while the scan finished and then start the generation" - depends on how the generation of facade classes is implemented. If you are relying on Java parser model then yes you have to wait for parsing be finished. Alternatively if you generate AbstractFacade yourself then you can use that information in individual facades generation without depending on Java infrastructure.
I can not reproduce this now in the latest build.
I had a look at the code and problem is following (Tomas, could you advice how to handle it correctly): j2ee.ejbcore/src/org/netbeans/modules/j2ee/ejbcore/ejb/wizard/jpa/dao/EjbFacadeWizardIterator.generate() method uses JavaSource.runModificationTask() to generate AbstractFacade base class and later it is using second JavaSource.runModificationTask() call to generate subclass of AbstractFacade. The problem is that parser has not finished parsing of AbstractFacade and therefore when workingCopy.getTreeUtilities().parseType("b.AbstractFacade<a.Address>") is called AbstractFacade cannot be parsed/resolved. Tomas, what is the right way to make sure AF has been parsed and is in parser db? I placed between the two runModificationTask() a call to empty runWhenScanFinished(...).get() and that did help - after that generated code is always correct. Btw. I'm pretty much always able to reproduce it without my fix. I think that trick is to always generate EJB session beans into a new package so that new AbstractFacade is generated.
Davide, have you got any test case or steps to reproduce? The TU.parseType should work even when the background scan is not yet done iff the b.AbstractFacade and a.Address are in correct packages and files. The javac will use slow SourceFileObject it will be slower but it should be resolved. When the files are not in correct place the javac will not be able to find them until there is a sig (class) file. Running runWhenScanFinished(...).get() is a workaround which should work iff the file is "saved" synchronously before the second rMT is started. But I would rather take a look why is it not working.
Try these steps to reproduce. On my Ubuntu 8.04 and Product Version = NetBeans IDE Dev (Build 100218-621eb6389380) (#621eb6389380) Operating System = Linux version 2.6.24-24-generic running on i386 Java; VM; Vendor = 1.6.0_17; Java HotSpot(TM) Client VM 14.3-b01; Sun Microsystems Inc. I can reproduce it always. But it works for other people. I'm happy to enable some logging or run patched version of NB if you cannot reproduce yourself. Steps: * create Web Project (register GF v3 server - you may have to download one - talk to PetrJ if you need a help); ignore frameworks - you just need plain web p[roject with some EE6 server * New File -> Persistence -> Entity CLasses from DB -> datasource : jdbc/sample -> Add All tables -> Next -> enter a package -> Finish * New File -> Persistence -> Session Beans from Entity -> Add All -> Next -> enter different package -> Finish (you can repeat now just thit last step and choose a different package to reproduce the error) Now, for me at least one (sometimes more or all) *Facade.java classes have compilation errors because generetad body contains "extends <any>" instead of "extends AbstractFacade<concrete-entity>". From debugging I can see that facade classes are generated in for-cycle and depending on some other thread at some point in time "b.AbstractFacade<a.Address>" becomes correctly parsed. Prior to that point it is always "<any>". Relevant code is in EjbFacadeWizardIterator like 392 - "genUtils.createType(afName + "<" + entityFQN + ">", classElement)," and j2ee.core.utilities/src/org/netbeans/modules/j2ee/core/api/support/java/GenerationUtils.java line 234 - "TypeMirror typeMirror = copy.getTreeUtilities().parseType(typeName, scope);".
Thanks David, I will try what's happening.
Unfortunately I am not able to reproduce it on my Mac. It seems that for some reason the javac is not able to find the type parameter (eg. db.Customer). I have no idea why as the db.Customer already exists and was indexed. So it should be resolved. I will continue with this on Tuesday on qa Linux.
Davide can you recheck it if it's still valid in current build? Thanks
Just for reference, may be issue 173028 have the same root cause.
Right Sergey, it can be related. The "prdel.DiscountCode" was not resolved in that case which is very similar to unresolved db.Customer. Hopefully it's reproducable on Ubuntu. I've tried 5 times on Mac without success. Seems some race among initial scan and the wizard. According to thread dump the wizard does not use runWhenScanFinished. But even in this case the db.Customer should be resolved in sources when classpaths are correct.
I was testing this and bumped into different issue which I filed as Bug 183613 (p1).
Created attachment 96865 [details] Proposed fix David, could you please try to reproduce the issue with this patch. I hope it fix the problem. I can't verify it on my PC because can't reproduce even without the patch. :(
In the original case described by David the parametrized type was unknown (at least from the behavior, I was never able to reproduce it). It will be still unknown even with this patch.
I still can reproduce it (after disabling annotation processing to avoid issue 173028). I applied the patch and now I'm getting IDE exception from the new line of code introduced in the patch: java.lang.IllegalArgumentException: Incorrect number of type arguments at com.sun.tools.javac.model.JavacTypes.getDeclaredType0(JavacTypes.java:247) at com.sun.tools.javac.model.JavacTypes.getDeclaredType(JavacTypes.java:223) at org.netbeans.modules.j2ee.ejbcore.ejb.wizard.jpa.dao.EjbFacadeWizardIterator$2.run(EjbFacadeWizardIterator.java:382) at org.netbeans.modules.j2ee.ejbcore.ejb.wizard.jpa.dao.EjbFacadeWizardIterator$2.run(EjbFacadeWizardIterator.java:357) at org.netbeans.api.java.source.JavaSource$1.run(JavaSource.java:661) [...]
Created attachment 96875 [details] exception
OK, when the P1will be fixed, I will try again. Thanks David.
Fixed in the web-main. The fix is running empty task when scan finished before scheduling the modification task. Should not bring any performance problems because in the wizard the runWhenScanFinished operation performs when collection available entities for facade generation.
Integrated into 'main-golden', will be available in build *201004160201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/c3107b058b22 User: Andrey Yamkovoy <kaktus@netbeans.org> Log: #180583 - AbstractFacade introduction breaks EJBs generation