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 189626 - False-positive error badge on project with JPA targeting WebLogic
Summary: False-positive error badge on project with JPA targeting WebLogic
Status: RESOLVED FIXED
Alias: None
Product: javaee
Classification: Unclassified
Component: Persistence (show other bugs)
Version: 6.x
Hardware: PC All
: P2 normal (vote)
Assignee: Jan Lahoda
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-18 09:51 UTC by Petr Jiricka
Modified: 2010-08-20 14:13 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Jiricka 2010-08-18 09:51:53 UTC
1. Register WebLogic 10.3.3
2. In the WebLogic admin console, change default persistence provider to TopLink
3. Create new Java EE 5 web application with WebLogic as the target server
4. Create a new Entity class. EclipseLink persistence provider will be used and this will be a JPA 1.0 project.

You will see that the Source Packages node and the project node will be badged as erroneous, and deployment will complain about errors in the project. At the same time, Ant-based build passes.

The log file contains the following suspicious messages:
WARNING [com.sun.tools.javac.jvm.ClassWriter]: ClassWriter.assembleClassSig: <any> appears in the [e.NewEntity_]'s signature.
WARNING [com.sun.tools.javac.jvm.ClassWriter]: ClassWriter.assembleClassSig: <any> appears in the [e.NewEntity_]'s signature.

The workaround is to remove EclipseLink from the project's processor path, shut down the IDE, delete the <userdir>/var folder and start the IDE again. After rescan, the error badge does not appear.
Comment 1 Sergey Petrov 2010-08-18 09:55:24 UTC
Tomas, was there any changes in javac/scanning/processors support, etc recently? Any ideas?
Comment 2 Sergey Petrov 2010-08-18 09:58:29 UTC
Petr, is it always reproducible for you? I saw the same yesterday, but don't have the same issue today with your steps.
Comment 3 Sergey Petrov 2010-08-18 10:02:32 UTC
after more tests, it may pass for simple entity(for me) but I always have badge for entity from db.
Comment 4 Alexandr Scherbatiy 2010-08-18 10:03:29 UTC
I see that the issue is reproduced in the latest build NetBeans IDE Dev (Build
201008180001)
Comment 5 Sergey Petrov 2010-08-18 10:14:03 UTC
It's likely can be fixed on persistence side by not adding of eclipselink library to processor classpath in case if jpa1.0 is used, but it looks as relatively limited solution and likely will not work in case of non-default provider with metamodel generation support.
Some thoughts - some issues may be related to attempt to generate metamodel for jpa1.0 persistence.xml and with 1.5 source level.
Comment 6 Petr Jiricka 2010-08-18 11:40:58 UTC
Just discussed this with Honza Lahoda. The error visible in the index cache in userdir is:

ERROR:4:package javax.persistence.metamodel does not exist
ERROR:5:package javax.persistence.metamodel does not exist
ERROR:8:cannot find symbol\n  symbol\d class StaticMetamodel
ERROR:11:cannot find symbol\n  symbol\d   class SingularAttribute\n  location\d class e.NewEntity_

So the issue is that when this is compiled by the parsing infrastructure JPA 2.0 API is not on the classpath. However, when compiling by Ant, JPA 2.0 API is on the processor path. This difference is disturbing - why is that?

> It's likely can be fixed on persistence side by not adding of eclipselink
> library to processor classpath in case if jpa1.0 is used

I agree this could be a solution.

> will not work in case of non-default provider with metamodel generation support

Well, metamodel generation itself is a feature of JPA 2.0, right? So if JPA 1.0 is used, it NEVER makes sense to generate the metamodel, regardless of the provider.

> jpa1.0 persistence.xml and with 1.5 source level

I don't think the source level makes a difference, I am still getting an error with 1.6 source level.

I still think it should be investigated why internal parser behaves differently than Ant.
Comment 7 Sergey Petrov 2010-08-18 11:52:22 UTC
>Well, metamodel generation itself is a feature of JPA 2.0, right? So if JPA 1.0
is used, it NEVER makes sense to generate the metamodel, regardless of the
provider.

Yes, but it's likely should be checked by eclipselink. On our side if provider is non-default it will be added to compile classpath and corresponding annotations processors will be available. Annotations processing is enabled by default and is likely will try to use added metamodel processor.
Comment 8 Petr Jiricka 2010-08-18 13:17:49 UTC
I see what you mean. 

