[javaee-spec users] Re: [jsr342-experts] Java EE Meet the Spec Leads BOF at JavaOne

From: arjan tijms <>
Date: Thu, 19 Sep 2013 14:31:06 +0200


Great to see the Java EE 8 topic being discussed. Some feedback on the

About the NoSQL key/value story;

JCache is key/value store as well, and wasn't there some data grid JSR
proposed a while back (loosely based on JBoss InfiniSpan)?

The improved security framework has a couple of aspects.

*What does it mean?*


- No more dependency on vendor specific mechanisms (i.e. a
@DataSourceDefinition equivalent for security)
- A single security API for the entire platform (no more specific and
overlapping APIs for Servlet, JAX-RS, EJB, etc)
- Modernization of APIs (i.e. the JMS2 equivalent for security)

In some more detail:

First and foremost IMHO is fixing the mandatory dependency on vendor
specific mechanisms. It's currently not possible to secure the simplest
possible Java EE application without diving deeply into (obscure) vendor
specific deployment descriptors and/or interacting with a graphical UI.
Mandatory role mapping is probably the worst offender here, but things like
the undefined EJB "security domain" (mentioned in the EJB spec, but not
specified how it should work) and the underspecified @RunAS which always
needs a vendor specific companion for the associated principal, are pretty
bad too.

Adam Bien for example has some simple to use security examples, which
largely or even totally bypass the existing security support in Java EE. If
the simplest way to use a framework is bypassing it and home growing a
solution, then I think something is not entirely right.

Second is alignment of security aspects throughout the entire Java EE
platform. Currently Servlet, EJB, JAX-RS and JCA all have their own APIs
for security. Some overlap. There are 4 different API calls for checking if
the "current user" has a given role. Which one a programmer needs to use
depends on which type of Java EE artifact the code is in. Servlets can use
either standardized authentication modules (via JASPIC) or build-in ones
(FORM, BASIC, etc). The build-in ones are always implemented via a
completely different technology than JASPIC. The security domain mentioned
in the EJB spec can not use standardized authentication modules at all, etc.

Third is the modernization of the APIs. Especially JASPIC is low-level,
targets Java SE 1.4(!) and is mostly J2EE 1.4 like. Just upgrading the API
to target Java SE 7 and using modern Java EE techniques (mainly CDI) would
make a world of difference.

A simple and modern alternative for the "security
providers/repository/login modules" (the "things" that actually contain
credentials like username/password, as opposed to authentication modules
that coordinate the interaction with a user) would also be a big step.
Currently the platform only mentions JAAS login modules (via the JASPIC
bridge profile), but JAAS was never optimally suited for Java EE and has a
somewhat arcane feel these days. (Reza Rahman and myself individually
submitted a nearly identical proposal for this on the Java EE spec JIRA;

*More application APIs?*

Partially. There are some gaps in the current APIs like asking for all
roles of a user, and platform support for things like "remember me",
choosing an authentication authority/method for a "login with" feature and
changing the name and/or roles of a user without requiring a logout/login.
These should definitely be addressed but IMO it's not as important as the
more fundamental issues mentioned above.

*Better declarative security?*

The declarative part has always been pretty good in Java EE. The big change
that's needed is already covered above; alignment with the entire platform.
Things like @RolesAllowed should be applicable everywhere. @RunAs should be
more fully specified. Reza Rahman had a very interesting idea to allow EL
in declarative security. Combined with CDI/Bean Validation-like stereotypes
this could take declarative security to the next level.

 *Security configuration and management APIs?*

Configuration is a very important topic as well, largely part of the "No
more dependency on vendor specific mechanisms" story. Configuration of the
actual "login module" (for use with the high level FORM, BASIC etc
authentication modules) is now completely vendor specific. Curiously,
declarative configuration of the standardized JASPIC authentication modules
is currently also vendor specific. The only standardized method is
programmatically via a not entirely trivial API. Configuration should make
it easy to set both the (JASPIC) authentication module (taking care of the
user interaction) and if applicable the login module/security-provider (the
credential store).

Reza Rahman again had a very interesting idea here (JAVAEE_SPEC-28) for the
higher-level declarative configuration of a few well known "login
modules/security providers" (basically the login module equivalent of the
high-level and well known authentication modules FORM,BASIC etc).

About the configuation:

*What does it mean? / need more use cases*

Many people have asked for placeholders in deployment descriptors. A couple
of vendors ((e.g. JBoss) already supports this for their own descriptors.
The ability to use EL for the placeholder syntax would be great. Values
should come from system properties (-D commandline) and there should be the
possibility to specify a properties file at the commandline from which the
values can be used as placeholder or would just become system properties

Another thing is being able to select (fragments) of deployment descriptors
that all reside within the application. The use case is for an application
that is solely deployed in house and as such there is a small and finite
amount of servers (stages) to which this application is deployed (e.g.
localhost, dev, beta, live).

The application can then contain e.g. a version of a web.xml fragment that
just contains the <data-source> element for each such stage, and the right
one can be selected via a commandline option. In practice I've often seen
applications home grown something like this or use build tools like
Ant/Maven to do this at build-time. Both solutions are not ideal.

About the logging improvements:

One use case I didn't see is being able to configure what Java EE itself
logs. I'd like to say that JPA (whatever implementation) should not log
anything. Or that JPA should log queries, or that JSF should log everything
there is, etc.

About Java EE 7 maintenance releases:

There's a small typo here. It should be JASPIC 1.1, not 1.2 ;)

Kind regards,
Arjan Tijms

On Thursday, September 19, 2013, Bill Shannon wrote:

> Bill Shannon wrote on 9/11/13 4:57 PM:
> > Just a reminder that we have our usual "meet the spec leads" BOF
> > on Tuesday, September 24, 4:30 - 5:30 in Parc 55 - Cyril Magnin I.
> > I hope to see many of you there!
> >
> Attached are the slides I'm going to use for the BOF.
> We'll briefly review EE 7 then take questions from the
> audience. If they don't have much to say, we'll show
> them our ideas for EE 8 and get their feedback. Most
> of the slide deck is the latter. If you have any comments
> on what's there or what's missing, let me know. Note that
> we may not talk about this at all at the BOF, but I'm
> expecting to reuse it for our EE platform EG meeting on
> Wednesday.