Ebean + JPA 2.x + Jetty: Duplicate classes warnings

[jnehlmeier]

I am trying to reduce the warnings of an app which uses JPA (EclipseLink 2.7.9), Ebean (12.10.0) and Jetty (10.0.11).

During deployment Jetty scans all dependencies for annotated classes (because of servlet-api) and while doing so it emits a WARN if the same class has been found in multiple jar files. IMHO it is a nice warning because you usually don't want that as you can not guarantee that both classes are actually the same code.

Here an example

javax.persistence.AssociationOverride scanned from multiple locations: 
jar:file:///tmp/jetty/jetty-0_0_0_0-8080-app_war-_app-any-12064256284633159342/webapp/WEB-INF/lib/jakarta.persistence-2.2.3.jar!/javax/persistence/AssociationOverride.class, 
jar:file:///tmp/jetty/jetty-0_0_0_0-8080-app_war-_app-any-12064256284633159342/webapp/WEB-INF/lib/persistence-api-2.2.4.jar!/javax/persistence/AssociationOverride.class

Library jakarta.persistence-2.2.3.jar (still uses javax.persistence package) is pulled in by EclipseLink and persistence-api-2.2.4.jar by Ebean.

I can not exclude the Jakarta Persistence API because Ebean's version has removed some stuff from the annotations so that JPA won't work anymore. I can not exclude Ebean's version because then I am missing some Ebean features and I am not sure if they can be replicated using standard JPA annotations (that is I have no idea if Ebean adjustments are just syntactic sugar).

This affects everyone migrating away from JPA to Ebean and using Jetty. If the app is large (it is in my case) then migration can take very long or might never be fully done (then only new code uses Ebean). I can also see people developing desktop applications who want to use JPMS having trouble to do so given that two dependencies define the same module.

Currently we get warnings for N files of persistence api * M deployed apps using JPA & Ebean * amount of app servers which is quite some logging noise during deployment. I don't want to silence the logger and set it to ERROR only because then I am missing other warnings as well.

Personally I would love to see Ebean to move its modified, JPA originated annotations to io.ebean.annotations. Given that Ebean entities and JPA entities both need to be weaved/enhanced there is no way to use the same entity class with Ebean and JPA at the same time. So for incremental migration of code you always have to duplicate the class to make weaving work until the JPA entity isn't used anymore at all. Because of that having to change packages of Ebean JPA annotations in ebean entities to an ebean specific package seems not a big deal. If someone wants to do an all-or-nothing switch they could use search/replace to update imports and then fix everything that is broken. Overall I think it wasn't a great idea to duplicate, modify and re-release a specification using the same package.

The above issue will go away naturally when updating EclipseLink to v3 which uses the Jakarta namespace. But this can also involve additional work and might require other dependencies to be Jakarta ready as well.

[rPraml]

Refering to https://github.com/ebean-orm/javax-persistence-api ebean's JPA annotations are a clone/fork of the original ones. Except the two mentioned extensions. So ebean should be happy, with the original ones.
Try to exclude one of them in your pom file.

[rbygrave]

Exactly as Roland has said, just use the standard persistence API (with those 2 noted extensions of @repeatable and @Embedded prefix). *> and might require other dependencies to be Jakarta ready as well* I want to add that *I am very concerned* that the Java SE community in general is heading into serious difficulty in upgrading to Jakarta JAXB as it is effectively incompatible with Javax JAXB and is not guaranteed to co-exist in the same classpath (without hacking/shading/cloning the JAXB API). Refer jakartaee/jaxb-api#263 and #2722 I'm 99% sure we have to revert back to javax.xml.bind (from Jakarta) due to the conflict there and at this point there is no known nice way to upgrade to Jakarta JAXB without significant chance for an Java SE application to have conflicting dependencies with Javax JAXB. Ebean can kick this can down the road at the moment but at some point we need to deal with this issue of being effectively stuck on javax.xml.bind (which I'd suggest is an un-maintained dependency, mature sure but un-maintained going forward). So for example, if an app upgrades to Jakarta persistence and *has a dependency on Jakarta JAXB* ... then ebean-test / ebean-ddl-generator (in the test classpath) might not be able to co-exist due to the conflicting dependency on javax.xml.bind ... and Ebean will be in a catch 22 situation in that it can't satisfy both the Javax JAXB apps and the Jakarta JAXB apps at the same time. This could be painful. I'd love more community brain power going into this issue to clarify our path forward. Cheers, Rob.

…

On Tue, 16 Aug 2022 at 05:53, Roland Praml ***@***.***> wrote: Refering to https://github.com/ebean-orm/javax-persistence-api ebean's JPA annotations are a clone/fork of the original ones. Except the two mentioned extensions. So ebean should be happy, with the original ones. Try to exclude one of them in your pom file. — Reply to this email directly, view it on GitHub <#2790 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABTATIEMW2PXKLAWP5PZZLVZJ72NANCNFSM56SPUPEA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jnehlmeier]

Exactly as Roland has said, just use the standard persistence API (with those 2 noted extensions of @repeatable and @Embedded prefix).

