Right, I see it's only excluded on the client side, this and the fact
the annotations are missed out needs to be fixed
Thanks, Sergey
On 04/03/14 21:36, [email protected] wrote:
Thanks Sergey.
i tried ParamConverterProvider but problem is it is skipped for param types of
String... it will work with custom classes but since these params are just
strings with special characters added or converted somehow it will not work.
"
protected String convertParamValue(Object pValue) {
if (pValue == null) {
return null;
}
Class<?> pClass = pValue.getClass();
if (pClass == String.class || pClass.isPrimitive()) {
return pValue.toString();
}
ProviderFactory pf = ProviderFactory.getInstance(cfg.getBus());
if (pf != null) {
@SuppressWarnings("unchecked")
ParamConverter<Object> prov =
(ParamConverter<Object>)pf.createParameterHandler(pClass);
if (prov != null) {
return prov.toString(pValue);
}
}
return pValue.toString();
}
"
if it's just a string param it skips calling any custom param handlers.
the other thing i noticed which maybe a bug is for ParamConverterProvider
i thought the annotations would be populated so you can see what type of param
it is
public <T> ParamConverter<T> getConverter(Class<T> cls, Type arg1, Annotation[]
arg2)
but in my tests both server side and client side
arg2 was always null.
i thought it might be set with actual anotations from the @PathParam
declaration.
I'll look into filters then in my case or interceptors.
would you recommend a good location to do the param modifications as to be
most efficient in the cxf chain of filters/interceptors.
again my param is just a simple string and i want to apply this modification
to only @PathParam params.. query and form i want to leave those as is.
so I need a way to check a) is it a String variable only and b) is it a
PathParam
the modify/wrap/unwrap.
thanks,
parwiz
________________________________
From: Sergey Beryozkin <[email protected]>
To: [email protected]
Sent: Tuesday, March 4, 2014 1:08 PM
Subject: Re: Advice on overwriting @PathParameters jax-rs and cxf proxies
Hi, JAX-RS 2.0 ClientRequestFilter and PreMatch ContainterRequestFilter
can be used to override the request URI.
JAX-RS 2.0 ParamConverterProvider can be used on the client and server
sides, may give you a finer control...
HTH, Sergey
On 04/03/14 18:49, [email protected] wrote:
Hi,
First of all I apologize if this has been asked before.
I wanted to ask for good solution that won't be too inefficient.
I do know about cxf interceptors and also request handlers method to
add to chain of inbound/outbound but not sure what would be a good place so
please give me some pointers/advice.
We are using cxf jax-rs rest with jackson as our json serializer/deserializer.
We are also using cxf java proxies on client side to call our code so we do
have control over our callers and would like to apply a custom handling to
these (yes I know it won't support per say web callers but the services are
right now internal only and will be consumed only by java proxy client).
On proxy/client side I would like to overwrite path parameters and do some
custom modifications before it's handed it to server (say add some wrapping to
it or extra characters .. maybe mask a password but other usages too)
On server side I would like to revert those and unwrap and get back the
original parameter.
@PathParam("test1") test1
on client take test1 original value and add some extra characters to it
on server side remove the extra characters and then pass it on to the service
method. Basically the java client and service impl code should not need to know
about this nor juggly this portion.. all of it done in interceptors/request
handlers prior to getting into service layer code and post leaving client
caller.
So should i extend JAXRSInInterceptor and do this there or creae a new
interceptor of my own and add it to the chain (out on client side, in on server
side).
please advice if you have done similiar thing on your end. I noticed
JAXRSInInterceptor does parameter settings so I would hoping I could tap into
that and not redo that portion and slow down our services.
thanks,
parwiz
