No, CDI-2 doesn't add that much we would need. The problem is really that IF we package this, then TomEE could _not_ run in Java7 anymore. Which is still the official pre-requisit for EE7 servers (Java8 is just optional).
LieGrue, strub > Am 15.02.2018 um 14:05 schrieb Romain Manni-Bucau <[email protected]>: > > 2018-02-15 13:30 GMT+01:00 Rudy De Busscher <[email protected]>: > >>> >>> Can we assume Java8 for this attempt? >>> Oh and more important: Will the integration work based on TomEE7 (would >>> require Java7) or the upcoming TomEE8? >>> I'd say we should focus on TomEE8 and Java8 >> >> >> MicroProfile specs are defined in Java 8, so TomEE8 seems the only option. >> > > CDI 2 is the constraint more than java 8 which works on TomEE 7 ;). That > said converters should still be scannable so java 8 or not is maybe not the > main challenge - not even sure there is a challenge to be honest, just a > clean definition without any redefinition of what is a "context" works :). > > >> >> regards >> Rudy >> >> >> On 15 February 2018 at 09:37, Mark Struberg <[email protected]> >> wrote: >> >>> >>> >>>> Am 15.02.2018 um 07:50 schrieb Romain Manni-Bucau < >> [email protected] >>>> : >>>> >>>> Le 15 févr. 2018 01:35, "David Blevins" <[email protected]> a >>> écrit : >>>> >>>> I understand there's kind of a meta conversation going on that all >> roads >>>> and discussions need to end at there being something to put a >>>> microprofile-jwt git repo. I wave a white flag and gently request a >>>> respite from that as I don't want everything I write to be read as if >> I'm >>>> attempting to steer for or against. >>>> >>>> I'm 100% supportive of reuse. And there could be something of value to >>>> reuse in the end. But at this moment if there was a microprofile-jwt >>> git, >>>> even if that repo was in TomEE, I'm not sold at this point there would >> be >>>> enough code there to justify it. >>> >>> >>> No, there is no meta discussion. This is about reusability in other >>> projects. As clearly stated as that. >>> I think we can easily get this done by splitting it in a core part and >>> then a second part which exposes the JsonWebToken as Principal in various >>> EE apis. The overall structure will become way cleaner imo as it would be >>> highly modular without adding too much overhead. >>> >>>> >>>> I'd probably lean towards getting a prototype done with the mutual >>>> understanding this part of the discussion is still open. >>> >>> +1 >>> >>>> Once we have code >>>> in hand, we can have a more informed discussion and circle back to >> reuse. >>> >>> -1 You have to design with reuse in mind. >>> I'm not talking about making it overcomplicated and unecessarily modular, >>> but just address the things we know already. >>> >>>> >>>>> On Feb 14, 2018, at 11:57 AM, Mark Struberg <[email protected] >>> >>>> wrote: >>>>> >>>>> If you want to have JWT working for ALL EE things then it's not >>>> MicroProfile-JWT anymore, isn't? >>>>> It would be much more. Not bad of course, but still way beyond of what >>>> MicroProfile-JWT defines. >>>> >>>> Chapter 7 "Mapping MP-JWT Tokens to Java EE Container APIs" defines >> about >>>> 11 different integration points across JAX-RS, EJB, Servlets, JACC etc. >>> As >>>> only JAX-RS is a required part of a MicroProfile server and the other >>> parts >>>> are optional, at least 7 out of the 11 integration points are also >>> optional. >>> >>> Thanks for pointing me to this. >>> 'integration points'. Even the spec indicates that the EE part is merely >>> integration work. >>> That might be a lot of work of course. But it would be cool if getting >> the >>> JsonWebToken would merely be one line of code which is in the mp-jwt-core >>> package. >>> >>>> >>>> There are tests for much of them in the MicroProfile JWT TCK. The tests >>> are >>>> also optional, but we'd definitely want to run and pass them as well as >>>> contribute to them if they are incomplete. >>>> >>>> If the spec is incomplete and we did miss an EE integration point, >>>> definitely want to update the spec to cover it. Scott and I and the >>> other >>>> folks who worked on the spec did our best to try and enumerate the ones >>> we >>>> could think of, but we may have missed some. >>>> >>>>> Oh and I assume it does also include a way to _create_ JsonWebTokens, >>>> right? >>>> >>>> The token creation would be done by an OAuth provider, which is outside >>> the >>>> MP JWT specification. >>> >>> Oki, I will start a discussion over at MicroProfile. >>> Thinking about a JsonWebTokenBuilder or something. >>> >>>> >>>> The specification does have requirements that define what the token >>> should >>>> look like, but they're all very minimal so that we could be as >> compatible >>>> as possible with as many existing OAuth provider implementations as >>>> possible. >>>> >>>> Effectively it says the JWT must be signed with an RSA private key the >>>> OAuth Provider owns and assumes the MicroProfile server has been given >>> the >>>> public key. How that public key is passed is also outside the >>>> specification, but generally, it'll be on disk or sitting in the docker >>>> image somewhere. >>> >>> JWT doesn't even require oauth2, isn't? >>> Of course oauth2 _could_ be the payload. But that's no necessity for >>> everyone. >>> Most users will not need that actually. But they might be more interested >>> in having a radius like single sign on via JWT. >>> At least that's what I hear from my customers. >>> >>>> >>>> >>>>> * JSON-P on the json side. >>>> >>>> Agree. This is definitely mandatory to implement the MP JWT spec as >>> claims >>>> can be injected as JsonObject, etc. >>>> >>>>> * crypto: Whether to use the JCE built-in crypto or an external lib >>>> should be pluggable. We just need to add a smallish SPI with a few >>> methods. >>>> >>>> Agree to disagree on this one :) JCE is an abstraction with two well >>> known >>>> impls (OpenJDK and BouncyCastle). It's 3-4 lines to check a signature, >>> so >>>> not much complexity to abstract. >>> >>> Fine for me. This can easily be extendd afterwards IF we need it. >>> >>> >>>> >>>>> * JsonWebToken and a way to get 'the' JWT for a single Request. That >>>> might be a provider interface or a @RequestScoped CDI bean. >>>> >>>> MP JWT spec requires there to be a dependent scoped producer for >>>> JsonWebToken. The bean getting JsonWebToken injected must be >>>> RequestScoped. Currently section 7.1.3 forbids injection into beans >> that >>>> are not @RequestScoped. >>>> >>>> >>>> Any waynto have a fixed spec saying it is not portable to not do so? >>> Having >>>> a deployment exception for a so common case is very rude and not >>> justified >>>> technically. Also using provider as a woraround is not mainstream and >>>> generally way too slow. >>>> >>>> Not that supporting CharSequence can be a smooth workaround for app >> scope >>>> ;). >>> >>> What do you mean here? I totally don't get that. Derailing? >>> >>>> >>>> >>>> With that in mind, I would probably implement JsonWebToken as an >>> immutable >>>> class -- i.e. get the token, then create the JsonWebToken and track >> that >>> in >>>> the request. So ultimately the producer of JsonWebToken needs to get >> the >>>> token from the request rather than the JsonWebToken implementation >>> itself. >>>> >>> >>> +1 for JsonWebTokan as immutable. Snce we do not create it but only make >>> it accessible. >>> >>>> >>>> It is backed by jsonp so immutable by definition no? >>>> >>>> >>>> Not yet discussed, but part of the spec is Claims can be injected as >> any >>>> java type using the same conversion rules as MP Config. >>>> >>>> Xbean-reflect has a large set of code for java-to-string conversion. I >>>> suspect geronimo-config as it's own implementation of java-to-string >>>> conversion. There's probably some opportunity for reuse consolidation >>>> there. >>> >>> hmm, java-to-string would not be possible. The config API only has >>> String->Java. >>> Because the least common denominator (or 'storage') for the config is >>> always String. >>> And from there you convert it to a target Java type. >>> >>> But why do we need java-to-string? We do not WRITE JsonWebTokens, do we? >>> We only read them. Which is string-to-java then, right? >>> And by using JSON-P and JSON-B we could probably defer this as well. >>> >>> >>>> >>>> Potentially even an option for a "Conversion" spec. Andres was talking >>>> about it at the last JCP EC event in London. His JSR-377 (Desktop >>>> Application Framework) apparently has similar needs. >>> >>> Yes, I had a talk wiht Andres about this as well. >>> It's a bit more complicated. >>> For example Andres needs this for the UI. >>> So while in theory both (Config and UI) needs a conversion from >>> string->java it might still work totally different. >>> In the config area you want your string representation to be as portable >>> as possible. Means you betterl _always_ use ISO or any other _fixed_ >> format. >>> Whereas in the UI area it's exactly the other way around. You almost >>> always want the string representation to be for the users Locale and >>> desired language. So even for the same server this might differ even for >>> each request. >>> >>> Back to JsonWebToken. This is really more like config. The string >>> representation is better off being a fixed format. >>> >>>> Makes sense (and without any "context" please, this pollutes config >> spec >>>> and makes it sadly not that portable :(). >>> >>> Well as explained there is a kind of 'context'. I agree it's not that >>> obvious, but there are reasons why even Stephen Coleburn failed to come >> up >>> with a good Converter API for many years now. >>> >>> Btw, with Lambdas any conversion A->B is just a Function anyway. >>> Can we assume Java8 for this attempt? >>> >>> Oh and more important: Will the integration work based on TomEE7 (would >>> require Java7) or the upcoming TomEE8? >>> I'd say we should focus on TomEE8 and Java8 >>> >>>> >>>> -David >>> >>> LieGrue, >>> strub >>> >>> >>
