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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev
_______________________________________________
security-dev mailing list
security-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev
_______________________________________________
security-dev mailing list
security-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev