On 30/06/14 12:27, arjan tijms wrote:
> On Mon, Jun 30, 2014 at 1:03 PM, Sergey Beryozkin <sberyozkin_at_talend.com
> <mailto:sberyozkin_at_talend.com>> wrote:
>
> I don't care if JSF will become an MVC implementation of choice for
> EE developers workig with JAX-RS or not
>
>
> Maybe just a small additional clarification here; JSF already is the MVC
> implementation of choice in Java EE (JSF already is and always has been
> an MVC web framework).
>
> What I think you're referring to is whether JSF will become the action
> oriented MVC implementation of choice, right?
In this group we discuss JAX-RS related issues. I did say (quoting with
a typo fixed):
"JSF will become an MVC implementation of choice for
EE developers *working with JAX-RS*"
Sergey
>
> Regards,
> Arjan
>
>
>
>
> , 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>
> <mailto: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>__>
> <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@jax-rs-spec.______java.net <http://java.net>
> <http://java.net>
>
> <mailto:jsr339-experts_at_jax-rs-____spec.java.net
> <mailto:jsr339-experts_at_jax-rs-__spec.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>>
> <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@jax-rs-spec.__j____ava.net <http://j__ava.net>
> <http://java.net>
>
> <mailto:jsr339-experts_at_jax-rs-____spec.java.net
> <mailto:jsr339-experts_at_jax-rs-__spec.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
>
>