Jeff/all,
Thanks a lot for the update. That's great news. I just did a brief overview
of the Java EE 8 (and to some extent 9) roadmap from JavaOne at my current
finance client. And while it could be a bit tricky to embrace JSR 375 or
Java EE 8 right now, there are several aspects in use, especially the
"Security Context" similar to other projects and clients I helped before.
Sounds like good timing to aim for an EDR 1 relatively soon and avoid
another Renewal Ballot.
That event could be a little soon, but I believe Ivar speaks in Kiev about
a week from now.
Rudy (and since I was invited with at least 2 other topics I may be able to
join him) has a JSR 375 related session at Java2Days in Sofia. Not sure but
he could also do similar ones at DevoXX BE.
Ivar and maybe others proposed for DevoXX US already I believe. Actually
unless there are any restrictions for events "close to JavaOne", Will
and/or Alex could even join him there since the CFP is still open till Oct
11
https://devoxx.us/ or propose something of their own if they can.
JavaLand 2017 has at least one session by Rudy, and I heard together with
others, that Java EE 8 should get a bit of room and attention in the
Community space, so we may also get a chance for Java EE/375 related
activities like Hackergarten there, too.
What about the java.net shutdown? Does Oracle have a concrete plan or
orders for that, or is it up to individual EGs and Spec Leads?
Alex already created the Google Group for JSR 375 Experts. I added
"Contributors" to offer room for the new contributor category. Alex and
Arjan are also managers in this group. Have to check Bintray, where we
started distributing snapshots, but at least Arjan and myself are admins of
the Bintray organization
https://bintray.com/javaee-security-spec and happy
to add Will, Alex or both as admins, too if they could share their bintray
users with us.
Alex created the Github space or is admin there, too, able to add others or
give them the necessary privileges.
Regards,
Werner
On Thu, Oct 6, 2016 at 11:19 PM, Jeff Tancill <jeff.tancill_at_oracle.com>
wrote:
> Werner/Arjan/all,
>
>
>
> Alex has changed organizations and I can now announce that Will Hopkins
> will be the new spec lead for JSR 375. Will has been a member of the EG
> since the start. More good news – Alex will stay in the EG, so just a swap
> of roles for 2 existing EG members. We’ll be reaching out to the EG to
> start weekly calls and to coordinate on getting the work done to date into
> an ED.
>
>
>
> Please join me in welcoming Will to his new role and please help him get
> the information he needs to pull together an ED 1.
>
>
>
> Thanks,
>
>
> Jeff
>
>
>
>
>
> *From:* Werner Keil [mailto:werner.keil_at_gmail.com]
> *Sent:* Tuesday, October 04, 2016 9:50 AM
> *To:* arjan tijms
> *Cc:* jsr375-experts_at_javaee-security-spec.java.net; Java EE Security API
> - JSR 375 - Experts
> *Subject:* [javaee-security-spec users] [jsr375-experts] Re: Support for
> Liberty added to Soteria
>
>
>
> Arjan/all,
>
> Thanks for the update. IBM, though Ajay officially represents them as per
> JCP.org are also in the EG, so their help is as appreciated as legitimate.
>
> Not sure, if KK who had the lead of the EG F2F during JavaOne shared his
> minutes here, but Alex who was also there hinted, he can't take the Spec
> Lead duties any more because he works in a different area at Oracle now.
> Also security-related, could be more on the Java SE/JDK side, so he won't
> be able to help with that I'm afraid. It could be one of the Oracle
> participants in the F2F including KK himself, but I guess they still need a
> bit to figure that out.
>
> For JSR 375 and others it is approx 6 weeks before the Renewal Ballot.
> JSON-P where a similar question was raised and discussed during JavaOne (my
> own talk and others plus a Hackergarten) is closer to a Renewal Ballot, so
> it should take place either this week or next week, too soon to push out an
> EDR. However, the Spec Lead question also seems a bit closer to being
> solved here and some EG members were equally helpful in keeping things
> going, to JSR 374 should also be in a position to contribute to an EE 8
> release train next year.
>
> Kind Regards,
>
>
> Werner
>
>
>
>
>
> On Tue, Oct 4, 2016 at 3:33 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>
> Hi,
>
>
>
> On Tue, Oct 4, 2016 at 2:46 PM, Werner Keil <werner.keil_at_gmail.com> wrote:
>
> Great to hear. It hasn't been a strong focus there so far, but being among
> those hoping for a "Microprofile" somewhere under Java EE (or next to
> it?;-) IBM and its co-collaborators there will certainly appreciate to hear.
>
>
>
> I hope so to too ;)
>
>
>
> But credit where credit is due, IBM (specifically Alasdair and Paul) have
> been exceptionally helpful in getting Soteria to run on Liberty by fixing
> issues and removing road blocks. Without their help it wouldn't have been
> possible, so a big thanks to them!
>
>
>
> Looking at the JSR detail page: https://jcp.org/en/jsr/detail?id=375
> H1 2017 Final Release
>
> was actually not that wrong after all;-)
>
>
>
> We're actually in pretty good shape. Still some issues to overcome, but
> generally looking good with respect to the authentication epic. TomEE
> support is nearly there as well (one of the last blockers is a very low
> level but important detail reported here: https://bz.apache.org/
> bugzilla/show_bug.cgi?id=60196)
>
>
>
> The authorization epic is a bit more difficult. I put quite an amount of
> time into a prototype for custom authentication rules, but Java EE lacks an
> easy to use hook into its authorization machinery. JBoss, GlassFish and
> Liberty have such hooks, but you can't use them from within a .war. You
> *have* to install a container side module for that. Now principally JSR 375
> has to run as a container module anyway, but this does make testing and
> demonstrating a lot more difficult. Tomcat doesn't have the hooks we need
> at all (although some of the Tomcat roadmap plans did state they wanted to
> look into it). Since Tomcat doesn't have those hooks for the Servlet
> container, by extension TomEE doesn't have them either.
>
>
>
> I've been trying for a long time to get an API for this hook in Java EE,
> but I'm not really getting anywhere. And, even if this API would be
> introduced, it would of course not have any effect on the existing Java EE
> 7 servers on which we'd like to test.
>
>
>
>
>
> However, unless at least EDR 1 goes out within a month from now (target
> was originally Q1 2015) the next Renewal Ballot at the end of November
> alongside nearly half a dozen other Java EE JSRs is inevitable.
>
>
>
> As I understood, it's really only the spec lead (Alex) who can submit
> this, right? Perhaps worth a try to contact him again and ask if he wants
> to submit what we have prepared?
>
>
>
> Kind regards,
>
> Arjan Tijms
>
>
>
>
>
>
>
>
>
>
>
>
>
> Several experts have confirmed JSR 375 talks between now and H1 or Q1
> 2017. Ivar should be in Kiev this month. Rudy (I am also invited with other
> JSRs, might join him if the talks are close enough together) was invited to
> Java2Days in Sofia next month. And at least JavaLand also accepted his talk
> (it looks like at least 2 were proposed in parallel, good they picked one,
> not just MVC;-)
>
> I proposed another session to Codemotion Rome and was proposed as
> co-speaker on JSON JSRs for Codemotion Amsterdam, so probably will also
> offer JSR 375 (anybody wanted to join in on that, CFP is open till the
> 21st. Given Java is not the only language relevant to Codemotion, it seems
> more sensible to do a joint proposal by 2, max 3 EG members than several
> competing proposals on the same JSR there)
>
> Kind Regards,
>
>
> Werner
>
>
>
>
>
> On Sat, Oct 1, 2016 at 7:52 PM, Guillermo González de Agüero <
> z06.guillermo_at_gmail.com> wrote:
>
> Hi,
>
> These are great news! Portability will make it easier for early adopters
> to test it. And also glad to see the IBM team is hearing and helping.
>
> Keep doing this great work, Arjan and all.
>
> Regards,
>
> Guillermo González de Agüero.
>
>
>
>
>
> On Sat, Oct 1, 2016 at 4:36 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>
> Hi,
>
>
>
> I just added support for Liberty to Soteria and added it to the test
> targets.
>
>
>
> See: https://travis-ci.org/javaee-security-spec/soteria/builds/164267239
>
>
>
> For this I used a proprietary feature of Weld where it's possible to do
> the per-request setup somewhat earlier. Weld will make sure that when the
> container (Liberty here) also asks for this initialisation later on, it's
> properly ignored, but does record the request. When the container then
> later on asks to destroy the per-request setup, it's again ignored so that
> we also have the opportunity to destroy it later.
>
>
>
> I introduced a small SPI for this that vendors can optionally implement.
> For now I used reflection to call the Weld API if the server is detected to
> be Liberty. It looks as follows:
>
>
>
> @Override
>
> public void init(HttpServletRequest request) {
>
> Object weldInitialListener = request.getServletContext().
> getAttribute("org.jboss.weld.servlet.WeldInitialListener");
>
> ServletRequestEvent event = new ServletRequestEvent(request.getServletContext(),
> request);
>
>
>
> ELProcessor elProcessor = new ELProcessor();
>
> elProcessor.defineBean("weldInitialListener",
> weldInitialListener);
>
> elProcessor.defineBean("event", event);
>
> elProcessor.eval("weldInitialListener.requestInitialized(event)");
>
> }
>
>
>
> I also had to disable the DB identity store test for Liberty, since it
> depends on an embedded datasource which Liberty does not support.
>
>
>
> Further more, I had to disable the custom form tests for Liberty. It
> depends on the HttpServletRequest#authenticate call, which the current
> version of Liberty (16.0.03 and 2016.9) does not support (but Paul from the
> Liberty team has internally implemented this so it should be available in a
> next version).
>
>
>
> Finally, a hack was needed for the form authentication. This makes use of
> request wrapping, which unfortunately is also not well supported in Liberty
> (but here too, Paul is already looking at it).
>
>
>
> Most importantly, all other tests do run flawlessly, so the majority of
> the implementation of JSR 375 now runs on Payara, JBoss (WildFly) and
> Liberty. It should also be possible to run it on TomEE (although it too
> currently doesn't support request.authenticate), and even on Tomcat with a
> CDI implementation separately added.
>
>
>
> Do note that from a spec viewpoint the RI implementation itself doesn't
> necessarily has to be portable, but I think it's a nice property that it
> largely is.
>
>
>
> Kind regards,
>
> Arjan Tijms
>
>
>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Java EE Security API - JSR 375 - Experts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jsr375-experts+unsubscribe_at_googlegroups.com.
> To post to this group, send email to jsr375-experts_at_googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jsr375-experts/CAAGawe1QSBRJyaUaKNMptnt_%
> 2BReRUr9y2diF19DXOqDWQ-FKMA%40mail.gmail.com
> <https://groups.google.com/d/msgid/jsr375-experts/CAAGawe1QSBRJyaUaKNMptnt_%2BReRUr9y2diF19DXOqDWQ-FKMA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
>