Topics

JPQL support for database identity store?


Guillermo González de Agüero
 

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


Arjan Tijms
 

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



Guillermo González de Agüero
 

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,


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
 

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


Guillermo González de Agüero
 

Hi Will,

I understand your concern. The RI implementation is already done [1] and I can do provide a PR for the spec myself. The only thing I cannot help in is the TCK since I don't even have access to it.

That said, I'll respect your decision. If you think it is at least *possible* that this feature might be accepted, please let me now and I'll work on the spec changes.

If you think it is definitely too late, I'd be happy if it can be left as a Soteria feature.


Regards,

Guillermo González de Agüero


El dom., 9 de julio de 2017 20:14, Will Hopkins <will.hopkins@...> escribió:
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


Werner Keil
 

Probably leave it for another release.