From: Werner Keil <werner.keil_at_gmail.com>
Date: Thu, 29 May 2014 14:11:35 +0200

Sorry, but
a) it's not directly related to Server-side-Events and
b) did you miss JSF Flowlets? That is exactly what you ask about
Spring/Struts inspired "actions" in JSF and Pivotal even contributed to
it;-)

Werner


>
> 3. [jax-rs-spec users] Re: Digest for list users_at_jax-rs-spec.java.net -
> Frans Thamura <frans_at_meruvian.org>
>
>
> ---------- Forwarded message ----------
> From: Frans Thamura <frans_at_meruvian.org>
> To: users_at_jax-rs-spec.java.net
> Cc:
> Date: Wed, 28 May 2014 18:13:53 +0700
> Subject: [jax-rs-spec users] Re: Digest for list
> users_at_jax-rs-spec.java.net
>
> 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.net
>>> and
>>> > 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
>>>
>>>
>>
> End of digest for list users_at_jax-rs-spec.java.net - Thu, 29 May 2014
>
>