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