[wildfly-dev] PicketLink pulling in JPA (Was: Changes to the PicketLink Module)

Tue Aug 6 17:02:11 EDT 2013

All,

In response to our discussion, the JPA-based registries are going to be
replaced by JDBC-based registries in 2.1.8, as per PLINK-101 and PLINK-102.

Until 2.1.8 is finished, do you think we should add the dependencies to
module.xml, or just leave it as it is?

Regards,

On Tue, Aug 6, 2013 at 12:03 PM, Jason Greene <jason.greene at redhat.com>wrote:

>
> On Aug 5, 2013, at 5:34 PM, Bill Burke <bburke at redhat.com> wrote:
>
> >
> >
> > On 8/5/2013 5:53 PM, Jason Greene wrote:
> >>
> >> On Aug 5, 2013, at 3:26 PM, Bill Burke <bburke at redhat.com> wrote:
> >>
> >>> Not sure I agree with your perspective on this anymore.  JPA is
> >>> something that does not require Wildfly to run.  You can use it in
> >>> library/resource-locale mode if desired.  WTF do we have JBoss Modules
> >>> if we can't use it to scope services exactly like this?
> >>
> >> The integration with JPA is complex in that it needs to do scanning of
> classes, reflective analysis, annotation analysis, bytecode generation,
> etc. The SE implementations assume all kinds of things like you can just go
> back and forth between Files and Jar URLs to do the scanning bit. You also
> need multiple class loaders in this very ugly stupid SPI so that various
> implementations can load the classes analyze them, then throw them away
> generate new classes and get those reloaded in a new class loader.
> >>
> >
> > IIRC, JPA doesn't require scanning either.
>
> Yeah hardcoding the classnames should be good enough. It still does a
> bunch of self-introspection though, which in the past has been a source of
> boot time cost. Although I believe there are a lot of other actions
> hibernate takes on start that has a big cost. If all of that can
> significantly improved it would certainly reduce my concern. Although I
> suspect we would potentially need direct Hibernate usage and have to skip
> the JPA SPIs (or create new SPIs). I should be clear though that these
> concerns only apply to core stuff we bundle in WildFly. If some other
> project which is based on WildFly wants to do this sort thing, it's not
> really my call. I would however convey the warning that if you want the
> best boot time this is likely to stand in your way.
>
> >
> >> There are other issues as well, like someone implements something that
> is tied to hibernate (pretty easy to do) or a specific version of hibernate.
> >>
> >
> > So why can't this be solved by JBoss Modules?
>
> Well what I mean is that if everyone needs "JPA" and they tie it to the
> single global JPA implementation, then the assumption is that swapping the
> JPA provider would be allowed. The reality though is that all of this is an
> implementation detail of the service itself (user doesn't care that JPA is
> involved or which provider etc). So services should probably be directly
> using their own JPA api and impl in some direct fashion. Care would have to
> be taken to ensure that we don't have 3 versions of hibernate floating
> around.
> >
> >
> >>>
> >>> So, you're also saying that if I have an auth service that uses
> Resteasy
> >>> client, I can't use Resteasy client because it is a subsystem we ship
> with?
> >>
> >> It depends on what dependency requirements we want to have. I mean the
> question really should be should the auth service pull in resteasy and
> everything it depends on? Maybe thats ok. I'd argue that a core
> authentication infrastructure we are using, like picket link, should
> support all potential configurations of WildFly, including perhaps servlet
> only, or maybe even just a web proxy with no servlet, or maybe some new non
> -EE api framework set like Play or some ruby thing. If it's a core reusable
> service we should ensure that it can be properly shared.
> >>
> >
> > Let's do this exercise.  The Resteasy AS7 OAuth plugin requires:
> >
> > * json parser
> > * HTTP
> > * HTTP connection pool
> > * PKI
> >
> > Do I ditch Resteasy, Apache Http Client 4.1, Jackson, and Bouncycastle
> because they already ship with AS7 and could cause version conflicts?
>
> Thats certainly reasonable. I'm not sure what I was thinking.
>
> > Isn't this more of a bootstrap issue as it pertains to JPA?
>
> Yeah the main issue is bootstrap, and also where we draw the lines for
> sharing. Just sharing the library, sharing the services, etc.
>
> >
> >
> >>>
> >>> As far as the IDM API goes, I'm already worried it is turning into a
> >>> Federated JDO project rather than an IDM API.
> >>
> >> Yeah I am worried about the API complexity that is being pulled in.
> >>
> >>> Not being able to use JPA
> >>> will require it to re-implement a lot of the features JPA has:
> >>> session/transaction management, connection pooling, 1st/2nd level
> >>> caching etc…
> >>
> >> If we look at this use case,
> >
> > I'm talking about the IDM API as I think it is effected by the same JPA
> vs. JDBC argument you're talking about here.
>
> Ok I think I see what you meant. I think the reason IDM looks like a JDO
> thing is that it has to support non-database stores (file, ldap, etc). So
> the challenge is that the IDM has to manage its data already, and the
> mapping of it. It has to cache, and it has to manage atomic updates. So JPA
> is just duplicating what it already has to do.
>
> >
> >> its simply persisting and loading a token. To me it's overkill to pull
> in JPA for that. I could see some use cases with very complex relational
> designs that maybe motivates you, but even then it really should be
> balanced with what the overall architecture is going to look like.
> >>
> >
> > +1 for JDBC for token-only storage.
> >
> >> So if we just need to share things like transactions and connection
> pooling it would make much more sense to split out those areas. We could
> for example look at can ironjacamar provide a tiny module that doesn't
> require all of RAR support to do connection pooling. Transactions is
> already small enough with just JTA, and naryana also has a new small core
> API.
> >>
> >> Second level cache is something I am not sure matched up nicely with at
> least the IDM case. I mean the IDM already does caching, and using a second
> level cache is just duplicative.
> >>
> >
> > 1st-level cache == per-transaction cache
> >
> > 2nd level cache == a cache shared by multiple EntityManager sessions.
> Meaning it doesn't necessarily have to be clustred infinispan, just
> something in memory.
>
> Right but what I mean is that IDM for example has to have its own global
> authentication cache. So JPA won't even be involved on subsequent reauth. I
> suppose the 2LC could be useful for browsing lists of users, however LDAP
> is just as common as an auth DB (actually likely more common), and so if
> you actually had that problem, you would need something above JPA to cache.
>
> >
> >> Anyway my key point is that I think we sometimes look at problems from
> an application developers perspective, as in whats the easiest way to solve
> the problem I need to solve from that very specific perspective vs really
> looking at what the whole system integration feels like. Those really need
> to be balanced.
> >>
> >
> > Honestly, I know what you mean and experience the issues you are
> concerned about all the time.  Its even worse for projects that are
> required to run in environments other than Wildfly.  But, there's a huge
> danger of re-implementing something that is already very mature in the
> wild.  JPA often looks like the easy-path to quick development, but when
> you look at it, its much more than just ORM.
>
>
> Yeah I see your point. I think a lot of the big benefits though are
> provided by JCA & JTA (unless I am missing something). Maybe there is a
> some need for core services to use an ORM + data services, although if so,
> it feels like our abstractions aren't in the right place, and wed need to
> look at those.
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
Fernando Ribeiro
Upic
+55 11 9 8111 4078
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20130806/ddda15f2/attachment.html 