Sergey,
> In the end of the day, may be you are right. Or may be not: HTML-
> centric UIs are on the rise, and modular UI (aka where every part of it
> is linked to a bigger whole via references and such) is easy to build
> on the server and let the browser do the presentation with all
> enabled/disabled from a start.
>
> I've found this discussion to be quite interesting to be honest.
I also liked a discussion where I can simply and concentrated talk about
pure technical stuff. :-)
I understand your bias on HTML and share your ideas about the future trend,
but for me there is a technical difference between JSF -which is good for
setting up complete HTML views (for human clients) as you proposed it- and
JAX-RS which is more a http-centric, Content-Type-agnostic API (for machine
clients). What I want is separation of concerns in a way that allows to have
authorization inspection *also* in pure http machine clients, not only a
dictated use of HTML. Adding a human readable view ontop, effectively
reducing roundtrips, is great, but it should not prevent us from adding pure
http support for authorization inspection in JAX-RS.
BTW, I just read an article about the fact that lots of companies go back
from HTML5 to native apps as the HTML stuff was simply too slow. So we
should keep HTML5 in mind, but it should not lead to the fact that we *only*
support full-views.
> I'd encourage to not try to get JAX-RS runtime deal with the diff level
> responsibilities - and to be honest this is my main objection. I know
> you asked for the ESB-specific module only to support it - my concern
> would be people will request it be supported across the all JAX-RS
> integration modules. Writing and testing a filter which can easily
> check @RolesAllowed is easy - I can share the code from the existing
> CXF interceptor which does it
I totally agree, but I want to note that it is not possible to write such a
filter in pure JAX-RS 2.0 (maybe you can tell me how, I did not find a
possibility to get the java.lang.reflect.Method at which I can obtain the
@RolesAllowed annotation) and in fact I *do* see JAX-RS to be the perfectly
right level of *API* to *define* it (in the sense of "defining API" in
contrast to "fulfilling implementation"). To say it clearly, this does not
mean that a JAX-RS container must *implement* it in the sense of
do-it-yourself, but what I expect actually is that a JAX-RS enabled web
server comes with an optimized JAX-RS container that simply offloads the
filtering of the Allows-Header to the lower level core server (i. e. *the
server* does that checks e. g. by applying the filters we talked about -- as
the @RolesAllowed annotation is static information, that core server can set
up static code at deployment time inside of its own pre-JAX-RS routine phase
to do this). For Java SE I would simply say it is optional, so it is up to
the JAX-RS vendor to write additional code or not. But, as the application
vendor *solely* writes applications following the JAX-RS specification
(without any knowledge about the deeper levels), this spec *must* tell that
in the Java EE scenario, @RolesAllowed MUST have effect in the reduction of
the Allow-header's values -- independent of the implementor's choice to do
this in the JAX-RS container, or offload it to the core server (which
possibly provides some additional optimization benefits for full-stack
providers).
>
> Cheers, Sergey
>
>
>
> > Regards
> > Markus
> >
> >
> >