5:34 p.m.
On 8/5/2013 5:53 PM, Jason Greene wrote:
On Aug 5, 2013, at 3:26 PM, Bill Burke <bburke(a)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