[security-dev] JPA?

[Anil Saldhana]

Jason - I will let others chime in their thoughts.

We want to support as many Identity Store implementations as possible. 
We implemented a File Store implementation mainly to aid its usage as 
the default identity store implementation in WildFly.
I have no issues in providing an additional JDBC identity store 
implementation. It just gives the users more implementations to choose from.

 From application developers perspective, I think the balance still 
swings toward JPA. But for Wildfly core authentication using PicketLink 
IDM, for database backends, JDBC makes sense.

It will be at least a couple of months before we attempt a JDBC 
implementation due to 2.5.0 release. That is why I placed the JIRA issue 
fix to be 2.5.1. I think this works for Wildfly roadmap.

On 06/11/2013 03:14 PM, Jason Greene wrote:
> I thought it best to move the discussion on undertow to here.
>
> Anil opened a JIRA to investigate:
> https://issues.jboss.org/browse/PLINK-190
>
> My concerns are:
>
> - Initialization Time (JPA has always been expensive in this area)
> - Dependency chain problems (if this forces the app server (which at some point might not be limited to Java EE) to have a big chunk of EE just to support database auth)
> - Potential increase of memory usage? (in particular if we end up with hibernate using infinispan as a cache which is then double cached at the auth level)
>
> I guess the main reason for the switch from JDBC is to avoid supporting various DB dialects. However, the following is also true:
>
> - ANSI SQL-92 is supported by almost everyone, and it allows for portable DML
> - IDMs have very simple relational layouts and queries
> - It's easy to abstract queries to allow customization by a user
>