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

[Bill Burke]

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.

> 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?


>>
>> 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? 
Isn't this more of a bootstrap issue as it pertains to JPA?


>>
>> 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.

> 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.

> 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.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com