Hi Andy thanks for starting this discussion,
On Sun, Oct 24, 2010 at 8:28 PM, Andrzej Michalec < [email protected]> wrote: > > Hi guys, > after discussion with Sergey, I started looking on advanced URI template > specification that could be interesting alternative for current > implementation (http://tools.ietf.org/html/draft-gregorio-uritemplate-04). > 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 : message.getContextualProperty(propertyName). 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 use PhaseInterceptorChain.getCurrentMessage() 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: > http://cxf.547215.n5.nabble.com/How-to-introduce-configuration-for-low-level-class-tp3234606p3234606.html > Sent from the cxf-dev mailing list archive at Nabble.com. >
