[jax-rs-spec users] Re: Digest for list

From: Werner Keil <>
Date: Mon, 2 Jun 2014 12:59:59 +0200


Thanks for detailed messages. It makes sense to align JSF with that and
regarding MVC I mentioned, that the "Flowlet" features in Java EE 7 already
used JSF primarily.
Angular and all those other .JS frameworks or libraries are not only
client-based, but aside from small Java or other parts they usually share
the same scripting language (JavaScript) both on the client and server
side. This may be a nice PoC and in some cases (when you require little or
no actual "Business Logic" in an Enterprise scale) it may even work on the
server side, but while quick (and dirty[?]) in many cases, few of those
proof to be as scalable as let's say Java EE.

In an Internet of Things era, you may see "semi-smart" servers or Embedded
containers (which is why I hate the term "Embedded" in the EE 8 context,
creates too much ambiguity in a Java Ecosystem where ME, SE and EE grow
seemlessly together already[?]) with a certain level of semantic
intelligence to handle sensor readings, business transactions from "Edge
Node", etc. these "Node" or "Angular" systems seem appropriate to gather
Small or Medium sized Data, but what's more often called BigData will
remain the domain of "Big Enterprise Systems" and you won't see that change
I am pretty sure.

Kind Regards,

 Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
Eclipse UOMo Lead, Babel Language Champion | Apache Committer

Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social |
Skype werner.keil | Google+

On Mon, Jun 2, 2014 at 11:15 AM, <> wrote:

> Table of contents:
> 1. [jax-rs-spec users] Re: [jsr339-experts] MVC - arjan tijms <
> 2. [jax-rs-spec users] Re: [jsr339-experts] Re: MVC - arjan tijms <
> ---------- Forwarded message ----------
> From: arjan tijms <>
> To:
> Cc:
> Date: Mon, 2 Jun 2014 00:46:17 +0200
> Subject: [jax-rs-spec users] Re: [jsr339-experts] MVC
> Hi,
> On Thu, May 22, 2014 at 11:05 PM, Santiago Pericas-Geertsen <
>> wrote:
>> As you may have seen in the Java EE 8 survey, there was significant
>> interest in adding an MVC framework to the platform in EE 8. After some
>> analysis, we are convinced that the best place for this work is in
>> In fact, as many of you may recall, this was on our list for
>> JAX-RS 2.0 but we've never got a chance to discuss it in any detail.
> First of all I like to mention I really like JAX-RS as it is and have been
> using the technology for pretty much every web service that I've
> implemented.
> However, I'm not a really big fan of the current plans of adding MVC and
> SSE to it. Combined with the fact that JAX-RS still has its own injection
> (@Context) despite a platform standard for this and some of its own
> security types (e.g. SecurityContext) that could have been useful for the
> entire platform, I fear that users might increasingly get the feeling that
> JAX-RS is a kind of full stack framework itself. With JAX-RS being a part
> of Java EE which is a full stack framework, I'm not sure if we aren't
> confusing users with such a setup.
> The question is also why specifically a RESTful web services framework
> should be extended with an MVC framework. Web services are about doing a
> very specific thing and I have a feeling that an MVC web framework is not
> exactly that thing. I guess people might frown about the idea of
> introducing an MVC web framework into JAX-WS, but what is really the
> difference between those two? Why would it be acceptable to add an MVC
> framework to one type of web services framework, but not to the other?
> As an extreme and obviously not realistic example, but wouldn't it also be
> somewhat similar to extending EJB with an MVC framework in such a way that
> e.g. rendered pixels or even high level graphics commands for some toolkit
> are sent over the @Remote RMI/IIOP connection?
> One explanation that I've seen (in the SSE thread) is that JAX-RS should
> be extended with the MVC framework because it has such a modern and nice to
> use @Path annotation for routing URL requests, as compared to Servlets
> which only has the more primitive @WebServlet with rather crude URL
> patterns. If that is indeed the case, couldn't it be a possible alternative
> to take the @Path annotation out of JAX-RS and separate it into its own
> spec dedicated to URL routing? (e.g. the URL routing JSR). That way the
> entire platform (specifically Servlet and JSF) could use the advanced URL
> routing and path/parameter extraction features and there might not be a
> need anymore to increase the size of a web services framework with an MVC
> framework.
> Things like this have been done before, e.g. EL was separated from JSP and
> JSF, and persistence was separated from EJB (as JPA).
> There's obviously much to discuss at a technical level concerning how JSF
> can take advantage of action oriented concepts and in what way this could
> be implemented best, but perhaps we should focus first on the question of
> whether it's really a good idea or even needed to do any part of this
> specifically in JAX-RS?
> Kind regards,
> Arjan Tijms
> ---------- Forwarded message ----------
> From: arjan tijms <>
> To:
> Cc:
> Date: Mon, 2 Jun 2014 01:26:11 +0200
> Subject: [jax-rs-spec users] Re: [jsr339-experts] Re: MVC
> Hi,
> On Fri, May 30, 2014 at 9:11 PM, Bill Burke wrote:
>> I am 100% against MVC in JAX-RS. Are we really going to introduce a
>> legacy and now defunct pattern to JAX-RS? The trend and future is Angular
>> JS or GWT apps with simple RESTful back ends.
> I'm personally not of the opinion that AngularJs is the definite future.
> While I appreciate its place in the toolset that's available to developers,
> IMHO there are tradeoffs between a single-page application and individual
> pages, and between JSON that after arrival on the client still needs to be
> processed and transformed before it can be rendered vs ready-to-render
> HTML. But, while an interesting discussion itself, this might not be the
> best place to discuss it ;)
> However, what is interesting here is that the action oriented pattern (and
> then as it seems more or less specifically in the way that Spring MVC
> implements it) is just one of the many approaches.
> Obviously component based (MVC with pull semantics) has a big share of
> fans, as JSF often ranks highly in surveys and sees much activity on e.g.
> SO. As one of the developers of the OmniFaces library for JSF I often get
> feedback that people like the work we do and like working with JSF. The
> pattern also has a couple of other representatives like Wicket and
> Tapestry, which each have their own share of fans as well.
> But as Bill points out here, there's also AngularJS and with it a whole
> slew of client-side frameworks like it (in fact, there seems to be a new
> one every few weeks). Clearly this approach has its following just as well.
> Then there's yet another model which is about largely abstracting from
> HTTP and HTML and building web UIs with pure Java in a style similar to
> Swing/AWT/SWT etc. I'm not too familiar with Vaadin, but if I'm not
> mistaken it's of this category.
> Next to that there are some things like Node.js, which focus on
> asynchronous processing above all.
> What I not rarely see is that fans of one approach dislike the other
> approaches, and in some cases may be very vocal about it. Maybe it's from
> this advocacy that the feeling has arisen that Java EE needs an "MVC"
> framework (actually "action oriented" framework). But if this is indeed
> added to Java EE, wouldn't the next advocacy group ask for a Vaadin clone?
> And then for a Node.js clone, etc? Where does this end? Java EE including
> clones of each and every type of other framework?
> While I think it can definitely be worthwhile to investigate how JSF can
> further benefit from action oriented concepts (i.e. in the way that e.g.
> Scala married functional and object oriented concepts), I'm not sure it's
> really the best idea to have one or even more standalone (as in: fully
> separated from JSF) additional web frameworks in Java EE.
> Kind regards,
> Arjan Tijms
> End of digest for list - Mon, 02 Jun 2014

(image/gif attachment: 329.gif)

(image/gif attachment: 347.gif)