[javaee-spec users] Re: [jsr342-experts] report on EG meeting at JavaOne

From: arjan tijms <>
Date: Fri, 4 Oct 2013 14:24:54 +0200


On Friday, October 4, 2013, Bill Shannon wrote:

> arjan tijms wrote on 10/03/2013 05:32 AM:
> > Hi,
> >
> > Thanks for the report. Some comments:
> >
> >
> > On slide 17, just to make it clear for everyone, "standardize
> authentication"
> > is really about simplifying the process. Authentication in Java EE is
> > theoretically standardized already (via JASPIC).
> JASPIC standards how to plug in an authentication provider. I think the
> issue
> here was to have some standard authentication providers already available
> for
> applications.

Ok, got it. The confusion was perhaps because the slide referenced
JAVAEE_SPEC-9, which is the issue about simplifying the "login module" part
of an auth module and standardizing how a JASPIC auth module is embedded
into an application declaratively (currently the only standardized way is a
not entirely trivial programmatic method).

Having some "login modules/security providers" already available is what
JAVAEE_SPEC-28 is about.

> > On slide 19, "JAX-RS MVC"
> >
> > I agree with the central question "Do we really need another standard web
> > framework?", and would like to specifically add the question "*Why*
> would we
> > want a second web framework?"
> >
> > Is it because JSF is not popular enough, or are there specific use cases
> > can't address?
> This is exactly what we need feedback on from the community.

What I'm personally seeing again and again in discussions (eg reddit,
dzone, so) about this topic is the stateful/stateless issue. I may be
wrong, but I think this particular topic dominates most action-oriented vs
component-oriented discussions.

Sometimes though people just like the pattern of having a clear "entry
point" where request processing starts, and then there are a few people who
like to be in total control of their markup (but those are offset by even
more people who just like to put a high-level component like a progress bar
on their view and be done with it).

> On slide 31 and 32 "ReST APIs to deploy and manage applications" and "ReST
> > APIs to monitor applications"
> >
> > It's perhaps interesting to remember that Java EE had an API/SPI here
> with JSR
> > 88 and JSR 77, but they were pruned for Java EE 7 (see e.g.
> >
> ).
> Right, do we believe they aren't used because they were poor APIs?
> Because they
> used the wrong technology? Will converting them to use ReST suddenly make
> them
> more attractive?
> I don't think the answers are clear.

I very briefly looked into JSR 88 and to me it seems a lot of effort was
wasted in providing interaction points with non-standard properties of an
application server. Just starting and stopping a server, plus deploying and
undeploying a simple application archive *seemed* to be regarded as a minor
use case, while I think people expected that to be the most important one.

See this old topic: and
specifically the 3rd comment:

    "Given that, the spec must assume that the user needs to interact with
the beans in order to specify their deployment information to the server.
That would seem to leave Ant right out of the picture. "

In 2002 things may have been different as I guess far less was standardized
then, but I'm not entirely sure if this assumption would make much sense
today. There's IMHO not much need for mandatory "deployment information".
There's a .war, .jar, .ear etc and for the main use case that's it.

Maybe it's worth it to look to Arquillian containers for this story, which
abstract the same start/stop/deploy/undeploy functionality but in a
seemingly more pragmatic way.

ReST would only work for an already running server, so for starting the
server there's still a non-ReST solution needed. But all in all, ReST can
make the APIs more attractive. What I got from Arquillian discussions is
that JSR 88 was also troublesome from the tool vendor perspective, since it
required linking to binaries. Linking to binaries frequently involves
licensing issues (either incompatible open source licenses, or closed
source/non-distributable jars like is the case for WebLogic). I think tool
vendors try to avoid that.

> > Maybe it would also have been interesting to see what the votes would
> have
> > been with Oracle attendees included.
> We didn't want to skew the results; we were more interested in what others
> thought.

I see. Where there also non-EG attendees that voted, or only EG members?
Maybe it would be interesting to see the distinction between EG/non-EG
members, instead or Oracle/non-Oracle. Otherwise you maybe want to exclude
JBoss attendees as well from voting where it concerns CDI, as they lead the
CDI spec. Or am I missing the point here?

> And there seemed to be support for it during the discussion, but in the
> end no
> one voted for it. Sometimes you have to make difficult choices when you
> have a
> limited number of dollars to spend...

I understand this more than anything (often have dealt with the same thing
internally in my company). Hopefully the security topic can get some more
support down the road though.

Kind regards,
Arjan Tijms