Hi,
On Mon, Jun 30, 2014 at 12:07 PM, Sergey Beryozkin <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"
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>__]
>> Sent: Freitag, 30. Mai 2014 23:02
>> To: '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>]
>> Sent: Freitag, 30. Mai 2014 21:12
>> To: 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
>>
>>
>>
>