Let me clarify: I don't care if JSF will become an MVC implementation of
choice for EE developers workig with JAX-RS or not, let it be, not a
problem. Neither I propose to have JAX-RS ship some full-blown MVC API.
I expect that JAX-RS will offer a light-weight link that either JSF or
non JSF implementations will be able to explore in their view
processors. What Jersey offers seems good enough for me, and to be
honest I'm happy enough with a MBW 'link' Apache CXF offers and which works.
But I have high hopes the spec will stay true to its spirit in the way
it is open to implementers/users.
Sergey
On 30/06/14 11:46, Sergey Beryozkin wrote:
> On 30/06/14 11:33, arjan tijms wrote:
>> Hi,
>>
>> On Mon, Jun 30, 2014 at 12:07 PM, Sergey Beryozkin
>> <sberyozkin_at_talend.com <mailto:sberyozkin_at_talend.com>> wrote:
>>
>> Sure, let JSF meet the requirements of Java EE users.
>> JAX-RS though is not used only by Java EE users and this is one of
>> reasons it's been generally more popular.
>> I want to be able to tell users who do not use JSF for doing MVC
>> that they still can do MVC with JAX-RS
>>
>>
>> I understand what you mean, but it's a slippery slope.
>>
>> For one there have been ongoing efforts to make Java EE a more
>> integrated, more clean fullstack framework. One of the complaints
>> against Java EE itself that I've not rarely heard is that it's a thrown
>> together bunch of technologies. This has been increasingly less the
>> case, but it still holds to some degree.
>>
>> Separate spec doing things their own way and/or duplicating efforts that
>> are found elsewhere in the Java EE platform contributes to this feeling.
>> Why do we have multiple types of managed beans? Why do we have 5 or 6
>> different kinds of converters (almost every spec has its own converter
>> these days)? Why do we have at least 4 ways (one in each spec) to get
>> the user/caller principal?
>>
>> I know from practice that this isn't really helping people get started
>> with Java EE. One only has to look at questions at StackOverflow. It's
>> not a small percentage of questions that is about this very confusion.
>>
>>
>> Secondly, wanting to do "something" in a certain spec for those users
>> that do not use that "something" that's already covered by another spec,
>> may set the door open to more and more other things, doesn't it?
>>
>> For instance given a new security JSR in Java EE, one could say:
>>
>> "I want to be able to tell users who do not use the security JSR for
>> doing security that they still can do security with JAX-RS"
>
> Lets not get side-tracked. JAX-RS is being used all over the place by
> people who do not work with Java EE. Plenty of users do it with
> standalone Tomcat or Jetty. These users do not have to be forced to
> download JSF in order to do MVC.
>
> I wonder if Bill was right in his pessimism about this effort, I'm
> starting worrying too
>
> Sergey
>
>>
>> Or about the new configuration JSR in Java EE:
>>
>> "I want to be able to tell users who do not use the configuration JSR
>> for doing configuration that they still can do configuration with JAX-RS"
>>
>> Or about a situation we already have, the managed bean model and
>> injection capabilities offered by CDI:
>>
>> "I want to be able to tell users who do not use CDI for doing injection
>> that they still can do injection with JAX-RS"
>>
>> It could go on and on, maybe in the future we'll have:
>>
>> "I want to be able to tell users who do not use JPA for doing
>> persistence that they still can do persistence with JAX-RS" (?)
>>
>>
>> Now it becomes even more difficult when we realize that JSF, just like
>> JAX-RS is also not only used by Java EE users. JSF in fact has been
>> usable outside Java EE from the very beginning and it has (IMHO) some
>> rather arcane backwards compatibility requirements just to satisfy this
>> other group of users. For JSF the exact same thing could be said:
>>
>> "I want to be able to tell users who do not use JAX-RS for doing MVC
>> that they still can do MVC with JSF" (ignoring for the moment that JSF
>> already does MVC and that "action oriented" is meant here).
>>
>> Taking this to the extreme, almost every single spec in Java EE could
>> theoretically become its own little Java EE, offering things like
>> validation, conversion, security, injection, MVC and what have you. I'm
>> not sure this is what we should aim for. In fact, as you may know JSF is
>> going the opposite route, dropping its own managed bean facility and
>> scopes in favour of CDI.
>>
>> Regards,
>> Arjan
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Cheers, Sergey
>>
>>
>> Regards,
>> Arjan
>>
>> Cheers, Sergey
>>
>>
>> Regards
>> Markus
>>
>> -----Original Message-----
>> From: Markus KARG [mailto:markus_at_headcrashing.eu
>> <mailto:markus_at_headcrashing.eu>
>> <mailto:markus_at_headcrashing.eu
>> <mailto:markus_at_headcrashing.eu>__>__]
>> Sent: Freitag, 30. Mai 2014 23:02
>> To: 'jsr339-experts_at_jax-rs-spec.____java.net
>> <http://java.net>
>> <mailto:jsr339-experts_at_jax-rs-__spec.java.net
>> <mailto:jsr339-experts_at_jax-rs-spec.java.net>>'
>> Subject: RE: [jsr339-experts] Re: MVC
>>
>> Frankly spoken, I am not clear about the intention of
>> adding MVC
>> support
>> particularly to JAX-RS. What do users expect to get in
>> the end,
>> keeping in
>> mind that JAX-RS's very own target is to provide a
>> framework for
>> RESTful
>> applications -- which by definition are stateless,
>> while MVC is
>> stateful,
>> just like JSF is. Could it be the case that MVC, just
>> as with
>> SSE (see my
>> other posting), is a candidate for a separate API built
>> ONTOP of
>> JAX-RS (an
>> OPTIONAL extension to JAX-RS in a technical sense)? I
>> think so,
>> so if Bill
>> Shannon likes to get that, and the JAX-RS EG group
>> denies this to be
>> RESTful, it might be an indicator that my proposal of
>> splitting
>> JAX-RS into
>> "Java API for http" and "Things built ontop of that,
>> like REST,
>> SSE, and
>> MVC" is valid and should be implemented. If JSF wants
>> to get an
>> MVC layer
>> implemented by JAX-RS technology, the way to go then
>> would be
>> that "we"
>> (JAX-RS) provide "Java API for http" (= the technology
>> defined
>> by JAX-RS
>> currently), while the JSF guys *use* that to build
>> their MVC
>> stuff ontop.
>> But frankly spoken, I do not see why "we" (JAX-RS)
>> should
>> provide MVC, is
>> that is not REST.
>>
>> Regards
>> -Markus
>>
>>
>> -----Original Message-----
>> From: Bill Burke [mailto:bburke_at_redhat.com
>> <mailto:bburke_at_redhat.com>
>> <mailto:bburke_at_redhat.com <mailto:bburke_at_redhat.com>>]
>> Sent: Freitag, 30. Mai 2014 21:12
>> To: jsr339-experts_at_jax-rs-spec.__j__ava.net
>> <http://java.net>
>> <mailto:jsr339-experts_at_jax-rs-__spec.java.net
>> <mailto:jsr339-experts_at_jax-rs-spec.java.net>>
>> Subject: [jsr339-experts] Re: MVC
>>
>>
>>
>> On 5/23/2014 4:36 AM, Sergey Beryozkin wrote:
>>
>> Hi
>> On 22/05/14 22:05, Santiago Pericas-Geertsen wrote:
>>
>> Dear Experts,
>>
>> 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 JAX-RS.next. 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.
>>
>> I'm aware of some discussion in the JSF
>> alias in
>> relation to MVC in
>> general, and its support as part of JAX-RS in
>> particular. I plan to
>> send an e-mail to the JSF alias as a way to
>> establish a
>> liaison
>> between the two groups. I believe their
>> expertise would
>> be of great
>> value for us and will help us design a
>> framework that
>> addresses the
>> requirements of the EE community.
>>
>> Look forward to JAX-RS supporting MVC and SSE. As
>> far as the
>> future
>> JAX-RS MVC is concerned, I hope it will not only
>> target EE users
>> though :-). i.e, it would work even if no JSF is
>> available,
>> but of
>> course the input from JSF experts will be of great
>> interest.
>> Using Jersey MVC as a template would be a nice
>> start IMHO,
>> we have a
>> less involved support for it, but I think it is
>> close enough
>> to the
>> way Jersey does it in some cases.
>>
>>
>> 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.
>>
>> This is wrong guys. You will regret adding and it will
>> end up
>> on the long
>> list of Java EE features that nobody uses and bloat
>> we'll have
>> to support.
>>
>> SSE and now MVC, I'm really disappointed in the
>> direction of JAX-RS.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Talend Community Coders
>> http://coders.talend.com/
>>
>> Blog: http://sberyozkin.blogspot.com
>>
>>
>>
>>
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com