Markus KARG

My proposal is a spec change. When designing applications it is really not nice that annotations have to get repeated in the implementing class. Why don't we change the spec...

> Is the proposal to add some clarifying Javadoc text to `UriBuilder.fromResource(...)` to indicate that class-level path annotation inheritance is not supported? Or is the proposal to change section 3.6...

> I agree that the annotation inheritance rules described in section 3.6 are a bit "special" and may not be very intuitive. But changing them would be challenging in regards...

I do not see that the server MUST depend of the client. We have many web services running that do NOT consume any other services, so why should they have...

> @mkarg Just to make sure I understand correctly. So you think we should split up the API JAR into three JARs (common, server, client)? This would be a requirement...

Ron, honestly I cannot see where there should be anything wrong or weird in the spec. Can you please clearly outline what bothers you here in detail?

To pitch the discussion, my proposal would roughly look like this: Let's find a specification wording that takes into account security roles and request properties as a mandatory feature of...

@spericas Thank you for chiming in. In fact, I deliberately abstained from providing a specific proposal, as I wanted to hear everybody's opinion on the *general problem* itself (the need...

@spericas Sorry to hear that, because in fact roles-based matching would be a *great* addition and we need it rather *frequently* and the current workarounds we have to do are...

> Instead of having special rules for security roles, could we have a more general dynamic/runtime disambiguation mechanism that could be used when more than one resource match a request?...