Hi,

Has the EG ever discussed JPA/JPQL support for the database identity store? JPA is already used in most applications, and the database JNDI already has to be set on persistence.xml (where there's no expression support).

I agree there are tons of more important thigs to do, but this is something to think about regarding naming. If the EG thinks this can be a valuable addition for a future version, for consistency purposes with JPA the attributes should be renamed to:
String persistenceUnitName(); // optional if there's only one PU
String callerQuery();
String groupsQuery();

String dataSourceLookup();
String callerNativeQuery();
String groupsNativeQuery();

The problem with that approach is that it pollutes the annotation. Another possibility is to create two different annotations/identity stores: DatabaseIdentityStore and JPAIdentityStore. This approach has two advantages:

- The annotations are slimmer. This is a big point for me. Annotations with lots of incompatible attributes are difficult to use as there's no validation until deployment time.

- The RI could provide the second annotation and the JPQL functionality right now.

Implementation will probably need to wait, but given the naming issue, I see this as something to think about. What path would you EG like most?

Regards,

Guillermo González de Agüero

Hi,

Indeed I remember this coming up at least once. Probably could warrant a new store, e.g. JPAIdentityStore or so.

Kind regards,

Arjan Tijms

On Sat, Jul 8, 2017 at 2:50 PM, Guillermo González de Agüero <z06.guillermo@...> wrote:

Hi,

Has the EG ever discussed JPA/JPQL support for the database identity store? JPA is already used in most applications, and the database JNDI already has to be set on persistence.xml (where there's no expression support).

I agree there are tons of more important thigs to do, but this is something to think about regarding naming. If the EG thinks this can be a valuable addition for a future version, for consistency purposes with JPA the attributes should be renamed to:
String persistenceUnitName(); // optional if there's only one PU
String callerQuery();
String groupsQuery();

String dataSourceLookup();
String callerNativeQuery();
String groupsNativeQuery();

The problem with that approach is that it pollutes the annotation. Another possibility is to create two different annotations/identity stores: DatabaseIdentityStore and JPAIdentityStore. This approach has two advantages:

- The annotations are slimmer. This is a big point for me. Annotations with lots of incompatible attributes are difficult to use as there's no validation until deployment time.

- The RI could provide the second annotation and the JPQL functionality right now.

Implementation will probably need to wait, but given the naming issue, I see this as something to think about. What path would you EG like most?

Regards,

Guillermo González de Agüero

Sorry, Guillermo, good idea, but I don't think it'll make the cut. It's not just spec'ing the annotation that needs doing, there's also reference impl, TCK, etc.

On 07/08/2017 01:50 PM, Guillermo González de Agüero wrote:

I've made a PR adding it to Soteria [1]. What I still haven't found is a way to get the default entity manager when there's only one. So for now the persistenceUnitName attribute is required, unless anyone has a better idea.

I think the addition is little and simple enough to be added to the spec (just one annotation). It provides a real advantage over container provided mechanisms since it allows to use your domain model directly instead of just querying the database. Anyway, I understand there are still lot of things to do and we are in a very advanced stage, so it's up to Will and the rest of the EG.

Regards,

Guillermo González de Agüero.

[1] https://github.com/javaee-security-spec/soteria/pull/99

On Sat, Jul 8, 2017 at 4:17 PM, Arjan Tijms <arjan.tijms@...> wrote:

Hi,

Indeed I remember this coming up at least once. Probably could warrant a new store, e.g. JPAIdentityStore or so.

Kind regards,

Arjan Tijms

On Sat, Jul 8, 2017 at 2:50 PM, Guillermo González de Agüero <z06.guillermo@...> wrote:

Hi,

Has the EG ever discussed JPA/JPQL support for the database identity store? JPA is already used in most applications, and the database JNDI already has to be set on persistence.xml (where there's no expression support).

I agree there are tons of more important thigs to do, but this is something to think about regarding naming. If the EG thinks this can be a valuable addition for a future version, for consistency purposes with JPA the attributes should be renamed to:
String persistenceUnitName(); // optional if there's only one PU
String callerQuery();
String groupsQuery();

String dataSourceLookup();
String callerNativeQuery();
String groupsNativeQuery();

The problem with that approach is that it pollutes the annotation. Another possibility is to create two different annotations/identity stores: DatabaseIdentityStore and JPAIdentityStore. This approach has two advantages:

- The annotations are slimmer. This is a big point for me. Annotations with lots of incompatible attributes are difficult to use as there's no validation until deployment time.

- The RI could provide the second annotation and the JPQL functionality right now.

Implementation will probably need to wait, but given the naming issue, I see this as something to think about. What path would you EG like most?

Regards,

Guillermo González de Agüero

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803