On 24/01/12 23:39, Sergey Beryozkin wrote:
This has been fixed on trunk/2.5.x/2.4.x,
but on on 2.3.x, just in case...
Technically, some of those characters which were previously encoded can
be kept as is when added to the path, but I still want to encode them
because it seems as if keeping them non-encoded may upset some legacy
servers :-) so keeping the 2.3.x without the fixes for now but of course
that can be pushed there too

Was a bit worried about '&' as it needs to be replaced with & in the
generated WADL if it is added un-encoded in @Path but ultimately it's a
XML processor which will read WADL so it should not be a prob

Give the snapshots a try please when you give a chance

when you *have* a chance

Sergey

Reply via email to