You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Andrzej Michalec <an...@gmail.com> on 2010/10/24 21:28:42 UTC
How to introduce configuration for low-level class?
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?
At the moment I am going to refactor current URITemplate implementation
keeping default behavior unchanged as much as possible - 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. 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.
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.
Re: How to introduce configuration for low-level class?
Posted by Andrzej Michalec <an...@gmail.com>.
Sergey Beryozkin-5 wrote:
>
> 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
>
In my sandbox I refactored references to create template always using
URITemplateFactory.create(). I successfully run JUnits and spring-driven
systest with default/current implementation running on server-side. Bad
thing is that in this factory method PhaseInterceptorChain always return
null as current message. I suspect that URITemplate instances are created
before processing phase, while message is not yet available.
cheers,
andy.
--
View this message in context: http://cxf.547215.n5.nabble.com/How-to-introduce-configuration-for-low-level-class-tp3234606p3239184.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: How to introduce configuration for low-level class?
Posted by Andrzej Michalec <an...@gmail.com>.
Bill Burke-2 wrote:
>
> It could be useful with UriBuilder
>
At the moment semantics of variables in curly braces is same for UriBuilder
and @Path annotation; they both delegate work with variables to common
URITemplate implementation class that does generation and matching. This is
why I am thinking about new implementation of URITemplate being
generation-matching pair aligned to this RFC draft grammar. If matching will
not be perceived as suitable, only the generation part may remain ;) Thanks
for comments.
cheers,
andy.
--
View this message in context: http://cxf.547215.n5.nabble.com/How-to-introduce-configuration-for-low-level-class-tp3234606p3239259.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: How to introduce configuration for low-level class?
Posted by Bill Burke <bb...@redhat.com>.
It could be useful with UriBuilder
On 10/27/10 1:15 PM, Andrzej Michalec wrote:
>
>
> Bill Burke-2 wrote:
>>
>> It think it was concluded that this spec was
>> more a URI generator template engine rather than a URI matching engine.
>> Meaning, it is more suitable for embedding within a link than using it
>> within a JAX-RS @Path annotation.
>>
> Bill, thank you for sharing your concerns from expert group perspective. I
> agree with first sentence, it was also my first impression: generation is
> trivial with while matching is not e.g. it introduces ambiguity with
> "undefined" values. I am not sure where it could be useful in JAX-RS if not
> in @Path? If we can build matching engine following this spec, I can imagine
> pushing more fine-grained patterns into @Path. For example today we use
> @QueryParam to extract this component of URI and then check if it is null or
> not to make further decisions; here one annotated method handles (is matched
> with) different permutations of URIs. If we could pushed decision up to
> @Path we would maintain patterns in one place.
>
> I have to admit that Sergey and me just started discussing this draft. I am
> just playing with this spec implementation and I am aware that it may not
> suite or not be accepted. If you see some obvious problems with construction
> of matching engine following this spec, please share your concern with me.
>
> cheers,
> andy.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
Re: How to introduce configuration for low-level class?
Posted by Andrzej Michalec <an...@gmail.com>.
Bill Burke-2 wrote:
>
> It think it was concluded that this spec was
> more a URI generator template engine rather than a URI matching engine.
> Meaning, it is more suitable for embedding within a link than using it
> within a JAX-RS @Path annotation.
>
Bill, thank you for sharing your concerns from expert group perspective. I
agree with first sentence, it was also my first impression: generation is
trivial with while matching is not e.g. it introduces ambiguity with
"undefined" values. I am not sure where it could be useful in JAX-RS if not
in @Path? If we can build matching engine following this spec, I can imagine
pushing more fine-grained patterns into @Path. For example today we use
@QueryParam to extract this component of URI and then check if it is null or
not to make further decisions; here one annotated method handles (is matched
with) different permutations of URIs. If we could pushed decision up to
@Path we would maintain patterns in one place.
I have to admit that Sergey and me just started discussing this draft. I am
just playing with this spec implementation and I am aware that it may not
suite or not be accepted. If you see some obvious problems with construction
of matching engine following this spec, please share your concern with me.
cheers,
andy.
--
View this message in context: http://cxf.547215.n5.nabble.com/How-to-introduce-configuration-for-low-level-class-tp3234606p3239107.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: How to introduce configuration for low-level class?
Posted by Bill Burke <bb...@redhat.com>.
On 10/25/10 1:05 PM, Sergey Beryozkin wrote:
> Hi Andy
>
> thanks for starting this discussion,
>
> On Sun, Oct 24, 2010 at 8:28 PM, Andrzej Michalec<
> andrzej.michalec@gmail.com> 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).
>>
FYI:
I think we tool a look at this RFC in the JAX-RS expert group (I can't
find the email thread). It think it was concluded that this spec was
more a URI generator template engine rather than a URI matching engine.
Meaning, it is more suitable for embedding within a link than using it
within a JAX-RS @Path annotation.
Cheers,
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
Re: How to introduce configuration for low-level class?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Andy
thanks for starting this discussion,
On Sun, Oct 24, 2010 at 8:28 PM, Andrzej Michalec <
andrzej.michalec@gmail.com> 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.
>