Re: [security-dev] JPA?

You lost me. I don't understand why an application needs an abstraction (picketlink API) if they are also coding against the data raw. On Jun 11, 2013, at 5:34 PM, Shane Bryzak <sbryzak(a)redhat.com&gt; wrote: > Sorry Bill, but that's nonsense. In Seam, the Identity bean (now part > of the PicketLink API) was a core component of most applications, at > least those that required any type of security. I agree with your > statement that developers won't be using the "PicketLink data model" to > develop their applications, this is something that's largely hidden > behind more developer-friendly abstractions. What PicketLink will do > though is work with an existing application model to enable more fluid > integration between them. Once PLINK-130 is complete we can perhaps > give some more illuminating examples, but to summarise, you'll be able > to define your own identity classes (rather than use the ones built-in > to PicketLink) complete with custom attributes - for example, your > application might require a User class that has properties (attributes) > for addresses and contact details, which would actually be persisted via > corresponding entity beans within the application. The changes we're > working on now will allow this and more. > > On 12/06/13 08:15, Bill Burke wrote: >> Most non-framework developers, even Seam ones, will never see the >> Picketlink API. Most will be picking pre-made widgets and assemblying >> these widgets together through configuration or the management console. >> Most Framework developers will want to write plugins that are usable >> with any storage back end, this also means no JPA. >> >> I think you're fooling yourself if you think app developers are going to >> use the Picketlink data model to developer their applications. If >> anything users are going to have existing models and security >> infrastructure they need to integrate with. >> >> On 6/11/2013 6:03 PM, Shane Bryzak wrote: >>> Of course there is, close to 100% of the developers that use/used Seam >>> would have been using JPA. Remember that the identity model will for >>> many use cases also tie into the application model, in fact the >>> refactoring that I'm working on for PLINK-130 will help to strengthen >>> this connection. >>> >>> On 12/06/13 07:04, Bill Burke wrote: >>>> How exactly does JPA give users more control over their data than JDBC? >>>> Also, I'm sorry, but I just don't believe you that there is this large >>>> contingent of app deveopers that want JPA. >>>> >>>> On 6/11/2013 4:57 PM, Anil Saldhana wrote: >>>>> Bill, application developers will care about JPA vs JDBC if they want >>>>> greater control on things like roles, groups etc. While container driven >>>>> security is good for many applications, a large contingent of app >>>>> developers just want greater control on determining the roles/groups of >>>>> users authenticating to their app. >>>>> >>>>> On 06/11/2013 03:53 PM, Bill Burke wrote: >>>>>> JPA vs. JDBC isn't a choice, users won't care. Why would app developers >>>>>> care either? They should be using management interfaces or the upcoming >>>>>> sso server to manage their domains. >>>>>> >>>>>> On 6/11/2013 4:39 PM, 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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/security-dev >>> _______________________________________________ >>> security-dev mailing list >>> security-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/security-dev > > _______________________________________________ > security-dev mailing list > security-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev