[javaee-spec users] Re: [jsr342-experts] Wish-List for EE 8

From: Peter Pilgrim <>
Date: Tue, 16 Jul 2013 19:52:55 +0100

Hi all

I agree with the approach of moving administration object to declarative
notations. Java EE security absolutely requires rethinking. As for the EJB
vs CDI container, I think this is one for the implementors. Can EJBs be
built entirely from CDI APIs ? Probably. Then there is the question of
Cloud: I think in 2013 it is still very much immature still. It may be
worth getting some buy-in from today's Java cloud providers, who are in the
business: Heroku, CloudFoundry, JElastic, Red Hat and Cloudbees.

I would be interested in Java EE 8 discussion at JavaOne. On the other
hand, as somebody who sees Java EE 6 issues, WebSphere 7 today, JAX-RPC
incompatible development libraries with Xerces, and other stuff. We still
have a long way to go in industry. Getting to people to look at Java EE 7
is still path to be conquered.

On 16 July 2013 13:13, arjan tijms <> wrote:

> Hi,
> On Monday, July 15, 2013, Werner Keil wrote:
>> Markus/all,
>> Thanks for the link. There are indeed a few JSRs that either didn't make
>> it into EE 7 (like the 2 Cache-related ones) or were never intended for it
>> from a schedule perspective (though some "widely respected IT magazine
>> thought otherwise[?]) but should play a vital role under the hood and
>> between other JSRs for EE 8.
>> 350, 351 (it may not have the answer to all Security questions, but tries
>> to address some, especially authentication, Single Sign-On, etc.)
> Thanks for pointing out JSR 351 (Identity API) which I forgot to mention
> on my blog. This has been in the works for some time, and it started to use
> CDI relatively early on. So this one is surely a good example of security
> infrastructure building on modern APIs.
> Ron is probably the one most suited to answer this question, but I wonder
> if the Identity API is going to be that overal "general" security framework
> in Java EE that will replace/unify things like
> HttpServetRequest#isUserInRole. I read through the available API a while
> back but couldn't yet fully wrap my head around it. I'll make sure to take
> another look soon though.
> If it is however not intended to be that overal general security
> framework, then having it around may actually complicate the situation
> for the end user. There will then be JAAS, JACC, JASPIC, JIAPI (Java
> Identity API) and portions of Servlet, EJB and JAX-RS all dealing with
> security. On top of that if vendors (mainly) keep emphasizing their own
> technology for authentication modules instead of JASPIC, then the end user
> has to deal with that as well. Depending on the situation this will thus be
> a maximum of 8 different technologies to deal with. In practice it's
> probably less, but it's still a lot.
> Kind regards,
> Arjan Tijms

Peter Pilgrim,
**Java Champion**,
Java EE Software Development / Design / Architect for `BlueChip'
enterprises, London, UK
Author of ``The Java EE 7 Developer Handbook'' to be published by Packt Pub
(September 2013)
JavaFX ++ Scala ++ Groovy ++  Android ++ Java
::  ::
:: ::
:: ::
:: Skype Call peter_pilgrim ::
::  ::

(image/gif attachment: 338.gif)