Ok, and Ebean still recognizes the container annotations like @AttributeOverrides of standard persistence API which are needed because corresponding annotations are not marked @Repeatable?

[rPraml]

First of all, your application will only use ONE persistence API if there are multiple jars with the same API in the classpath. (unless you do not use OSGI or something simirar) So, if you have 'ebean-persistence-api.jar' AND the 'standard-persistence-api.jar' in the classpath, the first one wins. (this is exactly, what jetty complains: having the same classes in different jars may produce strange results) so, I'm sure, in your current app, either ebean uses the "standard" one or eclipselink uses the one provided by ebean. Both will work, without problems, if you do not use the @Repeatable and @EmbeddedId extensions
If you use some extensions, you'll need the ebean-jpa and exclude the "standard" jpa. (and eclipselink should also work with it, but cannot use the extended features, of course)
If you are unsure, I would suggest, try to exclude the ebean-jpa. If your code still compiles, you do not need the extended api.

Please check with mvn dependency:tree (assuming that you use maven) which dependencies will pull the wrong api and add an tag in your pom file

[jnehlmeier]

So, if you have 'ebean-persistence-api.jar' AND the 'standard-persistence-api.jar' in the classpath, the first one wins.

Yes, but that is only true for classes that exist in both jar files. However 'ebean-persistence-api' has a lot of stuff deleted because ebean does not use/support it. For example @Access(AccessType) does not exist anymore in ebean persistence api because ebean only supports AccessType.FIELD. Same for Criteria API.

That is why I definitely can not exclude standard persistence api because then classic JPA code will break. So I have to exclude ebean persistence api and that is why I asked if ebean still supports the original/standard way for the cases ebean persistence api has made an extension for.

Currently I do not have ebean entities that use @AttributeOverrides, @Converts, @JoinColumns, @MapKeyJoinColumns, @NamedEntityGraphs, @NamedNativeQueries, @NamedQueries, @NamedStoredProcedureQueries, @PersistenceContexts, @PersistenceUnits, @SecondaryTables, @SqlResultSetMappings, @Embedded so classpath ordering doesn't matter. It could very well be that standard persistence API is currently shadowing ebean extensions.

Nevertheless I want to know if ebean works with

@AttributeOverrides({
  @AttributeOverride(....),
  @AttributeOverride(....)
})
private X field;

as well as

@AttributeOverride(....)
@AttributeOverride(....)
private X field;

Because if ebean does not support the first style anymore (because it has a nicer extension using @Repeatable) then as soon as I use any of these annotations in ebean entities I MUST keep both api jars AND I MUST make sure that ebean persistence api jar is first in classpath for the extension to be useable. And then I MUST also be sure that JPA entities will never have @OneToOne, etc. on methods, since ebean persistence api has removed METHOD as annotation target.

I hope the motivation of my question is clearer now.

[rPraml]

However 'ebean-persistence-api' has a lot of stuff deleted because ebean does not use/support it.

@rbygrave didn't notice, that stuff was removed (and not mentioned in the readme). This puts @jnehlmeier question in an other light.

• Ebean should/must work with the standard API (mostly true, expect some extensions)
• adding syntactic sugar like @Repeatable in an own fork should be ok (you can always use the old style).
• for extended features (like embeddedid) there must be a workaround (e.g. some annotation io.ebean.annotations to get the same behaviour when you must use the standard API) - this is AFAIK not the case now.
• removed stuff must be listed in the readme.md

[rbygrave]

Ebean should/must work with the standard API

It does with the limitation that Ebean only reads FIELD annotations. We did that for a reason and that reason is still valid. No-one has asked for that to change that back to additionally read METHOD annotations. At this point we are all good here.

for extended features (like embeddedid) there must be a workaround

You mean @Embedded prefix. The workaround is to do it the standard JPA way which of course works it's just very verbose. We do not need to add any extra annotation to io.ebean.annotations here for this. Nothing to do, we are good.

removed stuff must be listed in the readme.md

This is sounds more dramatic than it is. Ebean never supported EntityManager and a whole bunch of classes in the API. This is because JPA didn't separate mapping annotations from the rest of the API. The types removed like EntityManager etc were NEVER supported by Ebean. The benefit of not having those things in the ebean persistence-api is that it provides compile time check for things that Ebean will never use (like EntityManager) so that is a helpful validation. Apps using the standard persistence-api don't get that validation obviously.

[rbygrave]

ebean still supports the original/standard way for the cases ebean persistence api has made an extension for

Yes it does. Yes you can use @AttributeOverrides

Ebean still recognizes the container annotations like @AttributeOverrides of standard persistence API which are needed because corresponding annotations are not marked @repeatable?

Yes. If we look at `@Repeatable` and see how it works ... we see that for example `@Repeatable` on `@AttributeOverride` is just syntax sugar for putting the entries into a `@AttributeOverrides`. There is no way to remove the `@AttributeOverrides` or for Ebean to not read it etc. That is, the `@Repeatable` is effectively just syntax sugar and this is the case for all those `@Repeatable` containers".