Marek,
as I just commented in the JIRA tracker, for *me* such an annotation would
be sufficient, so there is no need to further argue. Looking from a bird's
view, really dynamic features just seemed to be a logical step forward.
About the annotation you suggested, this will indeed save code on the
application vendors' side. See here:
current
* execute filter
* check headers
* write custom property to enable interceptor
* execute interceptor
* check custom property to skip interceptor if needed
* do the actual interception
future
* do the actual interception
From the view of the application vendor's side I must say that having the
annotation will reduce the amount of code to write for the feature from six
steps to less as one! Whether or not it also improves performance depends on
the possibility for internal optimizations the JAX-RS implementation might
have.
If you really plan to support this annotation, it must be changed in two
ways: First, it must allow a combination of header-name and header-value,
second, it must accept more than one such combination or one must be able to
add multiple annotations to one feature.
Regards
Markus
From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
Sent: Freitag, 2. November 2012 20:49
To: jsr339-experts_at_jax-rs-spec.java.net
Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: FW: Please discuss
http://java.net/jira/browse/JAX_RS_SPEC-293
Feature is a meta-provider. It has been designed as a way of grouping all
providers and properties that are used in combination to provide some
facility. It does not even make sense to "apply a feature" in any other
context than to expand it into the actual set of providers and properties.
The actual providers are those components that are really applied in the
request processing context.
Btw. I have also replied to your comment on the issue:
http://java.net/jira/browse/JAX_RS_SPEC-293?focusedCommentId=349411
<
http://java.net/jira/browse/JAX_RS_SPEC-293?focusedCommentId=349411&page=co
m.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_349411
>
&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#act
ion_349411
In summary it is naive to think that what you're proposing would not have a
negative impact on performance. As an implementor I know what I'm talking
about. What you perhaps really want to propose is that there could be one or
more constraint annotations that could be applied to providers so that
runtime can do the request-specific conditional checks on behalf of those
providers. E.g.
@ApplyIfPresent(HttpHeaders.CACHE_CONTROL)
public class CacheFilter implements ContainerResponseFilter { ... }
But that's a completely different story. The above is just a convenience
feature and I'm not even sure if there's any code saved.
Marek
On Nov 2, 2012, at 7:55 PM, Markus KARG <markus_at_headcrashing.eu> wrote:
Yes this is correct, but see, the idea came up due to two aspects:
(1) A feature might want to skip a filter by default, but only apply it if a
given http header is set. Example: A "Microsoft Compatibility" feature might
be installed with a JAX-RS application, and which applies a filter on all
requests and an interceptor on all responses, if the request is sent from a
Microsoft client (this is needed for WebDAV compatibility due to bugs in
Microsoft's clients). Skipping filters completely (hence not invoking
filter() at all) will not only improve workload due to the bypass
processing, but also makes authoring the filter itself much simpler: The
filter and interceptor does not need to check the headers anymore but can
rely on the fact that it is only executed in case of a Microsoft request,
must not set any custom properties to be passed to the interceptor, and the
interceptor does not need to check custom properties to find out whether the
request was sent by a Microsoft client. In the end, the feature is a lot
simpler to code and to understand and the workload is improved.
(2) Mapping features to http headers should be distinct from the actual
action the feature implements, due to separation of concerns. Just as a
JAX-RS resource implementation is separated from the method mapping in
analogy. Possibly a resource shall only be invoked as reaction to particular
headers, it would make sense to add an annotation to that resource method.
The same annotation would be useable at features, too. So as long as it
makes sense to separate concerns in resources, it makes sense to separated
concerns in filters and interceptors, too.
Regards
Markus
-----Original Message-----
From: Bill Burke [mailto:bburke_at_redhat.com]
Sent: Freitag, 2. November 2012 18:14
To: jsr339-experts_at_jax-rs-spec.java.net
Subject: [jsr339-experts] Re: FW: Please discuss
http://java.net/jira/browse/JAX_RS_SPEC-293
I don't think this is needed. You can just write a filter/itnerceptor
that checks to see if the header exists in the request or response and
bind these filters/interceptors globally.
On 11/2/2012 12:56 PM, Markus KARG wrote:
Experts,
in a private discussion Jan and me thought it could be a good idea
that DynamicFeature (as the word "dynamic" implies it) would include
the possibility to bind filters to http headers, so I'd like to
invite
you to discuss this proposal
http://java.net/jira/browse/JAX_RS_SPEC-293 and to vote for it if you
share our opinion. :-)
Thanks
Markus
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com