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

[Jason Greene]

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