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 <HYPERLINK "mailto:arjan.tijms_at_gmail.com" \narjan.tijms_at_gmail.com> wrote:
Hi,
On Tue, Oct 4, 2016 at 2:46 PM, Werner Keil <HYPERLINK "mailto:werner.keil_at_gmail.com" \nwerner.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 <HYPERLINK "mailto:z06.guillermo_at_gmail.com" \nz06.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 <HYPERLINK "mailto:arjan.tijms_at_gmail.com" \narjan.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(HYPERLINK "
http://request.ge" \nrequest.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 HYPERLINK "mailto:jsr375-experts+unsubscribe_at_googlegroups.com" \njsr375-experts+unsubscribe_at_googlegroups.com.
To post to this group, send email to HYPERLINK "mailto:jsr375-experts_at_googlegroups.com" \njsr375-experts_at_googlegroups.com.
To view this discussion on the web visit HYPERLINK "https://groups.google.com/d/msgid/jsr375-experts/CAAGawe1QSBRJyaUaKNMptnt_%2BReRUr9y2diF19DXOqDWQ-FKMA%40mail.gmail.com?utm_medium=email&utm_source=footer" \nhttps://groups.google.com/d/msgid/jsr375-experts/CAAGawe1QSBRJyaUaKNMptnt_%2BReRUr9y2diF19DXOqDWQ-FKMA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.