My fault, you're right. JAX-RS is part of the WebProfile.
Arjan, with the latest changes to the return enums you made, is JASPIC
still strictly speaking a hard dependency?
If JASPIC is a concern, may the JSR 375 spec be reworded to mandate it
*only* on the full profile and just recommend it on other environments?
Regards,
Guillermo González de Agüero
El mar., 11 de abril de 2017 10:02, Romain Manni-Bucau <
rmannibucau_at_gmail.com> escribió:
> JAXRS is not part of webprofile? was in EE 7 so should be in EE 8 IMHO.
>
> Anyway back to security: the usage of jaspic is IMO a blocker, not
> integrated to CDI, not natural, and needs a lot of "tool" code to work
> (Arjan samples are great to realize it), so if EE security wants to use
> jaspic it should hide all that (and nicely make it not mandatory by that
> track, but that's just a nice side effect ;)). Said otherwise I kind of
> worry that to be usable we need omnifaces or a soteria tool module - not
> saying they are bad but that the entry cost is way too high.
>
> Concerning the "is SE in scope" I'm not sure but if you rephrase is "is
> not HTTP in scope" then it should be by design cause EE has concurrency
> utilities, jbatch, @Asynchronous, @Schedule etc... which can use security
> either by propagation or by direct late invocation. A very high part of
> these usages will not work with HTTP (note the propagation will be crucial
> and should be spec-ed at EE level to avoid a usage mess). If it is bridged
> and user still relies on HttpAuthenticationMechanism then the API is
> still unatural, will need mocking (which rarely helps to understand it) and
> will still require this state and protocol handling which will makes the
> adoption step way higher than it should be IMHO.
>
> For all these doubts I don't think we are ready to be prime time so full
> profile only is saner for this release until a huge amount of work is done.
>
> Side note 1: mvnrepository stats are limited which means they can't be use
> to check adoption (ex: deltaspike security api is more the ~ 2600 download
> *last month*). This fully ignore ("normally") the company frameworks which
> are nuuuummmeeerous for security and all end user applications.
>
> Side note 2: not sure how polls help, think we should rather try on real
> application the API to see how it fits and what's the gap cause polls are
> really biaised, in particular on tweeter where network are partial until
> you hit 100k followers for most person retweeting.
>
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-04-11 9:36 GMT+02:00 Guillermo González de Agüero <
> z06.guillermo_at_gmail.com>:
>
> I personally think bringing JASPIC to the Web Profile is not a big deal
> since, as have been said, all mayor plain Servlet Containers already do
> that, and even the Servlet spec has been talking about explicitly requiring
> it.
>
> JACC is another story, but then, JSR 375 can work without it so that's not
> a problem at all.
>
> So big +1 from me on adding JSR 375 to the web profile, even if that needs
> to also pull JASPIC.
>
> El mar., 11 de abril de 2017 0:53, arjan tijms <arjan.tijms_at_gmail.com>
> escribió:
>
> Could be a good idea indeed.
>
> I'm of course strongly, strongly biased, but I know from application
> development and working with a lot of different devs in application
> development, that something like a basic security for JAX-RS endpoints in a
> fully portable and app controlled way is something that comes up each and
> every time.
>
>
> Interestingly, JAX-RS is not part of the Web Profile.
>
>
> Basically just something like defining this: (pre JSR 375 syntax)
>
> http://arjan-tijms.omnifaces.org/2014/11/header-based-stateless-token.html
>
>
>
> On Tue, Apr 11, 2017 at 12:47 AM, reza_rahman <reza_rahman_at_lycos.com>
> wrote:
>
> If needed, I suggest doing a simple community poll (e.g. via Twitter) to
> help determine this. As I said, I suspect there is very strong desire for
> this functionality in all profiles.
>
> What do other people in this EG think? I know activity has been sparse for
> quite a few months, but surely we all have some opinions on this?
>
> -------- Original message --------
> From: reza_rahman <reza_rahman_at_lycos.com>
> Date: 4/10/17 4:38 PM (GMT-05:00)
> To: users_at_javaee-spec.java.net
> Subject: Re: [javaee-spec users] Re: [jsr366-experts] Java EE Security API
>
> I actually think what we have now is pretty useful. Given the strong
> support for security in all the Java EE surveys, I think it sends the wrong
> message not to include it in the Web Profile. I don't see that there is any
> future where the security API does not wind up in pretty much all
> significant Java EE profiles.
>
>
>
>