On Mon, Jun 30, 2014 at 1:03 PM, Sergey Beryozkin <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?
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>> 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
>