I don't think the Web Profile will end up as a Legacy profile, but there
will have to be a certain number of profiles or "catalogs" to use.
The MicroProfile idea is not new, it came from discussions in prior EE-spec
mailing lists and EGs for nearly a decade.
Unless defining those profiles became proprietary and vendor-specific (as
in Java ME or J2ME before it) there have to be a few, but I'm not sure, if
the responsible decision makers at Oracle have fully made up their mind
which way to go.
Eclipse where MicroProfile is trying to evolve shows, that Open and closed
source solutions can exist side-by side, so having at least a minimal set
of standard APIs to use is better than none or everything proprietary like
Spring Security and all the others.
Werner
On Tue, Apr 11, 2017 at 2:35 PM, Romain Manni-Bucau <rmannibucau_at_gmail.com>
wrote:
> Issue is EE doesnt have a remove process well defined (for a good reason)
> so if we add something then we'll not remove it even if we get a smooth API
> in 2 years or for EE 9 which will quickly create a web profile = legacy
> profile. This is less impacting for the full profile.
>
>
> 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 14:29 GMT+02:00 Werner Keil <werner.keil_at_gmail.com>:
>
>> On Tue, Apr 11, 2017 at 2:13 PM, Ondrej Mihályi <ondrej.mihalyi_at_gmail.com
>> > wrote:
>>
>>> Hi,
>>>
>>>
>>>> So if I try to summarize it seems a lot of shortcuts have been taken
>>>> cause of resources so regarding the addition or not of the spec to EE I
>>>> think the question is: are we happy enough of current state to make it part
>>>> of the platform or does it need more work to be at the level of something
>>>> we want to support for year. For me it has a small of unfinished, in
>>>> particular at platform level (at spec level itself it is usable with choice
>>>> you agree or not). The lack of other spec integration is kind of a blocker.
>>>> It hurts EE at several other places like CDI/servlet async, concurrency
>>>> utilities/async, CDI/JAAS, JAX-RS/CDI, CDI/Servlet scanning, ... and each
>>>> time it bites the platform and makes it look unfinished. Would be great to
>>>> avoid it for the security which is very important for all companies and not
>>>> a place where we can accept half full glass IMHO.
>>>
>>>
>>> *In other words, are we OK with having at least something in the
>>> WebProfile or we'd rather wait another couple of years until all is
>>> polished?*
>>>
>>>
>> With Java EE 8 and its current pace, it would not be more than another
>> year, but I would rather have what is working out now.
>> In an Agile and Iterative spirit of jcp.next (also see the adoption or
>> Individuals often far more involved than companies, not to mention those
>> who prefer to stay ouside th JCP;-|)
>>
>> Take MVC. While it is better to make it available to the community and
>> allow Ivar plus a few others (similar to what Arjan et al did in 375) to
>> get it Final there is still quite some doubt, if the industry would ever
>> pick it up like e.g. the Batch JSR or (slower but in the Financial industry
>> it moves at a different pace) and others were quickly adopted.
>>
>> Unless players like Vaadin or even Spring considered using it, hard to
>> say how well it'll do. It is certainly far too late compared to Struts,
>> Wicket or Spring MVC just to name 3 out of 300 or more MVC frameworks for
>> the JVM alone.
>>
>>
>>> The question is valid and full EE profile could provide an incubation
>>> for the spec and after it's improved after real life feedback, it could
>>> become part of Web Profile too. However, here are some objections from my
>>> side:
>>>
>>> - WebProfile is usually adopted faster, by more flexible companies and
>>> runtimes, and before real adoption, we can't receive a relevant real-life
>>> feedback. If the JSR is only in the full profile, the feedback would come
>>> much later
>>>
>>> - From all the previous arguments, I don't see anything prevent a later
>>> improvement while maintaining backward compatibility - the drawbacks
>>> mentioned (mostly by Romain) are about what is missing, and not about what
>>> is wrong and would possibly need to be changed in the future. The security
>>> spec can be improved later in EE 9, specifying all the missing pieces. My
>>> only concern is whether it can be easily integrated with other solutions to
>>> provide the missing pieces, e.g. as a CDI extension or something else. I
>>> guess the answer is "partially", but I think it's still far better than a
>>> 100% custom solution for security. Projects like Omnifaces or Deltaspike
>>> can provide the missing pieces until they are standardized later.
>>>
>>> - I understand that only a part of JASPIC, which applies to the servlet
>>> container plus a few generic types, is required by the security JSR.
>>> Therefore only a small portion of JASPIC is required and is already
>>> available in Web Profile. This should be clarified in the Web Profile spec
>>> if the security JSR becomes part of it.
>>>
>>>
>> JASPIC is quite an old JSR https://jcp.org/en/jsr/detail?id=196 Hard to
>> say, if "modularizing" it will be possible.
>>
>> Take CDI 2, it was a tedious and painful process to do this now and break
>> it up into pieces, not so different from the never-ending "Jigsaw" effort
>> in Java SE 9.
>>
>> Werner
>>
>>
>>> Ondrej
>>>
>>> 2017-04-11 13:49 GMT+02:00 Romain Manni-Bucau <rmannibucau_at_gmail.com>:
>>>
>>>>
>>>>
>>>> 2017-04-11 13:37 GMT+02:00 arjan tijms <arjan.tijms_at_gmail.com>:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Apr 11, 2017 at 12:42 PM, Romain Manni-Bucau <
>>>>> rmannibucau_at_gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>> 1. There are no available hooks in Java EE to take advantage of to
>>>>>>> introduce those
>>>>>>>
>>>>>>
>>>>>> Not sure the point there since all containers would get these hooks.
>>>>>> A JSR doesnt have to be portable but just to provide an API which can work
>>>>>> so don't think it is a blocker.
>>>>>>
>>>>>
>>>>> It's not a blocker in the technical sense indeed. If we really wanted
>>>>> it, such hook (its behaviour/SPI at least) could have been defined.
>>>>>
>>>>> But unfortunately we just had very, very little resources. Basically
>>>>> 99% of JSR 375 was developed from my side on the commute from and back
>>>>> home, as that was all the time I had left.
>>>>>
>>>>> It's an order of magnitude easier to use things that are already
>>>>> there, then to invent / spec new ones ;)
>>>>>
>>>>>
>>>>>
>>>>>> 2. There are very few if any existing mechanisms to use as examples
>>>>>> for these containers
>>>>>>
>>>>>>> 3. Demand for them is quite low
>>>>>>>
>>>>>>
>>>>>> Batch and @Async are not rare actually.
>>>>>>
>>>>>
>>>>>
>>>>> I agree, although I think what you want most here is a "login" method,
>>>>> meaning; skip the authentication mechanism (since there's not always a
>>>>> caller to interact with) and directly set the authenticated identity. Such
>>>>> method was on the roadmap, but we just didn't get to it. Again, available
>>>>> resources were incredibly low. I'm half surprised we still got as much done
>>>>> as we did.
>>>>>
>>>>> As a true authentication mechanism for @Asynchronous, yeah, that would
>>>>> be cool. But some thinking would have to go into how it would exactly
>>>>> interact with the caller. Throwing CDI events? The caller putting data in
>>>>> the event as response?
>>>>>
>>>>> From our previous discussions about @Asynchronous and the enhanced CDI
>>>>> version of that, you probably remember how much I would have liked to see
>>>>> that in Java EE 8, but because of time constraints it just didn't happen.
>>>>>
>>>>> Also, regarding the @Asynchronous annotation, it would have needed
>>>>> some cooperation of either the Concurrency spec or EJB spec, but neither
>>>>> were active during EE 8 :(
>>>>>
>>>>>
>>>>>
>>>>>> Well it is cause of AuthenticationStatus and HttpMessageContext
>>>>>>
>>>>>
>>>>> I wouldn't quite call that a state machine. AuthenticationStatus is
>>>>> mainly so the code calling it programmatically knows what to do.
>>>>>
>>>>> SUCCESS -> huray, we can use the principal. IN_PROGRESS -> The
>>>>> mechanism took over the response and I can't touch the response myself now,
>>>>> FAILURE -> I need to handle the failure somehow, i.e. by setting an error
>>>>> message.
>>>>>
>>>>> Is that a state machine, or just handling a response code? I dunno ;)
>>>>>
>>>>
>>>> Well you have the notify methods etc implying a state machine you need
>>>> to know as a user. Put another name if you prefer but point was it is a big
>>>> complicated as a central API.
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Maybe I missed something but the store doesn't secure by itself, I
>>>>>> see it as the LoginModule for JAAS which is actually not the API you use to
>>>>>> validate a context. So it is good it is not protocol specific (kudo on
>>>>>> that) but we still miss some server in between no?
>>>>>>
>>>>>
>>>>> Indeed, the store doesn't secure by itself. It's a protocol
>>>>> independent "database" of sorts. It's exactly like the LoginModule
>>>>> (LoginModule could bridge to IdentityStore, another thing that was planned
>>>>> but not realised). You put a credential in, you get an authenticated caller
>>>>> and optionally groups out.
>>>>>
>>>>> The one element that we didn't get to as mentioned above is something
>>>>> to directly set the outcome into the container without a mechanism in
>>>>> between. In terms of Servlet (but just as an example) that would correspond
>>>>> roughly to what HttpServletRequest#login does behind the scenes.
>>>>>
>>>>
>>>>
>>>> So if I try to summarize it seems a lot of shortcuts have been taken
>>>> cause of resources so regarding the addition or not of the spec to EE I
>>>> think the question is: are we happy enough of current state to make it part
>>>> of the platform or does it need more work to be at the level of something
>>>> we want to support for year. For me it has a small of unfinished, in
>>>> particular at platform level (at spec level itself it is usable with choice
>>>> you agree or not). The lack of other spec integration is kind of a blocker.
>>>> It hurts EE at several other places like CDI/servlet async, concurrency
>>>> utilities/async, CDI/JAAS, JAX-RS/CDI, CDI/Servlet scanning, ... and each
>>>> time it bites the platform and makes it look unfinished. Would be great to
>>>> avoid it for the security which is very important for all companies and not
>>>> a place where we can accept half full glass IMHO.
>>>>
>>>>
>>>>>
>>>>> Kind regards,
>>>>> Arjan Tijms
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Kind regards,
>>>>>>> Arjan Tijms
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> 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-statel
>>>>>>>>>> ess-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.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>