Hi,
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.
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;-)
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.
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().ge
>> tAttribute("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
>>
>>
>>
>