So what are other possible ways to fix it? Could we create another provider which would be something like "EclipseLink 2.x on JPA 1.0", which would not contain the modelgen jar file?
Comment 9 Sergey Petrov 2010-08-18 14:08:47 UTC
Supplied libraries can be split  in my opinion, one with name 'eclipelink' and second one with 'eclipselink-modelgen'  with only one modelgen jar, in case if provider's library is added and jpa level is chosen as jpa2.0+ modelgen lib can be added additionally. Im my opinion ist's better then have eclipselink library with and without modelgen jar, but still a bit strange solution and I'm not sure perfect.
Comment 10 Petr Jiricka 2010-08-18 14:37:08 UTC
Ok, sounds good. Well if it works, I would say go for it, even if it's not perfect. If we think of a better solution, we can redo it.
Comment 11 Sergey Petrov 2010-08-18 14:56:19 UTC
ok, will try to split in m1 and see if how it will work, just as workaround isn't so easy should be p2.
Comment 12 Jan Lahoda 2010-08-18 15:01:21 UTC
FYI: errors in files generated by APs should not cause error badges in Projects tab after:
http://hg.netbeans.org/jet-main/rev/3d94d1a3c155
Comment 13 Sergey Petrov 2010-08-18 15:04:22 UTC
ok, will test tomorrow, does it mean the issue is fixed?
Comment 14 David Konecny 2010-08-18 21:26:52 UTC
(In reply to comment #12)
> FYI: errors in files generated by APs should not cause error badges in Projects
> tab after:
> http://hg.netbeans.org/jet-main/rev/3d94d1a3c155

If this makes problem invisible to user then I think it is enough to be done on our side. Perhaps file an issue for EclipseLink to disable annotation processing if persistence.xml is 1.0 version (is this what you are suggesting Sergey?) ?
Comment 15 Sergey Petrov 2010-08-18 21:38:33 UTC
I'm not sure regarding eclipselink issue, as it's unclear for me what code produce 'ERROR:4:package javax.persistence.metamodel does not exist;
Comment 16 Quality Engineering 2010-08-19 03:24:54 UTC
Integrated into 'main-golden', will be available in build *201008190001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/3d94d1a3c155
User: Jan Lahoda <jlahoda@netbeans.org>
Log: #189626: store errors from apt-generated files as non-badge errors (no one to read them currently)
Comment 17 Petr Jiricka 2010-08-19 04:40:45 UTC
> what code produce 'ERROR:4:package javax.persistence.metamodel does not exist

This is because the AP only has JPA 1.0 on classpath, which does not contain this package. If you include JPA 2.0 on the processor classpath, the error goes away.
Comment 18 Sergey Petrov 2010-08-19 05:10:10 UTC
Why there is jpa1.0 only? eclipselink 2.0 lib contain jpa2.0 api.
Is it ap trying t access this package?
Comment 19 Jan Lahoda 2010-08-19 06:02:39 UTC
IIRC, the project Petr showed me had nothing on (in-IDE) compile classpath. So the AP generated the source code that referenced javax.persistence.metamodel, but it was not possible to resolve that reference, so it reports a compilation error. What I did is that this error will not cause the error badge - not 100% correct, but the best solution I know. The question is whether the compile classpath is correct and whether the AP should run. I have seen that the jar with JPA 2.0 is on the processorpath - this is the path from which the APs are loaded, but the references from the source code cannot resolved against the processorpath.
Comment 20 Sergey Petrov 2010-08-19 10:48:58 UTC
even if it can be done better or some fix can be done on eclipselink side also, it works no, no error badge and able to deploy.
Comment 21 Sergey Petrov 2010-08-19 10:53:37 UTC
just one notice, it seems in case of build script if source level is 1.5 there is no ap processing(no generation for metamodel files) but according to the issue the problem was with result of ap processing, ap processors may need to be disabled in compile on save functionality for source level lower then 1.6
Comment 22 Petr Jiricka 2010-08-19 11:17:35 UTC
I must say this is not fixed for me. When I do steps 1.-3. as above and then:
4. Create Entities from DB
5. Create JSF pages from entities
6. Run the project
7. Access the customer list page

then I get the following exception in WebLogic console:
Caused by: java.lang.RuntimeException: Uncompilable source code - cannot find symbol
  symbol: class StaticMetamodel
        at p.Customer_.<clinit>(Customer_.java:9)
        ... 63 more

And in the build dir, class Customer_.class is still generated by the processor. So, I think it will be necessary to turn off the annotation processor as suggested by Sergey in comment #9.
Comment 23 Sergey Petrov 2010-08-19 11:35:12 UTC
do you use 1.5 source level?
Comment 24 Sergey Petrov 2010-08-19 11:42:33 UTC
Also as it;s runtime problem, it's unrelated with false error badge.
I just searched my project and it have no 'DiscountCode_' also there is no modelgen jars in war file, but I see the same problem at runtime.
Comment 25 Sergey Petrov 2010-08-19 11:45:10 UTC
It may be weblogic/eclipselink issue with metamodel generation similar to one initially described above(i.e. error badge as eclipselink try to generate metamodel but there is jpa1.0 api on classpath only). But I can't be 100% sure and say there is nothing from nb/persistence side.
Comment 26 Petr Jiricka 2010-08-19 11:59:18 UTC
Yes I am using 1.5 source level.
Comment 27 Sergey Petrov 2010-08-19 12:00:14 UTC
Petr, with quite 'hard' verification, you can try to remove eclipselink lib from processor classpath with project properties, and even uncheck ap checkboxes, I have the same error in this case at runtime. Nothing from #9 will help with the issue. We may need to contact weblogic team. Do you use 10.3.4 in your latest tests?
Comment 28 Sergey Petrov 2010-08-19 13:25:54 UTC
org.eclipse.persistence_1.0.0.0_2-1.jar in weblogic 10.3.4 distribution contain annotation processor registration via META-INF/services.
in my opinion this one issue need to be closed as fixed.
Comment 29 Sergey Petrov 2010-08-19 13:27:51 UTC
I was too fast, dismiss last comment.
Comment 30 Sergey Petrov 2010-08-19 13:35:33 UTC
but I found next in spec
"or the metamodel
can be accessed dynamically by use of the
javax.persistence.metamodel.Metamodel interface. The getMetamodel method of the
EntityManagerFactory or EntityManager interface can be used to obtain a Metamodel
instance."
so likely eclipselink create metamodel on entitymanager creation, but can't access jpa 2.0 api and fails. Even if el will not create it on em creation, it can later create/use it on any querry even in JPQL and widely used everiwhere, in my opinion it's the issue with attempt to limit eclipselink 2.x to use only jpa1.0 on weblogic side, wonder why el2.x was selected as bundled one instead of 1.1.3
Comment 31 Petr Jiricka 2010-08-19 14:09:08 UTC
> Do you use 10.3.4 in your latest tests?

I use 10.3.3, but I have the same issues.
I found out that the error goes away if I disable deploy on save. So it is the deploy on save that runs the AP.

When I turn off deploy on save, exit the IDE, delete the editor caches, restart the IDE and deploy, the problem seems to go away - the metamodel classes are not generated (although it still does not deploy).

> it's the issue with attempt to limit eclipselink 2.x to use only
> jpa1.0 on weblogic side

From what I heard, this is a Java EE compliance issue. If you include JPA 2.0 API on the classpath, you no longer pass the Java EE 5 compatibility test suite.

> wonder why el2.x was selected as bundled one instead of 1.1.3

Probably because EL 2.x is an overall better implementation of JPA, even if limited to JPA 1.0.
Comment 32 Sergey Petrov 2010-08-19 14:24:05 UTC
I'm a bit mixed

> (although it still does not deploy).
 
vs

>6. Run the project
>7. Access the customer list page


Are you able to deploy with latest nb build or not?
Do you  have runtime issue with switched off ap support in netbeans and completely removed eclipselink library from web project?
Comment 33 Petr Jiricka 2010-08-19 15:23:52 UTC
> (although it still does not deploy).

This was probably a different error (plugin issue?), not related to the annotation processing. At the end I got deployment timeout after 20 minutes. But the metamodel classes were NOT generated for me.

> Do you  have runtime issue with switched off ap support in netbeans and
> completely removed eclipselink library from web project?

In my scenario I have ap support on, and EclipseLink is completely removed. Yes I have deployment issues, but they seem unrelated to this.
Comment 34 Sergey Petrov 2010-08-19 17:34:20 UTC
It may be good to file new issues in my opinion.
Comment 35 Petr Jiricka 2010-08-19 21:42:22 UTC
Ok, filed bug 189697.
Comment 36 Sergey Petrov 2010-08-20 14:13:39 UTC
No false badges, and new issue should work now also.