Re: [security-dev] JPA?

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev