[security-dev] JPA?

[Shane Bryzak]

+1, I agree with Anil.

On 12/06/13 06:39, Anil Saldhana wrote:
> 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
>>
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev