cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: How to introduce configuration for low-level class?
Date Mon, 25 Oct 2010 17:05:52 GMT
Hi Andy

thanks for starting this discussion,

On Sun, Oct 24, 2010 at 8:28 PM, Andrzej Michalec <> wrote:

> Hi guys,
> after discussion with Sergey, I started looking on advanced URI template
> specification that could be interesting alternative for current
> implementation (
> I
> am talking about alternative since extending current implementation is not
> possible due to massive differences in semantics. Having different
> implementations it would be good to be able to configure them per endpoint.
> What I am looking for is your help in determining how to manage this kind
> of
> configuration. Usually config is defined on high-level and is passed down.
> For example using JAXRSServerFactoryBean configuration of endpoint is done
> with properties e.g. 'endpoint.put("org.apache.cxf.jaxrs.comparator",...)'
> which can be extracted then like this:
> 'message.getExchange().get(Endpoint.class).get("org.apache.cxf.jaxrs.comparator");'.
> However URITemplate class is more core/low-level and does not depend on
> bus.
> How should I make URITemplate class aware of configuration per-endpoint? Is
> the only option to extract this configuration from bus, so we need to make
> URITemplate factory method(s) aware of Messages?
JAXRSServerFactoryBean has a setProperties(Map) method as well; you can
probably use that one instead.
Usually, you can do on the current message :


Given that an advanced URI Template will only be used during the match on
the server side (initially at least), during the current invocation, you can


if it is not null then we can safely assume, in the URITemplate factory
method, that it is a server scope and so we can check if an advanced
URITemplate is required. In all other cases (the property is not set or the
current message is null) we can default to the default implementation
(initially at least).

> At the moment I am going to refactor current URITemplate implementation
> keeping default behavior unchanged as much as possible

Agreed - we need to keep the current implementation carefully isolated so
that we can be sure we are always JAXRS compliant, no matter what we do with
the advanced URI Template...

> - extraction of super
> interface will not be straightforward, there are places spread over the
> code
> where URITemplate objects are directly constructed (by c-tor) while in
> other
> places using static factory methods.

Yes indeed... Lets try to have most of the existing URITemplate code working
for both cases.
When I looked at it few weeks ago, I thought that the code which really has
to be isolated is the one which currently
executes in a constructor - so we can have two strategies there; the factory
method will decide which strategy instance to pass to the URITemplate
constructor. This is probably not very straightforward :-), but I'm hoping
we can have most of the existing URITemplate code working as expected
irrespectively of which matching strategy is used...

> Then I will introduce temporary
> configuration e.g. global property "org.apache.cxf.jaxrs.uriTemplateClass"
> without endpoints distinction. After all, with your help, template
> implementation will be configured in per-endpoint in proper manner.
> I usually prefer introducing boolean properties, so that users could just
indicate that they want the advanced uri template support, without having to
know the impl class names. Or may be string properties, ex,
"org.apache.cxf.jaxrs.uriTemplate" : jaxrs vs advanced, something like that

thanks, Sergey

> cheers,
> -andy.
> --
> View this message in context:
> Sent from the cxf-dev mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message