From: Frans Thamura <frans_at_meruvian.org>
Date: Wed, 28 May 2014 18:13:53 +0700

Just curious

Will in the future action framework arrive to jcp?

Standardize springmvc and struts, and integrate to jaxrs?

So.if result is json, equal jaxrs, if result is html, back to action
framework

This wont happen of sun didnt hijack popularity struts and recreate jsf.

F
On May 28, 2014 5:58 PM, "Werner Keil" <werner.keil_at_gmail.com> wrote:

> Tham/all,
>
> +1
> Sounds like a good argument.
>
> While CDI events primarily aim at Java code inside a container or in a
> distributed scenario (but rarely with other code like WS do) those have
> been around for quite a while now, too:
> http://docs.oracle.com/javaee/7/tutorial/doc/cdi-adv005.htm
>
> I happen to be involved or helped Spec Leads make up their mind in cases
> like State Management (JSR 150) or the hopefully soon proposed Config JSR.
> And they all talk about events, too.
> JSR 107, overly hyped by some, but still dissapoiting in the EE 8 context
> (e.g. throwing away Transaction Support which large Enterprise apps won't
> like to miss[?]) also got redundant, mostly client-side aspects of events
> AND configuration (IMHO if 107 was to be worthy of EE 8 and a Config JSR
> also part of the same "Umbrella", they MUST get their act together and 107
> adapt or even prune some of its own configuration subsystem, otherwise
> you'd have a "Config Hell" all over again and we might as well forget about
> the Config JSR[?])
>
> So we should try to avoid "too many wheels" being reinvented for SSE, too.
> Having 4 competing and largely incompatible representations of Date/Time in
> Java SE 8 should not become a blueprint for EE 8 to do the same there in
> some cases[?]
>
> Werner
>
> On Wed, May 28, 2014 at 11:15 AM, <users-request_at_jax-rs-spec.java.net>wrote:
>
>> Table of contents:
>>
>> 1. [jax-rs-spec users] Re: [jsr339-experts] Re: [javaee-spec users]
>> [jsr342-experts] Server-Sent Events in Java EE 8 - <zarub2k_at_gmail.com>
>> 2. [jax-rs-spec users] Re: [jsr344-experts mirror] JAX-RS MVC - Frank
>> Caputo <frank_at_frankcaputo.de>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: <zarub2k_at_gmail.com>
>> To: users_at_jax-rs-spec.java.net
>> Cc:
>> Date: Tue, 27 May 2014 17:46:08 +0000 (UTC)
>> Subject: [jax-rs-spec users] Re: [jsr339-experts] Re: [javaee-spec users]
>> [jsr342-experts] Server-Sent Events in Java EE 8
>> Hi,
>> IMHO, both websockets and SSE can be used in 2 different context. If we
>> want to communicate in both ways we can rely on web sockets.
>>
>> Where as SSE will update the client whenever there is a need. It will
>> avoid the request from the client. Client listener will be notified
>> when there are some events are thrown from the server.
>>
>> In another context, when we want to use Websockets, we need to rely on
>> completely new protocol (WS). But SSE communication is possible through
>> plain HTTP protocol. This is more powerful than a new protocol in my
>> perspective
>>
>> Thanks,
>> Tham
>>
>>
>> ---------- Forwarded message ----------
>> From: Frank Caputo <frank_at_frankcaputo.de>
>> To: users_at_jax-rs-spec.java.net
>> Cc:
>> Date: Tue, 27 May 2014 19:52:28 +0200
>> Subject: [jax-rs-spec users] Re: [jsr344-experts mirror] JAX-RS MVC
>> Hi,
>>
>> I’m Frank Caputo and happy to continue the discussion here.
>>
>> Ciao Frank
>>
>> Am 23.05.2014 um 17:27 schrieb Edward Burns <edward.burns_at_oracle.com>:
>>
>> >>>>>> On Fri, 23 May 2014 10:10:21 -0400, Santiago Pericas-Geertsen <
>> Santiago.PericasGeertsen_at_oracle.com> said:
>> >
>> > SPG> I'm the spec lead for JAX-RS and Ed asked me to pop in here and
>> > SPG> invite you over to the mailto:users_at_jax-rs-spec.java.net where we
>> > SPG> are planning to have our discussions. I'd like to preserve the
>> > SPG> momentum from the thread that was started by Arjan back in February
>> > SPG> [2] and had discussions through until April [3]. Our plans for
>> > SPG> JAX-RS MVC include using Facelets and JSP as well as support for
>> > SPG> Flows, ViewScope and FlashScope. Ed will have more to say about the
>> > SPG> JSF side of these things.
>> >
>> > Hi Santiago,
>> >
>> > Thanks for the invitation.
>> >
>> > This email is a call to action to those of us how contributed to the
>> > discussion of MVC on users_at_javaserverfaces-spec-public list.
>> > Specifically, I'm counting on Arjan Tijms, Adrian Gonzalez, Andy Bosch,
>> > Kito Mann, Leonardo Uribe, Manfred Riem, Neil Griffin, and
>> > Frank Caputo to strongly consider joining users_at_jax-rs-spec.java.netand
>> > continuing the discussion there.
>> >
>> > Here is a brief summary the discussion that happened on
>> > users_at_javaserverfaces-spec-public thus far, staring with Arjan's
>> message
>> > on Fri, 28 Feb 2014 23:14:52 +0100 [1] and completing with Leonardo's
>> > last message on the thread at Tue, 8 Apr 2014 18:22:44 +0200 [2].
>> >
>> > Arjan pointed out the work Manfred did to build the action oriented
>> > framework on top of the JSF lifecycle mechanism.
>> >
>> > Adrian Gonzalez wrote:
>> >
>> > AG> Both JAX-RS and JSF miss some features for a MVC framework. JSF
>> > AG> misses (at least) the following stuff to support reasonably well the
>> > AG> MVC scenario :
>> >
>> > AG> 1. it doesn't support for now HTTP REST usage : HTTP PUT, POST
>> > AG> (without postback), DELETE, etc... This is a blocker.
>> >
>> > AG> 2. templating : plugging in a 3rd party templating engine easily
>> > AG> should be supported in MVC.
>> >
>> > AG> This is not the case for a component and an action based
>> > AG> framework. As I recall, Spring MVC has been built after
>> > AG> JAX-RS. Spring MVC authors didn't used JAX-RS because it was too
>> > AG> limiting for them . Perhaps someone should ask them why JAX-RS was
>> > AG> too limiting in order to lift those limitations ?
>> >
>> > AG> As for PlayFramework, I didn't used it, but here are some goodies :
>> >
>> > AG> * code reloading - a must have !
>> >
>> > AG> * view are compiled so you can use them in the controllers (to
>> > AG> populate the view and to navigate to them).
>> >
>> > AG> * view templates (and form helpers) are more succinct/understandable
>> > AG> than the same in JSP / facelets.
>> >
>> > Andy Bosch wrote:
>> >
>> > AB> Of course I am in favour of enhancing JSF according to user
>> > AB> feedback. But I am not sure whether it is a good idea to integrate
>> > AB> too much into it.
>> >
>> > Ed Burns wrote:
>> >
>> > EB> I'd like to see us extract Facelets from JSF, make it a first class
>> > EB> citizen of a JAX-RS MVC, *and* provide an Action Oriented
>> > EB> lifecycle as an alternative to the standard JSF lifecycle.
>> >
>> > Andy Bosch replied:
>> >
>> > AB> In my personal opinion it sounds good. But I often hear complaints
>> > AB> of people about the JSF lifecycle (mostly those people do not like
>> > AB> JSF at all ;-) ). Some people just don't like a complex
>> > AB> lifecycle. They prefer having a simple controller that is called
>> > AB> during an action invocation.
>> >
>> > AB> So to sum up I would say we have to carefully think about how
>> > AB> complex or easy such an lifecycle would become.
>> >
>> > Kito Mann asked:
>> >
>> > KM> Ed, what's your motivation for doing the JAX-RS route _and_ the JSF
>> > KM> route? Support action-based scenarios within JSF apps, but provide
>> > KM> JAX-RS for those who don't use JSF?
>> >
>> > Ed Burns replied:
>> >
>> > EB> Right, it's about making Facelets available outside of JSF because
>> > EB> templating is useful on its own, even without the JSF lifecycle.
>> >
>> > Leonardo Uribe responded by asserting that the combination of Spring MVC
>> > *and* JSF can be powerful, citing a blog entry and examples.
>> >
>> > LU> In other words, what the user want is in this case is:
>> >
>> > LU> - Take advantage of JSF 2 template system (facelets) and component
>> > LU> model.
>> >
>> > LU> - Don't use the JSF lifecycle and use something else that fits.
>> >
>> > Leonardo further asserts it is nonsense to take Facelets out of JSF:
>> >
>> > LU> If you take facelets out of JSF, what you are really doing is get
>> > LU> rid of JSF lifecycle, but besides that, you are not doing anything
>> > LU> else.
>> >
>> > Frank agreed with Leonardo's assertion.
>> >
>> > Though I agree with all of Leonardo's other points in his response, I
>> > disagree with this one. You are getting all the page templating from
>> > the <ui:> tag library which doesn't exist in any other server side java
>> > solution aside from Struts Tiles.
>> >
>> > Leonardo goes on to sketch a solution to allow JSF to plug more cleanly
>> > into Spring MVC, providing specific details about how the JSF lifecycle
>> > can be improved in the process.
>> >
>> > Taking another perspective on the matter, Leonardo outlines the
>> > data-only JSF lifecycle idea we've been kicking around for years and
>> > discussed at Javaland. The basic idea is to have a way for a JSF ajax
>> > request to have access to all JSF features except those relating
>> > directly to a view. This would include FacesContext, Flash, Flow, etc
>> > but would *NOT* include anything to do with a specific view. This is
>> > captured in JAVASERVERFACES_SPEC_PUBLIC-1261 and I want to pursue this
>> > in JSF 2.3.
>> >
>> > The discussion continued after Javaland. Frank sketched out how you
>> > could forward from JAX-RS to the FacesServlet today, even without Jersey
>> > MVC. Leonardo replied,
>> >
>> > LU> The only flaw I can see is using ExternalContext there is no way to
>> > LU> know when the request is a GET, a POST and so on, which is important
>> > LU> at the time to define the endpoint.
>> >
>> > LU> Now, it could be useful to have a "action source framework"
>> > LU> component. That means, an special component that work in a way that
>> > LU> everything inside it works just like any action source framework,
>> > LU> but everything outside the box still work under JSF rules.
>> >
>> > LU> So, other people has already thought the same as we are trying to do
>> > LU> and have been doing (JSF 2.2 viewAction and JSF 2.0 viewParam),
>> > LU> there are some cases where an action oriented approach with a
>> > LU> component oriented framework can coexist. In that sense, the ability
>> > LU> to define REST services inside CDI managed beans through Faces
>> > LU> Servlet seems to be important. For what? It is not hard to find
>> > LU> cases. For example, to expose information to some other app or
>> > LU> component or service that consume it as a REST service. If you have
>> > LU> a JSF webapp nothing can be simpler as define the method right on
>> > LU> the managed bean.
>> >
>> > Leonardo followed up on this with some very detailed suggestions.
>> > Leonardo, please join the discussion over on
>> > users_at_jax-rs-spec.java.net. He ends by summarizing:
>> >
>> > LU> For some users who currently uses JSF at a daily basis, this problem
>> > LU> is not something important, because there is a workaround and this
>> > LU> usually suppose a small part of the whole application, so you don't
>> > LU> really spent a lot of time solving it. It is not really hard to
>> > LU> write a couple of servlets that can do the job in these cases.
>> >
>> > LU> But for some other users that are not into JSF, this is
>> > LU> important. The reason is JSF Template engine (Facelets) solves a lot
>> > LU> of problems for them. These guys usually are making applications
>> > LU> with another architectural paradigm, different to the one proposed
>> > LU> initially by JSF.
>> >
>> > Let's get moving!
>> >
>> > Ed
>> >
>> > [1]
>> https://java.net/projects/javaserverfaces-spec-public/lists/users/archive/2014-02/message/7
>> >
>> > [2]
>> https://java.net/projects/javaserverfaces-spec-public/lists/users/archive/2014-04/message/6
>> >
>> >
>>
>>
>> End of digest for list users_at_jax-rs-spec.java.net - Wed, 28 May 2014
>>
>>
>