relationship b/w Jakarta Data repositories and persistence units

[gavinking]

Here's something we could say. I'm not sure if it's a good idea or not.

[njr-11]

The text looks fine if we decide to add this

[scottmarlow]

even if the repository interface is packaged in a separate archive.

If the entity classes are not accessible to the separate archive that might not work.

[gavinking]

Well the entity classes have to be accessible since the repository is defined in terms of them.

[scottmarlow]

Good point as clearly the application will not work otherwise.

[scottmarlow]

So if the persistence unit definition + entity classes are in a sub-deployment in an ear, other sub-deployment modules may or may not have access to the entity classes was what I was trying to say.

[gavinking]

Sure. Of course the persistence unit has to be a dependency of the module containing Jakarta Data repositories; that goes without saying.

The problem I'm trying to solve here is the opposite one: what if the module containing the Jakarta Data repositories is not a dependency of the persistence unit? How can the persistence provider get hold of the repository interfaces to scan them for @JakartaQuery and @NativeQuery annotations? My proposed solution is: pass the Class objects to the persistence provider.

[scottmarlow]

Will @JakartaQuery + @NativeQuery be tagged as Discoverable?

I'm not sure if that helps but it might.

[scottmarlow]

#937 is the related issue for Discoverable.

Sadly I think @DISCOVERABLE class scanning would be done by the EE container at the root of the persistence unit definition but repository interfaces might not be in that same root of the persistence unit location.

It sounds like the root deployment archive that contains repository interfaces need to be scanned for @DISCOVERABLE (@JakartaQuery and @NativeQuery which would need to be Discoverable) as well but accessible via a different PersistenceUnitInfo#getAllDiscoverableClassNames that would need to scan from the root of the deployment for all top level + sub deployment @DISCOVERABLE classes. Would that help?

[gavinking]

Sadly I think DISCOVERABLE class scanning would be done by the EE container at the root of the persistence unit definition but repository interfaces might not be in that same root of the persistence unit location.

Yes, that is certainly the intent.

What I'm trying to do here is add a separate, additional kind of discovery just for @Repository interfaces. I admit that it's an inelegant solution.

[scottmarlow]

CC @bstansberry

[gavinking]

The text looks fine if we decide to add this

@njr-11 In Liberty, what are the restrictions on packaging of repositories with respect to persistence units?

[njr-11]

The text looks fine if we decide to add this

@njr-11 In Liberty, what are the restrictions on packaging of repositories with respect to persistence units?

Liberty does not require the class annotated Repository to be packaged with or even accessible to the persistence unit. To confirm, I just tried out packaging the entities and defining a persistence unit within a JAR file of the application (which cannot load from web modules) and in a web module defined a repository that uses the entity and has the persistence unit as its data store. This worked fine as expected (using Data 1.0 and Persistence 3.2/EclipseLink), with the web module being able to successfully inject and perform operations on the repository, despite the persistence unit not having access to the repository.